Redis复制流程概述：
复制功能：完全建立在基于内存快照的持久化策略基础上。 即：无论持久化策略选择的是什么，只要用到Redis复制功能，就一定会有内存快照发生----> 所以，首先要注意系统内存容量规划（原因涉及到Redis磁盘IO问题） Redis 复制流程在slave和Master端各自是一套状态机流转。涉及到的状态信息是：
Slave REDIS_REPL_NONE
REDIS_REPL_CONNECT REDIS_REPL_CONNECTED
REDIS_REPL_WAIT_BGSAVE_END REDIS_REPL_SEND_BULK REDIS_REPL_ONLINE
整个状态机流程过程： 1、Slave端在配置文件中添加slave of指令，于是slave启动时读取配置文件，初始状态为：REDIS_REPL_CONNECT。 2、Slave端在定时任务serverCron（Redis内部的定时器触发事件）中连接Master，发送sync命令。然后阻塞等待master发送回其内存块状文件。 3、Master收到sync命令，简单判断是否有正在进行的内存快照子进程，没有则开始内存快照，有则等待结束，当快照完成后会将该文件发送给slave端。 4、Slave端接收Master发来的内存快照文件，保存到本地，接收完成后，清空内存表。重新读取Master发来的内存快照文件。重建整个内存表数据结构。并最终状态置位为REDIS_REPL_CONNECTED，---Slave状态机流转完成。 5、Master 在发送快照文件中，接受的任何会改变数据集的命令都先会暂时保存在Slave网络连接的发送缓存队列里——（list数据结构）。。待快照完成后，依次发送给Slave，之后收到的命令相同处理，并将状态置位为REDIS_REPL_ONLINE。
Redis 复制机制的缺陷
Slave从库连接Master主库时，Master会进行内存快照，然后把快照文件发给Slave。没有像MySQL那样有复制位置的概念——无增量复制，这样会给整个集群搭建带来很多问题：
主从库读写分离的配置中，————假如从库Slave与Master断开了连接----------------那么重新连接时，需重新获取整个Master的快照，Slave重新建立整个内存表，----这样就造成： ====一方面Slave恢复的时间会非常慢，另一方面也会给主库带来压力
所以基于上述原因：如果Redis需主从复制，那么最好事先配置好所有的从库，避免中途再去增加从库。
Cache还是Storage的问题
Redis目前的设计思路——单机版的思路，因为持久化方式不够成熟，复制机制存在较大缺陷。——那么Redis应该怎样定位： Cache还是Storage？？
如果是Cache的话，除了那些必须使用Redis的某种数据结构的特殊的业务场景外，Memcache则会更合适； 如果作为Storage的话，无法解决Redis的单点问题。即一台Redis挂掉，就没有太好的办法能够快速的恢复。
Redis可扩展集群搭建： 主动复制避开Redis复制缺陷——即一次进行多次写入； 解决容量规划与在线扩容问题。 问题：多个Redis实例是啥意思？？？？
Redis复制改进思路:暂时先没看
Redis与MySQL的结合：
大部分互联网公司采用MySQL作为数据的主要持久化存储。这样设计一种基于MySQL作为主库，Redis作为高速数据查询从库的异构读写分离的设计方案。。
