本章重点回顾
1.Redis通过复制功能实现主节点的多个副本。从节点可灵活地通过slaveof命令建立或者断开复制流程。
2.复制支持树状结构，从节点可以复制另一个从节点，实现一层层向下的复制流。Redis2.8之后复制的流程分为：全量复制和部分复制。全量复制需要同步全部主节点的数据集合，大量消耗机器和网络资源。而部分复制有效减少因为网络异常等原因造成的不必要全量复制情况。通过配置合理的复制积压缓冲区尽量避免全量复制。
采用树形结构降低多个从节点对主节点的消耗
全量复制运行流程
部分复制流程图
3.主从节点之间维护心跳和偏移量检查机制，保证主从节点通信正常和数据一致。
4.Redis为了保证高性能复制过程是异步的，写命令处理完后直接返回给客户端，不等待从节点复制完成。因此从节点数据集会有延迟情况。
5.当使用从节点用于读写分离时，会存在数据延迟、过期数据、从节点可用性等问题，需要根据自身业务提前做出规避。
6.在运维过程中，主节点存在多个从节点或者一台机器上部署大量主节点的情况下，会有复制风暴的风险。
读写分离产生的问题
复制数据延迟问题
Redis复制数据的延迟由于异步复制特性是无法避免的，延迟取决于网络带宽和命令阻塞情况，比如刚在主节点写入数据后立刻在从节点上读取可能获取不到。需要业务场景允许短时间内的数据延迟。对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟大的时候出发报警或者通知客户端避免读取延迟过高的从节点
主节点偏移量在info replication的mater_repl_offset 从节点可以查询主节点的slave0字段的offset指标 差值就是主从节点延迟的字节量
超过10MB 触发程序并通知客户端从节点延迟过高。可以采用zookeeper的监听回调机制实现客户端通知。
客户端接到具体的从节点高延迟通知后，修改读命令路由到其他从节点或者主节点上。延迟恢复后，再次通知客户端，恢复从节点的读命令请求。
读到过期的数据
主节点存储大量超时数据时候，如缓存数据，Redis内部需要维护过期数据删除策略：
惰性删除
主节点惰性删除过期键同步给从节点
为了保证数据的一致性，从节点永远不会主动删除超时数据
定时删除
主节点在内部定时任务会循环采样一定数量的键，当发现采样的键过期时执行del命令，之后再同步给从节点
如果此时数据大量超时，主节点采样速度跟不上过期速度且主节点没有读取过期键的操作，那么从节点将无法收到del命令。这时在从节点上可以读到已经超时的数据。Redis3.2版本解决了这个问题，从节点读取数据之前会检查键的过期时间来决定是否返回数据，可以升级到3.0版本来规避这个问题。
从节点故障问题
需要客户端维护可用从节点列表，当从节点故障时候立刻切换到其他从节点或者主节点上。使用Redis做读写分离存在一定的成本。Redis本身的性能非常高，开发人员在使用额外的从节点提升读性能之前，尽量在主节点上做充分优化，比如解决慢查询，持久化阻塞，合理应用数据结构等，当主节点优化空间不大时候再考虑。可以尝试考虑Redis Cluster等分布式解决方案，这样不止扩展了读性能还可以扩展写性能和可支撑数据规模，并且一致性和故障转移也可以得到保证，对于客户端的维护逻辑也相对容易。
规避全量复制
1. 第一次建立复制：由于是第一次复制，从节点不包含任何主节点数据，因此必须进行全量复制才能完成数据同步。对于这种情况是无法避免的。当对数据量较大切流量较高的主节点添加从节点时候，建议在低峰时候进行操作，或者尽量规避使用大数据量的Redis节点。
2.节点运行ID不匹配：当主从复制关系建立以后，从节点会保存主节点的RUNID，如果此时主节点因为故障重启，那么它的RUNID会改变，从节点发现主节点RUNID不匹配时候，会认为自己复制的是一个新的主节点从而进行全量复制。对于这种情况应该从架构上规避，比如提供故障转移功能。当主节点发生故障后，手动提升从节点为主节点或者采用支持自动故障转移的哨兵或者集群方案
3.复制积压缓冲区不足：主从节点网络中断后，从节点再次脸上主节点时会发送psync offset runId 请求部分复制，如果请求的偏移量不在主节点的积压缓冲区中，则无法提供给从节点数据，因此部分复制会退化为全量复制。 根据网络中断时长，写命令数据量分析出合理的积压缓冲区大小。网络中断一般有闪断，机房割接，网络分区等情况。这时，网络中断一般再分钟级。写命令数据量可以统计高峰期主节点每秒info replication 的master_repl_offset 差值获取 (write_size_per_minute) 。积压缓冲区默认为1MB，对于大流量场景显然不够，这时需要增大积压缓冲区，保证repl_backlog_size > net_break_time * write_size_per_minute
规避复制风暴
1.单节点复制风暴
一般发生在主节点挂在在多个从节点的场景。 当主节点重启恢复后，从节点会发起全量复制流程，这时主节点就会为从节点创建RDB快照，如果在快照创建完毕之前，有多个从节点都常识与主节点进行全量同步；那么其他从节点将共享这份RDB快照。Redis做了优化，有效减免了创建多个快照。但是，同时向多个从节点发送RDB快照。可能使得主节点的网络带宽消耗严重，造成主节点的延迟变大，极端情况会发生主从节点链接断开，导致复制失败。
解决方案首先可以减少主节点挂在从节点的数量，或者采用树状复制结构，加入中间层从节点来保护主节点
事情都有两面性，虽然网络开销交给位于中间层的从节点，而不必消耗顶层的主节点。但是这种结构带来了运维的复杂性 ，增加了手动和自动处理故障转移的难度。
2.单机器复制风暴
Redis是单线程架构，通常单台机器会部署多个Redis示例。当一台机器上同时部署多个主节点
如果出现故障或者网络长时间终端，当她重启恢复后，会有大量从节点针对这台机器的主节点进行全量复制，造成带宽耗尽。
避免方式：
主节点尽量分散在多台机器上 避免单台机器上部署过多的主节点。
当主节点所在机器故障后提供故障转移机制，避免机器恢复后进行密集的全量复制。