Redis从出门到高可用–Redis复制原理与优化
单机有什么问题？
1、单机故障;
2、单机容量有瓶颈
3、单机有QPS瓶颈
主从复制：主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。
1、一个master可以有多个slave；
2、一个slaver只能有一个master；
3、数据流向是单向的，master到slave；
主从复制两种实现方式：
1、slaveof命令
取消复制：slavof no one
2、配置
slaveof ip port
slave-read-only yes :实现读写分离
两种方式比较：
方式 slaveof 配置
优点 无需配置 统一配置
缺点 不便于管理 需要重启
实验演示：
修改配置文件：端口分别为6379（master），6380（slave）
分别启动两个redis实例：
1 2 3 4 6379.conf [root@localhost config]# redis-server redis6279.conf [root@localhost config]# redis-cli
1 2 3 4 6380.conf [root@localhost config]# redis-server redis6380.conf [root@localhost config]# redis-cli -p 6380
设置6380为6379的slave：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 127.0.0.1:6380> slaveof 127.0.0.1 6379 OK 127.0.0.1:6380> info replication # Replication role:slave master_host:127.0.0.1 master_port:6379 master_link_status:up master_last_io_seconds_ago:5 master_sync_in_progress:0 slave_repl_offset:29 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
1 2 3 4 5 6 7 8 9 10 127.0.0.1:6379> info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6380,state=online,offset=43,lag=1 master_repl_offset:43 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:42
在6379上执行set操作：
1 2 3 4 127.0.0.1:6379> set k1 1 OK 127.0.0.1:6379> set k2 2 OK
在6380上执行get操作：
1 2 127.0.0.1:6380> get k1 "1"
二、复制的原理 redis全量复制的原理是，首先将master本身的RDB文件同步给slave，而在同步期间，master写入的命令也会记录下来（master内部
有一个复制缓冲区，会记录同步时master新增的写入），当slave将RDB加载完后，会通过偏移量的对比将这期间master写入的值同步给slave。
三、全量复制和部分复制 在介绍全量复制和部分复制和之前，先介run_id和偏移量offset
run_id:
1 2 3 4 [root@localhost config]# redis-cli -p 6379 info server | grep run run_id:9e4f78c64e71ec4201aa5bda334a10f8ccde2aaa [root@localhost config]# redis-cli -p 6380 info server | grep run run_id:c38b9cc14a2c050dd047ae395d23735f72f9105a
偏移量offset：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 slave0:ip=127.0.0.1,port=6380,state=online,offset=1424,lag=1 master_repl_offset:1424 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:1423 [root@localhost config]# redis-cli -p 6379 info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6380,state=online,offset=1438,lag=0 master_repl_offset:1438 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:1437 [root@localhost config]# redis-cli -p 6379 set k3 3 OK [root@localhost config]# redis-cli -p 6379 info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6380,state=online,offset=1480,lag=1 master_repl_offset:1480 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:1479 [root@localhost config]#
复制过程：
全量复制：
全量复制要求 大专栏 Redis从出门到高可用--Redis复制原理与优化 将master的数据同步到slave，同时也要将master新增的数据同步到slave。
1、psync ? 1:第一个参数是runId，第二个参数偏移量，由于第一次同步，slave不知道master的runId和自己的偏移量，所有以？和-1代替，告诉master节点是第一次同步；
2、master接收到1的指令后，知道slave需要进行全量复制，所以将自己的runId和偏移量offset发送给slave
3、save masterInfo : salve保存master的基本信息；
4、master执行bgsave 异步生成RDB文件；
为将将全量数据复制到slave，并且在生成RDB到RDDB文件传输完成过程中新增的数据也传输，master开启子进程来将dataset写入rdb文件（步骤4），同时将子进程完成之
前接收到的写命令缓存到复制缓冲区，即send buffer。
5、master 执行send RDB将master生成的RDB文件传给slave；
6、将复制缓冲区buffer中的增量数据发给slave；
7、清除老数据（slave挂一个新的master时会清除老数据）；
8、slave加载RDB文件和buffer数据；
全量复制开销：
1、master执行bgsave命令的开销；
2、RDB文件网络传输时间；
3、slave节点清除数据的时间；
4、从节点加载RED的时间；
5、可能的AOF重写时间（在slave加载RED文件时）；
增量复制（部分复制）：
值得注意的是，当slave跟master的连接断开时，slave可以自动的重新连接master，在redis2.8版本之前，每当slave进程挂掉重新连
接master的时候都会开始新的一轮全量复制。如果master同时接收到多个slave的同步请求，则master只需要备份一次RDB文件。
上面提到，slave和master断开了、当slave和master重新连接上之后需要全量复制，这个策略是很不友好的，从Redis2.8开始，Redis提供了增量复制的机制：
master除了备份RDB文件之外还会维护者一个环形队列（复制缓冲区，默认大小1M），以及环形队列的写索引和slave同步的全局offset，环形队列用于存储最新
的操作数据，当slave和maste断开重连之后，会把slave维护的offset，也就是上一次同步到哪里的这个值告诉master，同时会告诉master上次和
当前slave连接的master的runid，满足下面两个条件，Redis不会全量复制：
1、slave传递的run id和master的run id一致；
2、master在环形队列上可以找到对呀offset的值。
1、在slave复制master过程中连接断开；
2、主服务器端为复制流维护一个内存缓冲区（in-memory backlog）。主从服务器都维护一个复制偏移量（replication offset）和master run id
3、slave重写连接
4、slave发送自己的runId和offset；
5、假如主从服务器的两个master run id相同，并且指定的偏移量在内存缓冲，复制就会从上次中断的点开始继续。
区中还有效
四、故障处理 主从结构–故障转移
slave宕机
当其中某一个slave发生故障，此时可以将故障机的客户端重新连接到其他的slave上；
master宕机
当master发生故障，首先。master客户端断开与master服务的连接，即执行slaveof no one，然后重新选一个master，其他客户端重新连接到新的master；
但是在实际的生成中，每一秒都是很重要，所以重新连接肯定不是好的选择，即，主从复制其实并没有真正的解决redis高可用问题。
五、开发运维常见问题 1、读写分离 读流量分摊到从节点
问题：
复制数据延迟：由于对master的写的数据复制到slave需要时间，或者slave发生阻塞；
读写分离时，master会异步的将数据复制到slave，如果这是slave发生阻塞，则会延迟master数据的写命令，造成数据不一致的情况
解决方法：可以对slave的偏移量值进行监控，如果发现某台slave的偏移量有问题，则将数据读取操作切换到master，但本身这个监控开销比较高，所以关于这个问题，大部分的情况是可以直接使用而不去考虑的
读到过期数据：我们知道redis在删除过期key的时候，是有两种策略，第一种是懒惰型策略，即只有当redis操作这个key的时候，发现这个key过期，就会把这个key删除
。第二种是定期采样一些key进行删除。
针对上面说的两种过期策略，会有个问题，即如果我们过期key的数量非常多，而采样速度根本比不上过期key的生成速度时会造成
很多过期数据没有删除，但在redis里master和slave达成一种协议，slave是不能处理数据的（即不能删除数据）而我们的客户端没
有及时读到到过期数据，并将master将key删除的命令同步给slave，就会导致slave读到过期的数据（这个问题已经在redis3.2版本
中解决）
从节点故障，如何将从节点进行迁移；
2、主从配置不一致 这个问题一般很少见，但如果有，就会发生很多诡异的问题
1、例如maxmemory不一致，这个会导致数据的丢失；
原因：例如master配置4G，slave配置2G，这个时候主从复制可以成功，但，如果在进行某一次全量复制的时候，slave拿到master的
RDB加载数据时发现自身的2G内存不够用，这时就会触发slave的maxmemory策略，将数据进行淘汰。更可怕的是，在高可用的集群环
境下，如果我们将这台slave升级成master的时候，就会发现数据已经丢失了
2、数据结构优化参数不一致（例如hash-max-ziplist-entries）：这个就会导致内存不一致
原因：例如在master上对这个参数进行了优化，而在slave没有配置，就会造成主从节点内存不一致的诡异问题。
3、规避全量复制 1、第一次全量复制：
当我们某一台slave第一次去挂到master上时，是不可避免要进行一次全量复制的，那么，我们如何去想办法降低开销呢？
方案1：小主节点，例如我们把redis分成2G一个节点，这样一来，会加速RDB的生成和同步，同时还可以降低我们fork子进程的开销（
master会fork一个子进程来生成同步需要的RDB文件，而fork是要拷贝内存快的，如果主节点内存太大，fork的开销就大）。
方案2：既然第一次不可以避免，那我们可以选在集群低峰的时间（凌晨）进行slave的挂载。
2.节点RunID不匹配
例如我们主节点重启（RunID发生变化），对于slave来说，它会保存之前master节点的RunID，如果它发现了此时master的RunID发生
变化，那它会认为这是master过来的数据可能是不安全的，就会采取一次全量复制
解决办法：对于这类问题，我们只有是做一些故障转移的手段，例如master发生故障宕掉，我们选举一台slave晋升为master（哨兵或集群）
3.复制积压缓冲区不足
master生成RDB同步到slave，slave加载RDB这段时间里，master的所有写命令都会保存到一个复制缓冲队列里（如果主从直接网络抖
动，进行部分复制也是走这个逻辑），待slave加载完RDB后，拿offset的值到这个队列里判断，如果在这个队列中，则把这个队列从
offset到末尾全部同步过来，这个队列的默认值为1M。而如果发现offset不在这个队列，就会产生全量复制。
解决办法：增大复制缓冲区的配置 rel_backlog_size 默认1M，我们可以设置大一些，从而来加大我们offset的命中率。
这个值，我们可以假设，一般我们网络故障时间一般是分钟级别，那我们可以根据我们当前的QPS来算一下每分钟可以写入多少字节，再乘以我们可能发生故障的分钟就可以得到我们这个理想的值。
4、规避复制风暴 什么是复制风暴？举例：我们master重启，其master下的所有slave检测到RunID发生变化，导致所有从节点向主节点做全量复制。尽
管redis对这个问题做了优化，即只生成一份RDB文件，但需要多次传输，仍然开销很大。
1.单主节点复制风暴：主节点重启，多从节点全量复制
解决：更换复制拓扑如下图：
（1）.我们将原来master与slave中间加一个或多个slave，再在slave上加若干个slave，这样可以分担所有slave对master复制的压力。
（这种架构还是有问题：读写分离的时候，slave1也发生了故障，怎么去处理？）
（2）.如果只是实现高可用，而不做读写分离，那当master宕机，直接晋升一台slave即可。
2.单机器复制风暴：机器宕机后的大量全量复制，如下图：
当machine-A这个机器宕机重启，会导致该机器所有master下的所有slave同时产生复制。（灾难）
（1）.主节点分散多机器（将master分散到不同机器上部署）
（2）.还有我们可以采用高可用手段（slave晋升master）就不会有类似问题了。
