Redis集群模式之主从复制模式（2）
上一篇文章我们主要讲解了什么是主从复制模式，这一篇文章我们结合几个问题来更深入的理解一下主从复制模式。
在主节点服务器不进行持久化时使用主从复制安全吗？
在进行主从复制设置时，强烈建议在主节点服务器上开启持久化，当不这么做时，比如考虑到延迟的问题，应该将实例配置为避免自动重启。
为什么不持久化的主服务器自动重启非常危险呢？为了更好的理解这个问题，下面举一个例子：
首先，我们设置节点A为主服务器，关闭了他的持久化，节点B和节点C设置为从服务器，从节点A复制数据。这时，突然主服务器出现了一个崩溃，但Redis具有自动重启系统，重启了进程，因为关闭了持久化，主节点服务器重启后数据是空的。这时节点B和节点C从节点A之间进行主从复制，B、C节点本来具有数据，但是在主从复制过程中被删除了，数据也变成空的了。
所以，如果数据比较重要，并且在使用主从复制时关闭了主服务器持久化功能的场景中，都应该禁止实例自动重启。
为什么主从全量复制使用RDB而不使用AOF？
首先，前面的文章中我们也介绍了，AOF文件存储的是操作命令，RDB文件存储的是二进制数据，而且还是压缩过的。所以，RDB文件要比AOF文件更小，在执行主从全量复制时，传输RDB文件可以尽量降低对主节点服务器网络带宽的消耗，从节点在加载RDB文件时，由于RDB文件小，并且是二进制形式，所以从节点在读取数据和解析还原数据时都会非常快，所以使用RDB进行主从全量复制的成本比使用AOF低的多。
其次，如果要使用AOF进行全量复制，意味着必须打开AOF功能，打开AOF就要选择文件刷盘策略，选择不当会严重影响Redis的性能。而使用RDB只在需要定时备份和主从全量复制时才会触发生成一次快照。在很多对数据丢失不敏感的业务场景下，其实是不需要开启AOF的。
为什么有无磁盘复制模式？
Redis默认的是磁盘复制模式，但是如果使用的磁盘读写速度比较低的话，这种操作会给主节点服务器带来较大的压力。有了无磁盘复制模式后，主服务器中的子进程直接将RDB通过网络发送给从节点服务器，而不使用磁盘作为中间存储。无磁盘复制模式适用于磁盘读写速度较慢，并且网络较快的场景。
为什么还有从库的从库这种设计？
对于一次全量复制的过程来说，生成RDB文件和传输RDB文件对于主节点服务器是十分耗时的两个操作。如果从节点的数量很多，就意味着一个主节点服务器要承担起所有从服务器的主从复制操作，住节点服务器就会忙于fork子进程来生成RDB文件，而fork子进程的过程中主节点服务器的主进程是会被阻塞的，从而导致了主进程响应后续命令的速度变慢。另外，主节点服务器生成完RDB文件传输时，也会大量占用主节点服务器的网络带宽，给主节点服务器造成很大的压力。
上述的问题就引出了“主-从-从”的设计。这种设计方式将主节点服务器的压力以级联的方式分散到了从节点服务器上。在设计主从集群时，我们可以选择一个内存资源配置比较高的从节点服务器级联其他的从节点服务器，然后我们可以再选择一些从节点服务器，让他们和刚才所选的从节点服务器建立起主从关系。
这样一来，这些从节点就知道，在进行数据同步时，不用再和主节点服务器进行交互了，只要和级联的从节点进行写操作同步就行了，这样一来，主节点服务器的压力也就减少了。
读写分离策略存在设么问题？
①延迟与不一致问题
由于主从复制命令的传播是异步的，所以延迟和数据不一致的问题是不可避免的。如果应用对数据不一致的接受程度较低，可以通过优化主从节点服务器之间的网络环境、监控主从节点的延迟大小（如果延迟过大考虑不从该从节点服务器读取数据）、使用集群同时扩展写负载和读负载等措施。
②数据过期问题
在单机版的Redis中，使用两种过期删除策略，分别是惰性删除和定期删除。在主从复制的场景下，为了主从节点的数据一致性，从节点不会主动删除数据，而是由主节点控制从节点中过期数据的删除。由于主节点的惰性删除和定期删除策略，都不能保证主节点对过期数据的及时删除。因此，当客户端通过从节点读取数据时，很容易读取到过期的数据。
在Redis3.2中，客户端通过从节点读取数据时，增加了对数据是否过期的判断，如果数据过期，则不返回给客户端。
③故障切换问题
在没有使用哨兵模式进行读写分离的场景下，如果主节点服务器出现故障，需要手动切换从节点服务器为主节点服务器，但是这一操作需要手动进行，中间间隔的时间太长，很容易引起整个服务的瘫痪。后面文章要讲到的哨兵模式实现了自动化的主从切换，能够有效解决此问题。
这篇文章我们通过几个问题来深入理解了主从复制模式，也引出了后面文章要讲解的其他Redis集群模式。大家有什么问题或者勘误可以在评论区留言，笔者看到都会回复的。