Redis主节点挂掉时，运维可以让从节点来接管，服务就可以继续，否则线上业务就需要很长时间才能恢复。没有Redis集群，起码要配备Redis主从，否则线上服务的风险就会比较大。
【CAP原理】
CAP原理是分布式领域的理论基石。C-Consistent,A-Availability,P-Partition tolerance。
分布式系统的节点在不同的机器上通过网络进行信息互通，这会有网络断开的风险，这个网络断开的场景叫做网络分区。发生网络分区时，两个节点的数据修改无法同步，所以一致性就无法实现，除非我们关停一个服务，只让其中一个服务对外提供访问，也就是牺牲可用性。所以在网络分区发生时，一致性和可用性只能二选一。
【Redis的最终一致性】
Redis的主从数据是异步同步的，也就是主从节点的数据会存在一个状态差，所以Redis系统不满足一致性要求。但即使在主从网络断开时，主节点还是可以正常对外提供修改服务，所以Redis满足可用性。
Redis保证最终一致性，即使主从网络断开，数据出现大量不一致，但一旦网络恢复，从节点会采用多种策略努力追赶，尽力保持和主节点一致。
【主从同步与从从同步】
Redis同步支持主从与从从同步。这里统一理解为主从同步。
【增量同步】
Redis同步的是指令流，主节点将那些对自己的状态产生修改性影响的指令记录在本地内存buffer中，然后异步将buffer中的指令同步到从节点，从节点一边执行同步的指令，一边向主节点反馈自己同步到哪里了（偏移量），这里应该就和AOF中的指令一样的。
但是与AOF不同，这里的指令集合是记录在内存中的，内存容量有限，所以Redis设置了一个缓冲区，即一个数组，当数组指令存满之后，主节点就会从头覆盖前面的内容。
也就是说，从节点不断地根据这个指令流来修改自己的数据状态，但如果发生了网络分区，就有可能出现指令没有传到从节点就被覆盖的情况，此时就要使用快照同步。
【快照同步】
主节点发现反馈回来的偏移量被覆盖之后，进行一次bgsave，将内存数据存入磁盘文件，然后再将文件内容传送给从节点，从节点立即进行一次全量加载，加载完毕后通知主节点继续进行增量同步。
如果从节点加载数据的过程中，主节点的增量指令又被覆盖，那会再次发起快照同步。在一些事务性操作密集高频的场景下，极有可能陷入死循环。
在增加从节点时，它必须先进行一次快照同步，同步完成之后再继续进行增量同步。
【无盘复制】
主节点进行快照同步时，会进行耗时的IO操作，整个过程会对系统的负载产生较大影响。
从Redis2.8.18开始，Redis支持无盘复制，即主服务器直接通过套接字将快照内容发送给从节点，生成快照的过程中，就一边序列化，一边将序列化的内容发送到从节点，从节点还是跟之前一样，先将接收到的内容存储到磁盘，再进行一次性加载。
【wait指令】
Redis复制是异步进行的，wait可以让异步复制变为同步，确保系统的强一致性。
wait N t #N表示从节点的数量，t以毫秒为单位。表示等待wait指令之前所有写操作同步到N个从节点，最多等待t时间，如果t=0，表示无限等待N个从节点同步完成。
但如果此时发生网络分区，主节点无法收到从节点的反馈，那么wait指令会永远阻塞。
【小结】
如果只是用Redis做缓存，也就不需要从节点备份，挂掉重启就行。但只要使用了Redis的持久化功能，就必须认真对待主从复制，保证数据安全。
【参考】
《Redis深度历险 核心原理与应用实践》