Redis复制与可扩展集群搭建——Redis学习笔记（四）

原文链接：http://www.infoq.com/cn/articles/tq-redis-copy-build-scalable-cluster

Redis复制流程概述：

复制功能：完全建立在基于内存快照的持久化策略基础上。

即：无论持久化策略选择的是什么，只要用到Redis复制功能，就一定会有内存快照发生---->所以，首先要注意系统内存容量规划（原因涉及到Redis磁盘IO问题）

Redis 复制流程在slave和Master端各自是一套状态机流转。涉及到的状态信息是：

Slave

REDIS_REPL_NONE

 REDIS_REPL_CONNECT  REDIS_REPL_CONNECTED 

Master端：

REDIS_REPL_WAIT_BGSAVE_START

 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作为高速数据查询从库的异构读写分离的设计方案。。