Redis的复制原理及优化

一、单机有什么问题？

单机即在一台机器上部署一个redis节点，主要会存在以下问题：

如果发生机器故障，例如磁盘损坏，主板损坏等，未能在短时间内修复好，客户端将无法连接redis。

当然如果仅仅是redis节点挂掉了，可以进行问题排查然后重启，姑且不考虑这段时间对外服务的可用性，那还是可以接受的。

而发生机器故障，基本是无济于事。除非把redis迁移到另一台机器上，并且还要考虑数据同步的问题。

假如一台机器是16G内存，redis使用了12G内存，而其他应用还需要使用内存，假设我们总共需要60G内存要如何去做呢，是否有必要购买64G内存的机器？

redis官方数据显示可以达到10w的QPS，如果业务需要100w的QPS怎么去做呢？

关于容量瓶颈和QPS瓶颈是redis分布式需要解决的问题，而机器故障就是高可用的问题了

如图所示左边是Master节点，右边是slave节点，即主节点和从节点。从节点也是可以对外提供服务的，主节点是有数据的，从节点可以通过复制操作将主节点的数据同步过来，并且随着主节点数据不断写入，从节点数据也会做同步的更新。

整体起到的就是数据备份的效果。

除了作为数据备份，主从模型还能做另外一个功能，就是读写分离。
让master节点负责提供写服务，而将数据读取的压力进行分流和负载，分摊给所有的从节点。

主从复制的作用

如图，想让6380节点成为6379的从节点，只需要执行 slaveof 命令即可，此复制命令是异步进行的，redis会自动进行后续数据复制的操作。
注：<mark>一般生产环境不允许主从节点都在一台机器上，因为没有任何的价值。</mark>

如果6380节点不希望成为6379的从节点，可以执行 slave of on one 命令，取消后6380节点的数据不会被清除，只是说后续6379节点新写入的数据不会再同步到该节点了。

注意：<mark>如果取消复制后想slave一个新的主节点，新的主节点在同步给slave节点数据时，会先将从节点的数据全部清除</mark>

# 配置主节点的IP和端口号
slaveof ip port
 # 从节点只做读的操作，保证主从数据的一致性
slave-read-only yes

全量复制主节点会将RDB文件也就是当前状态去同步给slave，在此期间主新写入的命令会单独记录起来，然后当RDB文件加载完毕之后

实际上全量复制的开销是非常大的，主要体现在如下方面

假如master和slave网络发生了抖动，那一段时间内这些数据就会丢失，对于slave来说这段时间master更新的数据是不知道的

解决：

如果发生了抖动，相当于连接断开了
主会将写命令记录到缓冲区，repl_back_buffer
当slave再次去连接master时候，就是说网络抖动结束之后，会触发增量复制
从会执行pysnc命令，将当前自己的offset和主的runid传递给master
如果发现传输的offset偏移量是在buffer内的，不在期间内就证明你已经错过了很多数据，buffer也是有限的，默认是1M，会将offset开始到队列结束的数据同步给从。这样master和slave就达到了一致