中间件集群之间数据同步和故障转移

赵润泽同学

已于 2022-03-20 20:19:20 修改

阅读量1.8k

点赞数

分类专栏：中间件分析文章标签： java

于 2022-03-20 20:18:39 首次发布

本文链接：https://blog.csdn.net/qq_37804737/article/details/123613109

版权

中间件分析专栏收录该内容

6 篇文章 0 订阅

订阅专栏

一. 数据库之间数据同步

mysql 两种集群同步方式：

Replication 同步方式
特点：弱一致性、速度快、低价值，适合日志新闻帖子等。
PXC 同步方式
特点：强一致性、速度慢、高价值，适合订单、账户、财务等。

Replication 介绍：Master 写，slave 读，单项操作。

基本流程：
sql-thread 可能是多线程。主备切换时，计划外切换先让备库获取中继日志relay-log，选择并设置新主库，查找其他从库上复制事件在新主库上二进制坐标，在新从库上重置复制，按上一步获得的二进制坐标连接主库，启动新复制。
计划内重置也是先校验备库是否执执行完中继日志，然后切换备库连接，设置新主库 set global readonly。

bin-log 语句分为 row（记录每一条记录）和 statement（记录操作语句），前者小数据量占优，后者大数据量占优。

PXC 介绍：彻底兼容 mysql ，同步流程与 Seata 类似。

基本流程：
pxc事务流程
就是在 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 机制，第一次注册的成功率就不是十分关键，此时强一致性协议的单点瓶颈就比较突出了。