主从同步

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

CAP原理

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

• 如上图说明，我们可以总结CAP原理：当网络分区发生时候，一致性和可用性两难全。

最终一致性

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

主从同步与从从同步

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

增量同步

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

快照同步

• 快照同步恒耗时，好资源

1. 在主节点执行bgsave，将当前内存数据load到磁盘快照文件
2. 将快照文件通过网络传输到从节点
3. 从节点接收快照文件后，先清空内存，然后立即执行一次全量加载
4. 加载完快照后继续增量同步buffer数据。

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

无盘复制

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

更变态的方式

• Redis的主从复制是异步，我们可以通过wait指令，让异步变同步，确保强一致性。如下

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

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

上一篇：Redis存储优化–小对象压缩

下一篇：Redis服务信息–Info指令