最后更新：2013/11/18
=======================
【综述】
目前官方没有提供HA集群解决方案，提供的是类似MySQL的主从同步方式，对于一般的规模和场景基本足够。
假设master为192.168.1.100:6000，slaver为192.168.1.101:6000，则slave的配置中打开 slaveof 192.168.1.100 6000 即可实现两者同步。
同步很简单，但怎样让同步更有效，集群更健壮，维护更简单呢？这些才是本文重点讨论的。
【RDB和AOF介绍】
众所周知，Redis支持RDB和AOF两种持久化方式（据说作者将来要将两者整合），前者就是定时快照，定时dump数据到磁盘；后者则类似于MySQL的binlog，会记录数据的每次变动动作。
两者并不冲突，可根据需求采用。
一般来说，常规情况下（绝大多数）都只是使用RDB；
性能至上的场景（类似memcache缓存）则可以完全关闭RDB和AOF；
对于对数据完整性要求极高的情况下（这种情况下一定要考虑好是不是非要用Redis）才会使用AOF，或两者都用。
【相关配置项介绍】
RDB时，对于快照的拍照频度，就是通过配置中的save <seconds> <changes>项进行设置，没啥好说的，视实际情况设置调整。
AOF时，也就是设置appendonly为yes，还需要设置的地方有：
appendfilename appendonly.aof 即aof文件的文件名。该文件增长的比较快，因为保存了每次写操作的过程，需要特别注意。
然后根据具体情况开启下面三个的其中一项，
# appendfsync always 每一步写操作都写入aof（最及时，影响性能最大）
# appendfsync everysec 每秒钟写入一次 （折中）
# appendfsync no Redis自身不主动写入，由OS系统内核写入（最慢，效率最高）
再捡几个主要的配置项说下：
slave-serve-stale-data默认为yes，表示当slave连不上master（如master宕机）时，该slave仍然能够响应client的请求，提供服务；反之为no时，slave不继续响应client，而是返回error。
rdbcompression默认为yes，表示保存快照时会对数据进行压缩，好处是dump出的文件会变小，坏处额外增加CPU负担，若改为no则反之。这年头CPU一般不是瓶颈，尤其是对于存储设备来说，所以建议开启。
maxmemory <bytes> 一定要设置最大内存，且建议最好留出一半以上的物理内存，供持久化操作及给slave同步数据用。
【数据恢复】
当Redis挂掉后，重启服务即可，此时它会自动从rdb或aof文件恢复数据到内存。
rdb文件中的数据更直接，体积小，恢复速度快；
aof文件记录的是log，体积庞大，恢复速度很慢。
如果两个文件都有，Redis会以哪个为准呢？
答：Redis在没有aof文件时才会使用rdb文件进行恢复。
【一种常规方案】
master关闭RDB和AOF；slave开启RDB，只读。
灾难场景：
1、当slave挂掉时，重启挂掉的slave即可，slave会自动和master同步；
2、当master挂掉时（只要slave没同时挂掉，如果怕就多搞几个slave），先停掉slave与master的同步（防止master重启后把未完全恢复的数据同步覆盖到slave），再把slave的rdb文件复制到master上（复制之前尽量执行一下bgsave命令，手动进行快照，否则一些新增数据很有可能尚未持久化），重启master，待master完全恢复后再开启slave的同步。
至于master为什么不开启rdb？性能不是主要原因，而是因为master开启rdb根本没有什么实际意义，其挂掉后最后写入的数据极大可能没有被dump，相比而言数据同步的速度一般会非常快，所以这部分数据一般会顺利地同步给slave，由slave完成dump，所以slave的rdb才是完整的。所以此方案只要能保证slave没问题，master几乎可以100%恢复数据。
【Tips】
1、如果要测试redis的数据恢复的话，不能直接用kill掉redis进程的方式模拟灾难，一定要加上-9参数，Redis内部是有捕获SIGTERM信号后的处理逻辑的。
2、每次快照是全盘dump，而不是增量dump（本质是先写新文件再rename），所以设置频度时要注意这个开销，并不是越及时越好。
3、Slave每次与Master重新同步的时候，master都会全盘快照给slave，在数据量大的情况下会造成master该段时间不可用，需要特别注意。