关于redis源码主从同步的信息
本文目录一览：
- 1、redis集群的主从数据是实时同步吗
- 2、redis主从和哨兵
- 3、redis 和 mysql 数据同步问题
- 4、redis 命令执行过程
- 5、redis主从数据库为什么同步失败
- 6、redis cluster集群选主
redis集群的主从数据是实时同步吗
多个master也只有一个主，一个或者多个备，一般都是在主上面进行增删，从一般都是通过复制log进行同步。这也是所有的主从复制式集群的原理，例如redis，mysql都是如此。
redis主从和哨兵
主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性
a,配置主从复制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379启动完后再启6380，完成配置；
b,配置主从复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效
c,查看状态：info replication
d,断开主从复制：在slave节点，执行6380:slaveof no one
e,断开后再变成主从复制：6380: slaveof 192.168.152.128 6379
f,数据较重要的节点，主从复制时使用密码验证： requirepass
e, 从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致
h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭
参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，
参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房
a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响
b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定
c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。
redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制
全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）
部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步
心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率
a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
b)主从复制主节点的写能力单机，能力有限
c)单机节点的存储能力也有限
a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；
b)其它的节点成为新主节点的从节点，并从新节点复制数据；
c)需要人工干预，无法实现高可用。
1. 为什么要有哨兵机制？
原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知
任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的
任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线
a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………
a)由Sentinel节点定期监控发现主节点是否出现了故障
sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移
c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行
流程：
1. 将slave-1脱离原从节点，升级主节点，
d) 故障转移后的redis sentinel的拓扑结构图
a) 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
b) 选择salve-priority从节点优先级最高（redis.conf）的
c) 选择复制偏移量最大，指复制最完整的从节点
以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署
1. 前提： 先搭好一主两从redis的主从复制，和之前的主从复制搭建一样，搭建方式如下：
A）主节点6379节点（/usr/local/bin/conf/redis6379.conf）：
修改 requirepass 12345678，注释掉#bind 127.0.0.1
B) 从节点redis6380.conf和redis6381.conf: 配置都一样
修改 requirepass 12345678 ,注释掉#bind 127.0.0.1,
加上访问主节点的密码masterauth 12345678 ,加上slaveof 192.168.152.128 6379
2. redis sentinel哨兵机制核心配置 (也是3个节点)：
将三个文件的端口改成: 26379 26380 26381
然后：sentinel monitor mymaster 192.168.152.128 6379 2 //监听主节点6379
三个配置除端口外，其它一样。
3. 哨兵其它的配置 ：只要修改每个sentinel.conf的这段配置即可：
sentinel monitor mymaster 192.168.152.128 6379 2
//监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster，2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了
sentinel auth-pass mymaster 12345678 //sentinel连主节点的密码
sentinel config-epoch mymaster 2 //故障转移时最多可以有2从节点同时对新主节点进行数据同步
sentinel leader-epoch mymaster 2
sentinel failover-timeout mymasterA **180000 **//故障转移超时时间180s，
a,如果转移超时失败，下次转移时时间为之前的2倍；
b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过 180S 时，则故障转移失败
c,从节点复制新主节点时间超过 180S 转移失败
sentinel down-after-milliseconds mymasterA 300000 //sentinel节点定期向主节点ping命令，当超过了 300S 时间后没有回复，可能就认定为此主节点出现故障了……
sentinel parallel-syncs mymasterA 1 //故障转移后， 1 代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销
4. 启动redis服务和sentinel服务:
a)先把之前安装的redis里面的标绿色的文件都拷贝到 usr/local/bin目录下，然后再再bin目录下新建一个conf文件夹存放配置好的redis主从配置文件和哨兵配置文件
b)启动主从复制服务，先启动主再启动从
主：./redis-server conf/redis6379.conf
从：
./redis-server conf/redis6380.conf
./redis-server conf/redis6381.conf
c）启动sentinel服务:
./redis-sentinel conf/sentinel_26381.conf
到此服务全部启动完毕
连接到6379的redis的服务，可看到6379就是主节点，他有6380和6381两个从节点
5. 测试： kill -9 6379 杀掉6379的redis服务
可以看到杀掉6379以后6380变为了主节点，6381变为了6380的从节点
重新启动6379以后变为6380的从节点
看日志是分配6380 是6381的主节点，当6379服务再启动时，已变成从节点
假设6380升级为主节点:进入6380info replication 可以看到role:master
打开sentinel_26379.conf等三个配置，sentinel monitor mymaster 192.168.152.128 6380 2
打开redis6379.conf等三个配置, slaveof 192.168.152.128 6380,也变成了6380
注意：生产环境建议让redis Sentinel部署到不同的物理机上。
a，sentinel节点应部署在多台物理机（线上环境）
b，至少三个且奇数个sentinel节点
c，通过以上我们知道，3个sentinel可同时监控一个主节点或多个主节点
sentinel参考资料：
redis sentinel的机制与用法一：
redis sentinel的机制与用法二：
redis 和 mysql 数据同步问题
结构不同
先讲MySQL，MySQL中一个事务提交之后就永久写入了，同时将事务的操作写入日志。然后，slave从master中请求日志，复制这个事务的操作（注意不是sql语句）。
而Redis的主从同步和数据快照有关，Redis定期将内存中数据作快照保存在文件中，mater只要将文件发送给slave更新就可以了。
MySQL的slave需要请求从从某个事务（就是slave刚完成的那个）开始的所有日志，而redis不需要，slave只要将收到的快照排队，一个一个复制到硬盘、内存就行了。
redis 命令执行过程
redis数据淘汰原理
redis过期数据删除策略
redis server事件模型
redis cluster mget 引发redis源码主从同步的讨论
redis 3.x windows 集群搭建
redis 命令执行过程
redis string底层数据结构
redis list底层数据结构
redis hash底层数据结构
redis set底层数据结构
redis zset底层数据结构
redis 客户端管理
redis 主从同步-slave端
redis 主从同步-master端
redis 主从超时检测
redis aof持久化
redis rdb持久化
redis 数据恢复过程
redis TTL实现原理
redis cluster集群建立
redis cluster集群选主
这篇文章的目的是为redis源码主从同步了描述redis server在处理client命令的执行过程redis源码主从同步，大概包括流程图、源码、以及redis的命令格式说明，redis的通信协议参考自redis的 官网 。
整个redis的server端命令执行过程就如下面这个流程图：
nread = read(fd, c-querybuf+qblen, readlen);负责读取命令数，通过processInputBuffer进行下一步处理。
核心在于processInlineBuffer处理内联命令，processMultibulkBuffer处理批量命令包括get/set等，核心的processCommand用于执行命令。
执行命令的过程其实主要是寻找命令对应的执行函数，通过lookupCommand查找对应的执行命令，通过call执行命令。
负责执行命令 c-cmd-proc 并更新统计信息，执行完成后负责同步数据 propagate 。
主要是负责同步数据到AOF文件和slave节点，feedAppendOnlyFile负责同步到AOF文件，replicationFeedSlaves负责同步
AOF涉及的缓存有多份，包括
包含redis源码主从同步了命令和对应执行函数的映射关系，应该看上去很清晰命令。
协议的一般格式如下，注意前面的*或者$等字符，结尾的\r\n是分隔符。
其中， 回复中的第二个元素为空。
redis主从数据库为什么同步失败
在老版本的MySQL 3.22中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从MySQL 3.23开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。 而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。 当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所 以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单 表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。 而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。
redis cluster集群选主
redis数据淘汰原理
redis过期数据删除策略
redis server事件模型
redis cluster mget 引发的讨论
redis 3.x windows 集群搭建
redis 命令执行过程
redis string底层数据结构
redis list底层数据结构
redis hash底层数据结构
redis set底层数据结构
redis zset底层数据结构
redis 客户端管理
redis 主从同步-slave端
redis 主从同步-master端
redis 主从超时检测
redis aof持久化
redis rdb持久化
redis 数据恢复过程
redis TTL实现原理
redis cluster集群建立
redis cluster集群选主
当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave。Failover的过程需要经过类Raft协议的过程在整个集群内达到一致， 其过程如下：
在作为slave角色节点会定期发送ping命令来检测master的存活性，如果检测到master未响应，那么就将master节点标记为疑似下线。
clusterHandleSlaveFailover执行重新选主的核心逻辑。
clusterHandleSlaveFailover内部通过clusterRequestFailoverAuth方法向集群当中的所有节点发送CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST报文，通知大家slave准备执行failover。
当节点收到超过n/2+1个master的response后即升级为主。
在redis主从选举过程中报文相关的解析逻辑，clusterProcessPacket内部主要处理CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST和CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK报文。
redis cluster集群的源码分析(1)
Redis Cluster 实现细节
