Redis高可用基石--主从同步

最新推荐文章于 2023-07-03 20:43:38 发布

生病的毛毛虫

最新推荐文章于 2023-07-03 20:43:38 发布

阅读量106

点赞数

分类专栏： redis 文章标签： redis

本文链接：https://blog.csdn.net/liaojiamin0102/article/details/109692068

版权

16 篇文章 1 订阅

订阅专栏

当我们将Redis用于线上环境，单机肯定是不行的，即使不做集群，我们也应该做主从，有了主从，当主节点（master）挂掉时候，让运维将从节点（slave）接管，服务可以继续，否则主节点宕机后重启恢复数据的一段时间很长，期间无法提供服务。
讨论主从同步之前，我们必须先了解一下先到分布式系统理论的基础-------CAP理论

CAp原理好比分布式领域的基础定律，他分别制定如下三个方面
- C：Consistent，一致性
- A：Availability，可用性
- P：Partition tolerance，分区容错性
分布式系统中我们的机器一般都不可能在同一个机房，因为如果断电，那就图团灭了，这就意味着我们需要部署多机房，甚至不同地域，通过网络进行通讯，这个网络就有断开的风险，这种网络断开的场景就叫网络分区
我们通过下图演示，网络分区时候，两个分布式节点之间无法通讯，对一个节点操作无法同步，所有数据一致性无法保证
此时要保证分布式节点数据一致，我们只能牺牲可用性，我们先暂停对外服务，等节点恢复，同步完在说。

在这里插入图片描述

Redis主从数据是异步同步的，所有分布式Redis系统并不满足一致性，Client端修改Redis之后会立刻返回，然后主动从网络异步同步，所以计算主从网络断开，还是可以对外服务，所以Redis此时满足可用性。
Redis保证最终一致性：从节点通过异步同步，经一段时间后追赶上主节点，最终主从一直，即使网络断开时候不一致，等恢复在同步还是最终可以一致。

Redis可能有多个从节点，并不是每个从节点都和主节点通讯同步数据，因为这样会导致主节点压力过大，从节点直接直接进行数据同步，也可以达到最终一致性，减少主节点的负担。

Redis同步的是指令流，主节点将对自己状态修改的指令记录在内存buffer，异步将buffer中指令同步从节点，从节点一边执行同步的指令流来达到主节点一样的状态，一边向主节点反馈自己同步到哪里的偏移量。
因为内存buffer优先，Redis主节点不能将所有记录同时放buffer中。Redis内存buffer是一个定长换线数组，容量满了就覆盖之前的内容。
问题：如果网络不好，从节点无法段时间同步buffer中数据，网络恢复后buffer中可能已经被覆盖了好几遍了，那么将会丢失很多数据，无法通过同步buffer指令进行同步，这个时候，需要用到更加复杂的同步机制----快照同步。

问题：整个快照同步过程，主节点的增量信息还是通过复制buffer，如果快照同步时间太久，导致buffer的复制还是被覆盖，这样会导致快照同步完成后还是无法增量复制，就会再次发起快照同步，依次死循环。
解决方法，将buffer的大小配置一个合理的大小，避免快照复制的死循环。

因为bgsave的时候，进行恒耗时的文件IO，在非SSD磁盘存储时候，快照同步会对系统负载产生较大影响。
Redis同步方法还有另一个方式，无盘复制：
- 在生成快照的时候就是遍历主节点的一个过程，主节点一边遍历内存，一边将序列化后的内容直接通过socket发送到从节点，从节点将接受到内容存储到磁盘文件，在进行一次性加载。

新docker-redis:0>wait 1 10
"0"

wait命令提供两个参数，第一个需要同步的从节点数量N，第二个时间T，毫秒为单位，如下含义
- wait指令之前的所有操作同步到N个节点，最多等待时间t，如果t=0，表示无线等待直到完成。
- 如果出现网络分区，wait第二个参数时间t=0，主从同步无法继续进行，wati指令永远阻塞，Redis丧失可用性。