Redis主从同步及哨兵原理

 

一、复制过程

　　复制过程大体分为6个过程：

　　流程图以下：

　　

　　1）保存主节点信息

　　　　执行slaveof后从节点只保存主节点的地址信息便直接返回，这时创建复制流程尚未开始，在从节点执行info replication能够看到以下信息：

master_host:xxx
master_port:xxx
master_link_status:down

　　　　从统计信息能够看出，主节点的ip和port被保存下来，可是主节点的链接状态master_link_status是下线状态。执行slaveof后Redis会打印以下日志：

SLAVE OF 127.0.0.1:6379 enabled (user request from 'id=65 addr=127.0.0.1:58090
fd=5 name= age=11 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=
32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')

　　2）从节点内部经过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点创建网络链接。从节点会创建一个socket套接字，专门用于接受主节点发送的复制命令。如链接成功，打印日志以下：

* Connecting to MASTER 127.0.0.1:6379
* MASTER <-> SLAVE sync started

　　　　若是从节点没法创建链接，定时任务会无限重试直到链接成功或执行slaveof no one取消复制。

　　　　链接失败，能够在从节点执行info replication查看master_link_down_since_seconds指标，它会记录与主节点链接失败的系统时间。此时日志以下

# Error condition on socket for SYNC: {socket_error_reason}

　　3） 发送ping命令

　　　　链接创建成功后从节点发送ping请求进行首次通讯，ping请求主要目的以下：

　　　　- 检测主从之间网络套接字是否可用

　　　　- 检测主节点当前是否可接受处理命令

　　　　若是发送ping命令后，从节点没有收到主节点的pong回复或者超时，好比网络超时或者主节点正在阻塞没法响应命令，从节点会断开复制连接，下次定时任务时任务会重连。

　　　　从节点与主节点创建链接流程如图

　　　　

　　　　从节点发送ping命令流程

　　　　

　　4）权限验证

　　　　若是主节点设置了requirepass参数，则须要密码验证，从节点必须配置masterauth参数保证与主节点相同的密码才能经过验证；若是验证失败复制将终止，从节点从新发起复制流程。

　　5）同步数据集

　　　　主从复制连接正常通讯后，对于首次创建复制的场景，主节点会把持有的数据所有发送给从节点，这部分是耗时最长的步骤。Redis在2.8版本之后采用新复制命令psync进行数据同步，原来的sync命令也一样支持，为了新旧版本的兼容性。新同步划分为两种状况：全量同步和部分同步。

　　6）命令持续复制

　　　　当主节点把当前数据同步给从节点或，便完成了复制的创建流程，接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

 

二、数据同步

　　Redis在2.8及以上版本使用psync命令完成主从数据同步，同步过程分为全量复制和部分复制。

　　全量复制：通常用于初次复制场景，Redis早期支持的复制功能只有全量复制，它会把从节点所有数据一次性发送给从节点，当数据较大时，会对主从节点和网络形成很大的开销。

　　部分复制：用于处理在主从复制中因网络闪断等缘由形成的数据丢失场景，当从节点再次连上主节点后，若是条件容许，主节点会补发丢失数据给从节点。由于补发的数据远远小于全量数据，能够有效避免全量复制的开销。

　　部分复制是对老版复制的重大优化，有效避免了没必要要的全量复制操做。所以当使用复制功能时，尽可能采用2.8以上版本的Redis。

　　psync命令运行须要如下组件支持：

　　- 主从节点各自复制偏移量

　　- 主节点复制积压缓冲区

　　- 主节点运行id

　　1）复制偏移量

　　　　参与复制的主从节点都会维护自身复制偏移量，主节点处理完写入命令后，会把命令的字节长度作累加记录，统计信息在info replication中的master_repl_offset指标中。

　　　　从节点每秒上报自身的复制偏移量给主节点，所以主节点也会保存从节点的复制偏移量。都可以经过info replication查看。

127.0.0.1:6379> info replication # Replication role:master ... master_repl_offset:1055130

------------------------------------

127.0.0.1:6379> info replication connected_slaves:1 slave0:ip=127.0.0.1,port=6380,state=online,offset=1055214,lag=1

　　　　从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。统计信息在info replication中的slave_repl_offset指标中：

127.0.0.1:6380> info replication # Replication role:slave ... slave_repl_offset:1055214

　　　　经过对比主从节点的复制偏移量，能够判断主从节点数据是否一致。

　　　　提示：能够经过主节点的统计信息，计算出master_repl_offset - slave_offset字节量，判断主从节点复制相差的数据量，根据这个差值断定当前复制的健康度。

　　2）复制积压缓冲区

　　　　复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为1MB，当主节点有链接的从节点时被建立，这时主节点响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区。

　　　　因为缓冲区本质上是先进先出的定长队列，因此能实现保存最近已复制数据的功能，用于部分复制和复制命令丢失的数据补救。复制缓冲区相关统计信息也保存在主节点的info replication中：

127.0.0.1:6379> info replication # Replication role:master ... repl_backlog_active:1 // 开启复制缓冲区
repl_backlog_size:1048576 // 缓冲区最大长度
repl_backlog_first_byte_offset:7479 // 起始偏移量，计算当前缓冲区可用范围
repl_backlog_histlen:1048576 // 已保存数据的有效长度。

　　3）主节点运行ID

　　　　每一个Redis节点启动后都会动态分配一个40位的十六进制字符串做为运行ID。运行ID的主要做用是用来惟一识别Redis节点，好比从节点保存主节点的运行ID识别本身正在复制的是哪一个主节点。若是只使用ip+port的方式识别主节点，那么主节点重启变动了总体数据集（如替换RDB/AOF），从节点再基于偏移量复制数据将是不安全的，所以当运行ID变化后从节点将作全量复制。能够运行info server命令查看当前节点的运行ID：

127.0.0.1:6379> info server # Server redis_version:3.0.7 ... run_id:545f7c76183d0798a327591395b030000ee6def9

　　　　须要注意的是Redis关闭再启动后，运行ID会随之改变。Redis不改变ID重启，可使用redis-cli debug reload

　　　　注意：debug reload命令会阻塞当前Redis节点主线程，阻塞期间会生成本地RDB快照并清空数据以后再加载RDB文件，所以对于大数据量的节点和没法容忍阻塞的应用场景，谨慎使用。

　　4）psync命令

　　　　从节点使用psync命令完成部分复制和全量复制功能，命令格式：psync {runid} {offset}

　　　　- runid：从节点所复制主节点的运行id

　　　　- offset：当前从节点已复制的数据偏移量

　　　　psync运行流程

　　　　

　　　　流程说明：

　　　　1）从节点发送psync命令给主节点，参数runid是当前从节点保存的主节点运行ID，参数offset是当前从节点保存的复制偏移量，若是是第一次复制则为-1。

　　　　2）主节点根据psync参数和自身数据状况决定响应结果：

　　　　- 若是回复 FULLRESYNC {runid} {offset}，那么从节点触发全量复制

　　　　- 若是回复CONTINUE，从节点将触发部分复制流程

　　　　- 若是回复ERR，说明主节点版本低于2.8，没法识别psync命令，从节点将发送旧版的sync命令触发全量复制流程。

 

三、全量复制

　　全量复制是Redis最先支持的复制方式，也是主从第一次创建复制时必须经历的阶段。触发全量复制的命令是sync和psync。

　　全量复制流程：

　　

　　流程说明：

　　1）发送psync命令进行数据同步，因为是第一次进行复制，从节点没有复制偏移量和主节点的运行ID，全部发送psync-1

　　2）主节点根据psync-1解析出当前为全量复制，回复+FULLRESYNC响应。

　　3）从节点接收主节点的响应数据保存运行ID和偏移量offset，执行到当前步骤时从节点打印以下日志：

Partial resynchronization not possible (no cached master) Full resync from master: 92d1cb14ff7ba97816216f7beb839efe036775b2:216789

　　4）主节点执行bgsave保存RDB文件到本地，主节点bgsave相关日志以下：

M * Full resync requested by slave 127.0.0.1:6380 M * Starting BGSAVE for SYNC with target: disk C * Background saving started by pid 32618 C * RDB: 0 MB of memory used by copy-on-write M * Background saving terminated with success

　　提示：Redis 3.0以后在输出的日志开头会有MSC等标识，对应的含义是：M=当前为主节点日志，S=当前为从节点日志，C=子进程日志。

　　save和bgsave的区别：save直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成以后向主进程发送信号，通知保存已完成。由于 rdbSave 在子进程被调用，因此 Redis 服务器在BGSAVE 执行期间仍然能够继续处理客户端的请求。

　　5）主节点发送RDB文件给从节点，从节点把接收的RDB文件保存在本地并直接做为从节点的数据文件，接收完RDB后从节点能够在日志中查看主节点发送的数据量：

16:24:03.057 * MASTER <-> SLAVE sync: receiving 24777842 bytes from master

　　注意：对于数据量大的主节点，好比生成的RDB文件超过6GB以上传输文件这一步操做很是耗时，速度取决于主从节点之间的网络带宽，针对数据量较大的节点，建议调大repl-timeout参数防止出现全量同步数据超时。

　　关于无盘复制：为了下降主节点的磁盘开销，Redis支持无盘复制，生成的RDB文件不保存到硬盘而是直接经过网络发送给从节点，经过repl-diskless-sync参数控制，默认关闭。无盘复制适用于主节点所在机器磁盘性能较差但网络带宽较充裕的场景。注意无盘复制目前依然处于试验阶段。

　　6）对于从节点开始接收RDB快照到接收完成期间，主节点仍然响应读写命令，所以主节点会把这期间写命令数据保存在复制客户端缓冲区内，当从节点加载完RDB文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。若是主节点建立和传输RDB的时间过长，对于高流量写入场景很是容易形成主节点复制客户端缓冲区溢出。默认配置为client-output-buffer-limit slave 256MB 64MB 60.若是60秒内缓冲区消耗持续大于64MB或者直接超过356MB时，主节点将直接关闭复制客户端链接，形成全量同步失败，日志以下：

M 27 May 12:13:33.669 # Client id=2 addr=127.0.0.1:24555 age=1 idle=1 flags=S qbuf=0 qbuf-free=0 obl=18824 oll=21382 omem=268442640 events=r cmd=psync scheduled to be closed ASAP for overcoming of output buffer limits.

　　所以须要根据主节点数据量和写命令并发量调整client-output-buffer-limit slave配置，避免全量复制期间客户端缓冲区溢出。

　　7）从节点接收完主节点传送来的所有数据后清空自身旧数据，该步骤对应以下日志：

16:24:02.234 * MASTER <-> SLAVE sync: Flushing old data

　　8）从节点清空数据后开始加载RDB文件，对于较大的RDB依然耗时。对于读写分离的场景，能够设置slave-serve-stale-data参数为no，关闭命令执行，在完成同步前不响应读命令。

　　9）从节点成功加载完RDB后，若是当前节点开启了AOF持久化功能，它会马上作bgrewriteaof操做，为了保证全量复制后AOF持久化文件马上可用。

　　RDB和AOF区别：RDB是将Redis某一时刻的数据持久化到磁盘上，相似于快照；AOF是将redis执行过的全部写指令记录下来，在下次redis从新启动时，只要把这些写指令从前到后再重复执行一遍，就能够实现数据恢复，默认每秒钟fsync一次。

 

四、部分复制

　　部分复制主要是Redis针对全量复制的太高开销作出的一种优化措施，使用psync {runid} {offset}命令实现，当从节点正在复制主节点时，若是出现异常状况，从节点要求补发丢失的命令数据，若是主节点的复制积压缓冲区内存在这部分数据则直接发送给从节点，这样就能够保持主从节点复制的一致性。

　　部分复制过程：

　　

　　流程说明：

　　1）当主从节点之间网络出现中断时，若是超过repl-timeout时间，主节点会认为从节点故障并中断复制连接。

　　2）主从链接中断期间主节点依然响应命令，写命令保存在复制积压缓冲区，默认最大缓存1MB。

　　3）当主从节点网络恢复后，从节点会再次链接主节点。

　　4）链接恢复后，因为从节点保存了自身已复制的偏移量和主节点的运行ID，所以会把他们当作psync参数发送给主节点，要求进行部分复制操做。

　　5）主节点接收到psync命令后首先核对参数runid，若是一致，说明以前复制的是当前主节点，以后根据参数offset在自身复制积压缓冲区查找，找到发送+CONTINUE响应。

　　6）主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

 

五、哨兵模式

　　Redis Sentinel经过三个定时监控任务完成对各个节点的发现和控制：

　　1）每隔10秒，每一个sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。经过解析info replication能够找到相应的从节点。此定时任务做用于三个方面：

　　- 经过向主节点执行info命令，获取从节点的信息。

　　- 当有新的节点加入时，能够马上感知出来。

　　- 节点不可达或者故障转移后，能够经过info命令实时更新节点拓扑信息。

　　2）每隔2秒，每隔sentinel节点会向Redis数据节点的__sentinel__:hello频道上发送该sentinel节点对于主节点的判断以及当前sentinel节点的信息，同时每隔sentinel节点也会订阅该频道，来了解其余sentinel节点以及他们对主节点的判断，所以此任务主要做用以下：

　　- 发现新的sentinel节点

　　- sentinel节点之间交换主节点的状态，做为后面客观下线以及领导者选举的依据。

　　3）每隔1秒，每隔sentinel节点会向主节点、从节点、其余sentinel节点发送一条ping命令作一次心跳检测。

 

六、Redis集群

6.1 数据分布

　　Redis Cluster把数据集划分到多个节点，每一个节点负责总体数据的一个子集。Redis Cluster槽范围是0~16383，槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展，每一个节点会负责必定数量的槽。

6.2 集群功能限制

　　1）key批量操做支持有限。如mset、mget，目前只支持具备相同slot值的key执行批量操做。对于映射为不一样slot值的key不被支持。

　　2）key事务操做支持有限。同理只支持多key在同一节点上的事务操做，当多个key分布在不一样的节点上时没法使用事务功能。

　　3）key做为数据分区的最小粒度，所以不能将一个大的键值对象如hash、list等映射到不一样的节点。

　　4）不支持多数据空间。单机支持16个数据库，集群只有db0。

　　5）复制结构只支持一层。