redis总结

转载：http://blog.sina.com.cn/s/blog_4a1f59bf0100teiz.html

redis高可用 (来自于：http://www.iteye.com/topic/1108383）

因为redis不仅作为缓存使用，而且也是resque执行异步和定时任务的消息队列，因此对于可用性的要求就比较高，一旦挂掉，所有后台任务就会全部停止，严重影响网站的功能和体验。

但是redis原生的cluster解决方案迟迟不出，去年看redis官网的时候，说是直到今年5月份才可能会有rc放出，所以没办法，只能自己做一个山寨的高可用方案勉强支撑一段时间。

PS：今年5月份的时候我再看，却又拖到“不早于夏末”了。原来不只是XXX说话不算数的。

redis双机高可用的基础，是redis的主备复制机制。指定主备角色，是用slaveof命令。

指定本机为master

Ruby代码   

1. slaveof NO ONE  

指定本机为192.168.1.10的slave

Ruby代码   

1. slaveof 192.168.1.10 6379  

本来一开始我也想如同mysql的master-master机制那样，分别在配置文件中指定本机为对方的slave，不过后来发现这个方法行不 通。如果配置文件中都设置slaveof x.x.x.x，那么这两个redis启动之后不提供服务，客户端无法连接，类似于服务死锁的状态。

经过多次实验发现，如果两个服务按照master-slave的方式启动，然后给master发送slaveof命令，指定其为另一个的slave，则此时双方都为slave，数据可以进行双向同步。基于这个原理，设计了一个redis双机互备的机制。

在自定义的配置文件中，做如下配置：

Ruby代码   

1. redis:  
2.   server: redis://192.168.1.1:6379  
3.   cluster:  
4.     master: redis://192.168.1.10:6379  
5.     slave: redis://192.168.1.20:6379  

192.168.1.1是keepalived的virtual ip，应用程序只使用这个ip地址来存取redis。

其核心的实现方式如下：

4.1 两台redis服务器，配合keepalived。初始状态，是在master（192.168.1.10）上绑定keepalived的virtual ip 192.168.1.1。
4.2 启动一个监控脚本，每秒钟对两个redis服务进行一次扫描。
4.3 如果两台redis处于正常master-slave状态，则不进行操作。
4.4 如果master挂掉，监控脚本对在线的slave（192.168.1.20）发送slaveof NO ONE命令，设置其为临时的主机temp-master，同时由于原来的master服务器挂掉，virtual ip 192.168.1.1自动转移至temp-master，不影响应用程序对redis的存取。此时应用程序新产生的数据都保存到temp- master（192.168.1.20）上。
4.5 脚本监测到原来的master（192.168.1.10）在挂掉后重新启动加入集群，则向master发送slaveof 192.168.1.20 6379命令，设置其为temp-slave，从temp-master（192.168.1.20）复制在自己挂掉期间丢失的数据。同时virtual ip自动跳回temp-slave（192.168.1.10）向应用程序提供服务。
4.6 延时30秒钟，确保数据复制完毕，对调temp-master和temp-slave的角色，恢复默认的master-slave体系。

我知道延时30秒钟确保数据复制完毕这种方式很不好，但我确实在redis的info命令响应中没有找到指示复制完毕的字段。如果有消息能够明确指出数据复制完毕的状态会更好。

这样，两台redis服务器中的任何一台挂掉，都会由另一台继续提供服务，不会对网站形成可察觉的影响，也不会丢失数据。



该文的url：http://my.oschina.net/victorli/blog/10939
最近在研究 Redis。去年曾做过一个 MemcacheDB, Tokyo Tyrant, Redis performance test， 到目前为止，这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的key value存储产品的诱惑，从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用 HBase(2))，当再回头再去看Redis，发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人，国内前十大网站 的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外，业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大 家探讨。

1. Redis是什么

这个问题的结果影响了我们怎么用Redis。如果你认为Redis是一个key value store, 那可能会用它来代替MySQL；如果认为它是一个可以持久化的cache, 可能只是它保存一些频繁访问的临时数据。Redis是REmote DIctionary Server的缩写，在Redis在官方网站的的副标题是A persistent key-value database with built-in net interface written in ANSI-C for Posix systems，这个定义偏向key value store。还有一些看法则认为Redis是一个memory database，因为它的高性能都是基于内存操作的基础。另外一些人则认为Redis是一个data structure server，因为Redis支持复杂的数据特性，比如List, Set等。对Redis的作用的不同解读决定了你对Redis的使用方式。

互联网数据目前基本使用两种方式来存储，关系数据库或者key value。但是这些互联网业务本身并不属于这两种数据类型，比如用户在社会化平台中的关系，它是一个list，如果要用关系数据库存储就需要转换成一种 多行记录的形式，这种形式存在很多冗余数据，每一行需要存储一些重复信息。如果用key value存储则修改和删除比较麻烦，需要将全部数据读出再写入。Redis在内存中设计了各种数据类型，让业务能够高速原子的访问这些数据结构，并且不 需要关心持久存储的问题，从架构上解决了前面两种存储需要走一些弯路的问题。

2. Redis不可能比Memcache快

很多开发者都认为Redis不可能比Memcached快，Memcached完全基于内存，而Redis具有持久化保存特性，即使是异步 的，Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因，目前想到的原因有这几方面。

• Libevent。 和Memcached不同，Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到 libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis使用另外一个libevent高性能替代libev，但是作者还是坚持Redis应该小巧并去依赖的思 路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。
• CAS问题。CAS是Memcached中比较方便的一种防止竞争修改资源的方法。CAS实现需要为每个cache key设置一个隐藏的cas token，cas相当value版本号，每次set会token需要递增，因此带来CPU和内存的双重开销，虽然这些开销很小，但是到单机10G+ cache以及QPS上万之后这些开销就会给双方相对带来一些细微性能差别(5)。

3. 单台Redis的存放数据必须比物理内存小

Redis的数据全部放在内存带来了高速的性能，但是也带来一些不合理之处。比如一个中型网站有100万注册用户，如果这些资料要用Redis来存 储，内存的容量必须能够容纳这100万用户。但是业务实际情况是100万用户只有5万活跃用户，1周来访问过1次的也只有15万用户，因此全部100万用 户的数据都放在内存有不合理之处，RAM需要为冷数据买单。

这跟操作系统非常相似，操作系统所有应用访问的数据都在内存，但是如果物理内存容纳不下新的数据，操作系统会智能将部分长期没有访问的数据交换到磁盘，为新的应用留出空间。现代操作系统给应用提供的并不是物理内存，而是虚拟内存(Virtual Memory)的概念。

基于相同的考虑，Redis 2.0也增加了VM特性。让Redis数据容量突破了物理内存的限制。并实现了数据冷热分离。

4. Redis的VM实现是重复造轮子

Redis的VM依照之前的epoll实现思路依旧是自己实现。但是在前面操作系统的介绍提到OS也可以自动帮程序实现冷热数据分离，Redis只 需要OS申请一块大内存，OS会自动将热数据放入物理内存，冷数据交换到硬盘，另外一个知名的“理解了现代操作系统(3)”的Varnish就是这样实 现，也取得了非常成功的效果。

作者antirez在解释为什么要自己实现VM中提到几个原因(6)。主要OS的VM换入换出是基于Page概念，比如OS VM1个Page是4K, 4K中只要还有一个元素即使只有1个字节被访问，这个页也不会被SWAP, 换入也同样道理，读到一个字节可能会换入4K无用的内存。而Redis自己实现则可以达到控制换入的粒度。另外访问操作系统SWAP内存区域时block 进程，也是导致Redis要自己实现VM原因之一。

5. 用get/set方式使用Redis

作为一个key value存在，很多开发者自然的使用set/get方式来使用Redis，实际上这并不是最优化的使用方法。尤其在未启用VM情况下，Redis全部数据需要放入内存，节约内存尤其重要。

假如一个key-value单元需要最小占用512字节，即使只存一个字节也占了512字节。这时候就有一个设计模式，可以把key复用，几个key-value放入一个key中，value再作为一个set存入，这样同样512字节就会存放10-100倍的容量。

这就是为了节约内存，建议使用hashset而不是set/get的方式来使用Redis，详细方法见参考文献(7)。

6. 使用aof代替snapshot

Redis有两种存储方式，默认是snapshot方式，实现方法是定时将内存的快照(snapshot)持久化到硬盘，这种方法缺点是持久化之后 如果出现crash则会丢失一段数据。因此在完美主义者的推动下作者增加了aof方式。aof即append only mode，在写入内存数据的同时将操作命令保存到日志文件，在一个并发更改上万的系统中，命令日志是一个非常庞大的数据，管理维护成本非常高，恢复重建时 间会非常长，这样导致失去aof高可用性本意。另外更重要的是Redis是一个内存数据结构模型，所有的优势都是建立在对内存复杂数据结构高效的原子操作 上，这样就看出aof是一个非常不协调的部分。

其实aof目的主要是数据可靠性及高可用性，在Redis中有另外一种方法来达到目的：Replication。由于Redis的高性能，复制基本没有延迟。这样达到了防止单点故障及实现了高可用。

小结

要想成功使用一种产品，我们需要深入了解它的特性。Redis性能突出，如果能够熟练的驾驭，对国内很多大型应用具有很大帮助。希望更多同行加入到Redis使用及代码研究行列。