Redis主从复制

之前没有了解过 Redis中 RDB 和 AOF 的小伙伴，点这里先了解下 RDB 和 AOF

如果 Redis 发生了宕机，它们可以分别通过回放日志和重新读入 RDB 文件的方式恢复数据，从而保证尽量少丢失数据提升可靠性。不过，即使用了这两种方法，也依然存在服务不可用的问题。

比如说，我们在实际使用时，只运行了一个Redis实例，如果这个实例宕机了，它在恢复期间，是无法服务新来的数据存取请求的。那么，我们总说的Redis具有高可靠性，又是什么意思呢？

其实，是有两层含义的

一是数据尽量少丢失

二是服务尽量少中断。

AOF和RDB保证了 数据尽量少丢失，而对于服务尽量少中断，Redis的做法是增加副本冗余量，将一份数据同时保存在多个实例上。即使有一个实例出现了故障，需要过一段时间才能恢复，其他实例也可以对外提供服务，不会影响业务使用。多实例保存同一份数据，听起来好像很不错，但是，我们必须要考虑一个问题。

这么多副本，它们之间的数据如何保持一致呢？数据读写操作可以发给所有的实例吗？

实际上，Redis提供了主从库模式，以保证数据副本的一致，主从库之间采用的是读写分离的方式。

• 读操作：主库、从库都可以接收；
• 写操作：首先到主库执行，然后，主库将写操作同步给从库。

那么，为什么要采用读写分离的方式呢？

你可以设想一下，在上面这张图中，不管是主库还是从库，都能接收客户端的写操作。那么，一个直接的问题就是，如果客户端对同一个数据（例如k1）前后修改了三次，每一次的修改请求都发送到不同的实例上，在不同的实例上执行。那么，这个数据在这三个实例上的副本就不一致了（分别是v1、v2和v3）。

在读取这个数据的时候，就可能读取到旧的值。如果我们非要保持这个数据在三个实例上一致，就要涉及到加锁、实例间协商是否完成修改等一系列操作，但这会带来巨额的开销，当然是不太能接受的。

而主从库模式一旦采用了读写分离，所有数据的修改只会在主库上进行，不用协调三个实例。主库有了最新的数据后，会同步给从库，这样，主从库的数据就是一致的。

那