读写分离概述：
读流量分摊到从节点上。这是个非常好的特性，如果一个业务只需要读数据，那么我们只需要连一台 slave 从机读数据。
虽然读写有优势，能够让读这部分 分配给各个 slave 从机，如果不够，直接加 slave 机器就好了。但是也会出现以下问题：
1、复制数据延迟
可能会出现 slave 延迟导致读写不一致等问题，当然你也可以使用监控偏移量 offset，如果 offset 超出范围就切换到 master 上，逻辑切换，而具体延迟多少，可以通过 info replication 的 offset 指标进行排查。
对于无法容忍大量延迟场景，可以编写外部监控程序（比如consul）监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点
例子：模拟网络延迟（只写一下步骤，不做模拟并截图了，感兴趣的自己试一下）
#使用redis镜像创建一台新的redis从节点服务器``docker run --privileged -itd --name redis-slave2 --net mynetwork -p 6390:6379 --ip 172.10.0.4 redis
注：--privileged 让docker容器将拥有访问主机所有设备的权限
通过linux下的控流工具，模拟网络延迟，用代码模拟下，因为对于网络的操作属于特殊权限所以需要添加 --privileged 参数
#安装linux下的控流工具，使用他来模拟网络延迟``yum ``install` `iproute
配置延迟5s（秒）
#进入redis-slave2容器里面``docker ``exec` `-itd redis-slave2 ``bash` `#配置这台服务器的网络延迟5秒钟``tc qdisc add dev eth0 root netem delay 5000ms` `#然后你可以使用swoole的定时器来检测查看结果` `#删除延迟网络服务器的命令如下：``tc qdisc del dev eth0 root netem delay 5000ms
注意：这个配置网络延迟不要乱用。。特别是生产环境。。。。。。
同时从节点的slave-serve-stale-data参数也与此有关，它控制这种情况下从节点的表现：如果为yes（默认值），则从节点仍能够响应客户端的命令；如果为no，则从节点只能响应info、slaveof等少数命令。该参数的设置与应用对数据一致性的要求有关；如果对数据一致性要求很高，则应设置为no。
只有N个从节点链接的时候才允许写入：
Redis 2.8以后，可以设置主节点只有在有N台从节点链接的时候可以写入请求。然而，因为Redis使用的是异步复制，所以没有办法保证从节点确实收到的给定的写入请求，所以存在一个窗口期的数据丢失的可能性。
接下来是解释这个特性是如何工作的：
从节点每秒钟都会ping主节点，告知它所有的复制流工作了。
主节点会记住从每个从节点收到的最新的ping
用户可以给主节点配置一个在等于从节点的数量的最低值和不超过最高值之间的延迟
如果至少有N个从节点，如果少于延迟M秒，则写入将被接受。
你可能觉得经最大努力保证数据安全的机制，虽然数据一致性无法保证，但是至少只是几秒的时间窗口内丢失数据。通常情况下范围数据丢失可比无范围数据丢失好多了。
如果条件不满足，主节点将会返回一个错误，并且写入请求将不被接受
主机配置两个参数：min-slaves-to-write <number of slaves>min-slaves-max-lag <number of seconds>
如何选择，要不要读写分离？
没有最合适的方案，只有最合适的场景，读写分离需要业务可以容忍一定程度的数据不一致，适合读多写少的业务场景，读写分离，是为了什么？主要是因为要建立一主多从的架构，才能横向任意扩展slave node去支撑更大的读吞吐量。
2、从节点故障问题
对于从节点的故障问题，需要在客户端维护一个可用从节点列表，当从节点故障时，立刻切换到其他从节点或主节点。
3、配置不一致
主机和从机不同，经常导致主机和从机的配置不同，并带来问题。
①、数据丢失：
主机和从机有时候会发生配置不一致的情况，例如 maxmemory 不一致，如果主机配置 maxmemory 为8G，从机 slave 设置为4G，这个时候是可以用的，而且还不会报错。但是如果要做高可用，让从节点变成主节点的时候，就会发现数据已经丢失了，而且无法挽回。
4、避免全量复制
全量复制指的是当 slave 从机断掉并重启后，runid 产生变化而导致需要在 master 主机里拷贝全部数据。这种拷贝全部数据的过程非常耗资源。
全量复制是不可避免的，例如第一次的全量复制是不可避免的，这时我们需要选择小主节点，且maxmemory 值不要过大，这样就会比较快。同时选择在低峰值的时候做全量复制。
造成全量复制的原因：
①、一是主从机的运行 runid 不匹配。解释一下，主节点如果重启，runid 将会发生变化。如果从节点监控到 runid 不是同一个，它就会认为你的节点不安全。当发生故障转移的时候，如果主节点发生故障，那么从机就会变成主节点。****
②、复制缓冲区空间不足，比如默认值1M，可以部分复制。但如果缓存区不够大的话，首先需要网络中断，部分复制就无法满足。其次需要增大复制缓冲区配置（relbacklogsize），对网络的缓冲增强。参考之前的说明。
****
该如何解决呢？
在一些场景下，可能希望对主节点进行重启，例如主节点内存碎片率过高，或者希望调整一些只能在启动时调整的参数。如果使用普通的手段重启主节点，会使得runid发生变化，可能导致不必要的全量复制！****
为了解决这个问题，Redis提供了debug reload的重启方式：重启后，主节点的runid和offset都不受影响，避免了全量复制。
5、复制风暴
当一个主机下面挂了很多个 slave 从机的时候，主机 master 挂了，这时 master 主机重启后，因为 runid 发生了变化，所有的 slave 从机都要做一次全量复制。这将引起单节点和单机器的复制风暴，开销会非常大。
如何解决呢？
可以采用树状结构降低多个从节点对主节点的消耗
从节点采用树状树非常有用，网络开销交给位于中间层的从节点，而不必消耗顶层的主节点。但是这种树状结构也带来了运维的复杂性，增加了手动和自动处理故障转移的难度。
6、单机器的复制风暴
由于 Redis 的单线程架构，通常单台机器会部署多个 Redis 实例。当一台机器（machine）上同时部署多个主节点（master）时，如果每个 master 主机只有一台 slave 从机，那么当机器宕机以后，会产生大量全量复制。这种情况是非常危险的情况，带宽马上会被占用，会导致不可用。
如何解决呢？
应该把主节点尽量分散在多台机器上，避免在单台机器上部署过多的主节点。****
当主节点所在机器故障后提供故障转移机制，避免机器恢复后进行密集的全量复制
