FAQ

Redis与其他key-value存储有什么不同?

主要有以下两个原因。

  • Redis有着更为复杂的数据结构并且提供对他们的原子性操作,这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明,无需进行额外的抽象。
  • Redis运行在内存中但是可以持久化到磁盘,所以在对不同数据集进行高速读写时需要权衡内存,应为数据量不能大于硬件内存。在内存数据库方面的另一个优点是, 相比在磁盘上相同的复杂的数据结构,在内存中操作起来非常简单,这样Redis可以做很多内部复杂性很强的事情。 同时,在磁盘格式方面他们是紧凑的以追加的方式产生的,因为他们并不需要进行随机访问。

Redis的内存占用情况怎么样?

给你举个例子: 100万个键值对(键是0到999999值是字符串“hello world”)在我的32位的Mac笔记本上 用了100MB。同样的数据放到一个key里只需要16MB, 这是因为键值有一个很大的开销。 在Memcached上执行也是类似的结果,但是相对Redis的开销要小一点点,因为Redis会记录类型信息引用计数等等。

当然,大键值对时两者的比例要好很多。

64位的系统比32位的需要更多的内存开销,尤其是键值对都较小时,这是因为64位的系统里指针占用了8个字节。 但是,当然,64位系统支持更大的内存,所以为了运行大型的Redis服务器或多或少的需要使用64位的系统。

我喜欢Reids的高水平操作和功能,但我不喜欢所有数据都放在内存中,因为我没有一个大数据集的内存,有没有改变这方面的机会呢。

在过去,Redis开发商尝试试用虚拟内存和其他系统为了让RAM数据集更大,但是毕竟我们非常高兴,如果我们能做好一件事:数据保存在内存,存储在磁盘。 但是现在没有计划创建一个基于磁盘的Redis,毕竟目前的设计是直接的原因。

然而,许多大型系统的用户采用多个Redis节点通过客户端Hash的办法解决了大数据集分配的问题。Craigslist和Groupon就是两个列子。

同时Redis Cluster(一个Redis的子集自动分发和容错实现)正在开发中,这可能是很多使用案例的一个很好的解决方案

如果我的数据集需要使用非常大的内存,我不希望使用一致性哈希或其他方式将数据集分布在不同的节点,我还能采用Redis吗?

一个可行的方案是同时使用传统数据库(Mysql或者其他的)和Redis,Redis里面存放状态信息(元数据,小但经常写的信息),和所有其他读写频繁的数据:用户身份验证token, 使用Redis List 存放与时间顺序有关的id列表、编码等等。然后使用MySQL(或其他)作为存储引擎来存放更大的数据, 创建一个自增长ID作为主键和一个较大的BLOB字段作为数据字段,访问MySQL的数据只能通过主键(ID) 。执行查询操作时,通过Redis读取数据, 但是当有读取打数据时需要通过主键(ID)访问MySQL数据库。

都有哪些办法可以降低Redis的内存使用情况呢?

如果你使用的是32位的Redis实例,可以好好利用Hash,list,sorted set,set等集合类型数据,因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。

Redis的内存用完了会发生什么?

随着现代操作系统的malloc(),返回NULL是不常见的,通常服务器会启动swap交换,这样Redis的性能会随之降低,您也可能会发现某些不妥。

INFO命令可以查看Redis的使用量,因此您可以编写一个监视Redis服务器状态的临界监控脚本以检查服务器的状态。 或者可以在配置文件中使用“maxmemory”配置Redis可以使用的最大内存,如果达到设置的上限,Redis的写命令会返回错误信息(但是读命令还可以正常返回)。 或者你可以将Redis当缓存来使用配置淘汰机制,当Redis达到内存上限时会冲刷掉旧的内容。

在liunx下即使有很多的RAM通过fork()调用后台保存还是会失败!

简短的回答:echo 1 > /proc/sys/vm/overcommit_memory :)

下面是长的回答:

Redis background saving schema relies on the copy-on-write semantic of fork in modern operating syst