一、Redis主从配置不一致
这个问题一般很少见，但如果有，就会发生很多诡异的问题，例如：
（1）max memory配置不一致：这个会导致数据的丢失。
原因：例如master配置4G，slave配置2G，这个时候主从复制可以成功，但如果在进行某一次全量复制的时候，slave拿到master的RDB加载数据时发现自身的2G内存不够用，这时就会触发slave的maxmemory策略，将数据进行淘汰。更可怕的是，在高可用的集群环境下，如果将这台slave升级成master的时候，就会发现数据已经丢失了。
（2）数据结构优化参数不一致（例如hash-max-ziplist-entries）：这个就会导致内存不一致。
原因：例如在master上对这个参数进行了优化，而在slave没有配置，就会造成主从节点内存不一致的诡异问题。
（3）Redis主从复制的性能问题
第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量 传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。第二次以及以后的同步实现是：Master将变量的快照直接实时依次发 送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上，只要有 Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞，但由于Redis使用单线程服务，如果Master快照文件比较大，那么第一次全量传输会耗费比较长时间，且文件传输过程中Master可能无法提供服务，也就是说服务会中断，对于关键服务，这个后果也是很可怕的。
以上根本问题的原因都离不开系统IO瓶颈问题，也就是硬盘读写速度不够快，主进程 fsync()/write() 操作被阻塞。
（4）单点故障问题
由于目前Redis的主从复制还不够成熟，所以存在明显的单点故障问题，这个目前只能自己做方案解决，如：主动复制，Proxy实现Slave对 Master的替换等，这个也是目前比较优先的任务之一。
总结：
Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
尽量避免在压力较大的主库上增加从库
为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系 为：Master<–Slave1<–Slave2<–Slave3…….，这样的结构也方便解决单点故障问题，实现Slave对 Master的替换，如果Master挂了，可以立马启用Slave1做Master，其他不变。
相关阅读：
6、欢迎加入技术交流
