一. 数据库之间数据同步
mysql 两种集群同步方式:
Replication 同步方式 特点: 弱一致性、速度快、低价值,适合日志新闻帖子等。 PXC 同步方式 特点: 强一致性、速度慢、高价值,适合订单、账户、财务等。
Replication 介绍:Master 写,slave 读,单项操作。
基本流程: sql-thread 可能是多线程。主备切换时,计划外切换先让备库获取中继日志relay-log,选择并设置新主库,查找其他从库上复制事件在新主库上二进制坐标,在新从库上重置复制,按上一步获得的二进制坐标连接主库,启动新复制。 计划内重置也是先校验备库是否执执行完中继日志,然后切换备库连接,设置新主库 set global readonly。
bin-log 语句分为 row(记录每一条记录) 和 statement(记录操作语句),前者小数据量占优,后者大数据量占优。
PXC 介绍:彻底兼容 mysql ,同步流程与 Seata 类似。
基本流程: 就是在 commit 的时候,获取全局事务 gtID,然后分别确认,如果 anther server 没有确认成功,则被剔除出集群。
主从复制详细博客
二. redis 集群之间数据同步
redis 架构方式主要有 : master/slave、哨兵、集群方式。
master/slave:主从之间数据复制有全量复制,即在从节点请求时主节点把 rdb 或者 aof 文件发送给从节点。 在主从连接期间,尚未断联太久时(命令长度未超过 repl-backlog-length 时),主从之间发送请求的命令,采用增量复制。
哨兵:解决主从架构时主节点宕机后需要人工干预问题。主要通过引入 sentinal 哨兵提供监控、提醒、自动故障迁移功能。哨兵节点不存储数据,
哨兵模式在故障切换时,单个哨兵先进性主观下线判断,再请求其他哨兵节点,如果超过 quorum(一般是哨兵节点数量的一半+1),则视为客观下线,然后投票选出新主节点,执行故障转移。
集群模式:解决单个节点写能力、存储能力受到单机限制,动态扩容复杂问题,引入多主多从架构,从节点为主节点的备节点。
主从和哨兵时,数据存储在一个节点,其他节点进行复制,集群才用 虚拟哈希槽分区 的方式,Hash_slot = CRC(key) % 16384,每个节点负责一部分槽以及槽所映射的键值数据。扩缩容后,槽需要重新分配,节点数据也要重新迁移,服务不需要下线。
redis 架构博客
三. 注册中心之间数据同步
数据中心中心之间的同步,就比较容易理解一点了,mysql 和 redis 多多少少都根据自身功能进行定制化数据同步规则,比较难以理解,也比较复杂,数据中心提供的功能较为简单,所以数据同步也比较简单。
一致性基本可以分为两家:一种是基于 leader 的非对等部署的单点写一致性,一种是对等部署的多写一致性。
eureka Renew 机制: 启动时:把自身当作 client 向其他 server 注册, 获取注册信息。 数据变更时:把自身信息同步到其他 server。
同步时如果接受其他 server 同步的变更信息再同步回其他 server ,就会产生死循环,在消息头中增加 HEADER_REPLICATION 来说明这是一个复制请求。
数据同步时冲突问题,使用版本号字段 lastDirtyTimestamp 字段来解决冲突,a 请求 b 的数据时(如 renew),如果 a 比 b 新,b 返回 404 ,a 向 b 注册这个应用实例,反过来,b返回 409,返回中带有 InstanceInfo,a 会 register 新数据。
eureka之间数据同步博客
zookeeper zab 协议和 Paxos 协议类似,zab 目的为了高可用数据同步系统,paxos 为了构造一致性状态机。主要步骤有崩溃恢复和消息广播,用来做客户端提交数据时同步和 leader 崩溃时自动选举恢复服务。 和 raft 类似。
nacos:之间数据同步有两种方式,一种是简化的 raft 和 distro。前者是强一致性协议,follow 半数同意即返回,后者是类似 eureka,注重高可用。nacos 更推荐 distro ,因为在注册中心场景下,有 renew 机制,第一次注册的成功率就不是十分关键,此时强一致性协议的单点瓶颈就比较突出了。
四. 消息中间件之间数据同步
rocketmq 提供了好几种消息同步方式,最新版也是通过简化 raft 实现故障转移,提供高可用特性。
rocketmq故障转移
kafka 基于 zookeeper 作为协调者,在 leader 故障的时候,选出消息完备的 ISR 作为 新leader。消费者故障,会把分区分配给组内其他消费者,broker 故障会将持有的分区主导权分配给其他 leader。
kafka故障转移
五. 总结
数据同步和故障转移,成熟的中间件都基于自身业务场景对协调算法进行了优化,这里总结的比较粗糙,后续优化。
|