主从同步原理
- 刚开始 mater 与 salve 数据是不不同步的 过一段时间后就同步了 就是所谓的最终一致性
- 第一次同步 主节点做一次bgsave 同时将后续操作记录到内存buffer中去 待完成后 将rdb文件全量同步到从节点，从节点接收后，将数据加载到内存中，加载完成后，再通知主节点将期间修改的操作以及数据同步到从节点
按照同步内容的多少 分为全同步 与增量同步
全同步
- Slave发送sync命令到Master
- master启动一个后台进程，将redis中的快照数据保存到文件中 就是bgsave
- master将保存快照数据期间接收到的写命令缓存起来
- master完成写文件操作后，将文件发送给savle
- savle接收到新的文件后，使用新的aof文件替换掉旧的aof文件
- master将期间收集的增量命令发送给salve端
全量同步完成后 后续的写命令都是在master上 读命令都是在savle上 读写分离场景 当然 master也可以读 一般为了提升性能 都只写 所以用户的写操作要及时的扩散到savle 以便保持数据最大程度上的同步
增量同步
- master接收到用户的操作命令 判断是否需要传播到salve
- 如果是写命令 追加到aof文件
- 将操作传播到其他savle 1. 对齐主从库 确保数据库是该操作数据库 2. 往相应缓存写入指令
- 将缓存中的数据发送给salve
主从模式的弊端就是 不具备高可用 当master挂掉之后 redis将不能对外提供服务
Redis Sentinel 解决master宕机后主从切换问题 监控：检查主服务器是否运行正常 提醒：通过api向管理员或其他应用程序发送故障通知 自动故障迁移：主从切换
流言协议 Gossip 在杂乱无章中寻求一致
- 每个节点都随机的与对方通信 最终所有节点的状态达成一致
- 种子节点定期随机的向其他节点列表发送节点列表以及需要传播的信息
- 不保证所有信息一定可以传递到所有节点，但是最终会趋于一致
