如何控制主从架构的数据一致性？

胡弦，视频号2023年度优秀创作者，互联网大厂P8技术专家，Spring Cloud Alibaba微服务架构实战派(上下册)和RocketMQ消息中间件实战派(上下册)的作者，资深架构师，技术负责人，极客时间训练营讲师，四维口袋KVP最具价值技术专家，技术领域专家团成员，2021电子工业出版社年度优秀作者，获得2023电子工业出版技术成长领路人称号，荣获2024年电子工业出版社博文视点20周年荣誉专家称号，2024电子工业出版社年度优秀作者。

目录

1.概要设计

1.1 数据库层面的解决方案

1.1.1 设置数据库主从同步方式

1.1.2 强制读主

1.1.3 使用数据库中间件

1.1.4 缓存记录写key法

1.2 Redis主从架构的特定解决方案

1.2.1 主节点作为唯一写入点

1.2.2 同步复制

1.2.3 自动故障转移

1.2.4 最后写入优先（LWW）

1.2.5 确保多数投票

1.2.6 读写分离

1.2.7 一致性哈希

1.3 其他优化措施

1.3.1 优化硬件和文件系统

1.3.2 调整数据库配置

1.3.3 使用GTID复制模式

2.哪些数据库中间件可以实现主从同步？

2.1 MySQL相关中间件

2.1.1 Canal

2.1.2 DBSyncer

2.1.3 MaxScale

2.1.4 MHA

2.2 通用数据库中间件

2.2.1 Otter

2.2.2 Debezium

3.开源的主从复制框架有哪些？

3.1 数据库自带的主从复制功能

3.1.1 MySQL主从复制

3.1.2 Redis主从复制

3.2 专门的数据库中间件

3.2.1 Canal

3.2.2 Otter

3.2.3 Maxwell

3.2.4 Debezium

3.3 其他相关工具和框架

3.3.1 SymmetricDS

3.3.2 Talend

3.4 选择和考虑因素

---

控制主从架构的数据一致性是一个复杂但至关重要的任务，特别是在分布式系统中。以下是一些控制主从架构数据一致性的方法。

1.概要设计

1.1 数据库层面的解决方案

1.1.1 设置数据库主从同步方式

（1）异步复制：这是数据库默认的复制方式，主库在执行完客户端提交的事务后，会立即将结果返回给客户端，并不关心从库是否已经接收并处理。这种方式性能较高，但数据一致性较差。

（2）半同步复制：主库在执行完客户端提交的事务后，会等待至少一个从库接收完成后再将结果返回给客户端。这种方式性能和数据一致性都介于异步复制和全同步复制之间。

（3）全同步复制：主库在执行完客户端提交的事务后，会等待所有从库接收并处理完成后再将结果返回给客户端。这种方式数据一致性最高，但性能最低。

以MySQL为例，从MySQL5.5开始，MySQL以插件的形式支持半同步复制，确保事务提交后binlog至少传输到一个从库但是不保证从库应用完成这个事务的binlog，性能有一定的降低，网络异常或从库宕机，卡主库，直到超时或从库恢复。该方案优点是利用数据库原生功能，比较简单；缺点是主库的写请求时延会增长，吞吐量会降低。

1.1.2 强制读主

通过架构改造，强制所有读请求都直接从主库读取，不使用从库。这种方式可以确保数据的一致性，但会增加主库的压力，并需要额外的系统架构改造。

1.1.3 使用数据库中间件

数据库中间件可以记录所有写请求的key，并在主从同步时间窗口内，将读请求路由到主库，以确保读取到最新数据。这种方式能保证绝对一致，但数据库中间件的成本比较高。

1.1.4 缓存记录写key法

当写请求发生时，将相关的key记录在缓存中，并设置一定的超时时间。在超时时间内，读请求会被路由到主库以确保数据一致性。这种方式成本较低，但需要引入额外的cache组件，并且读写数据库时都多了一步cache操作。

1.2 Redis主从架构的特定解决方案

1.2.1 主节点作为唯一写入点

在标准的主从架构中，所有的写操作都只能在主节点上进行，从节点只负责读操作。这种做法自然避免了写操作上的数据冲突。

1.2.2 同步复制

在某些配置中，从节点可以在接收并应用主节点数据更改之后，才对外提供读服务。这确保了读取的数据是最新的，但可能会增加读操作的延迟。

1.2.3 自动故障转移

使用如Redis Sentinel或Redis Cluster可以在主节点故障时自动进行故障转移，选举新的主节点，这有助于保持系统的可用性和一致性。

1.2.4 最后写入优先（LWW）

如果发生故障转移，可能出现短时间的数据不一致（由于异步复制）。Redis通常采用最后写入优先的策略来解决这类问题。

1.2.5 确保多数投票

在使用如Redis Sentinel这样的系统时，确保大多数节点都能通信，以避免脑裂现象。脑裂发生时，两个分区都可能认为自己拥有一个活跃的主节点，从而导致数据不一致。

1.2.6 读写分离

客户端可以选择只从主节点读取关键数据，以确保数据的最新性。

1.2.7 一致性哈希

在分布式环境中，使用一致性哈希等技术来减少因节点变动（如故障转移）导致的缓存击穿问题。

1.3 其他优化措施

1.3.1 优化硬件和文件系统

（1）使用高性能的服务器、存储设备（如SSD）和网络环境（如万兆交换机）来减少延迟。

（2）调整文件系统的mount属性，减少不必要的磁盘写操作，提高I/O性能。

1.3.2 调整数据库配置

（1）在主库上设置innodb_flush_log_at_trx_commit=1和sync_binlog=1等参数，确保每次事务提交后都能实时刷新到磁盘中，避免数据丢失。

（2）在从库上设置master_info_repository="TABLE"、relay_log_info_repository="TABLE"和relay_log_recovery=1等参数，确保复制相关的元数据表也采用InnoDB引擎，并开启relay log自动修复机制。

1.3.3 使用GTID复制模式

在MySQL中开启GTID复制模式，可以简化复制的管理和维护，并提高数据的一致性。

综上所述，控制主从架构的数据一致性需要综合考虑多种因素，包括数据库的选择、同步方式的配置、系统架构的设计以及硬件和文件系统的优化等。通过合理的配置和优化措施，可以在确保数据一致性的同时提高系统的性能和可用性。

2.哪些数据库中间件可以实现主从同步？

多种数据库中间件可以实现主从同步，以下是一些常见的中间件及其特点。

2.1 MySQL相关中间件

2.1.1 Canal

（1）简介：由Alibaba开源，基于binlog的增量日志组件，能够伪装成MySQL的slave，发送dump协议获取binlog，解析并存储起来给客户端消费。这使得它能够同步任何非查询类操作DDL和DML语句（除了数据查询语句select）。

（2）特点：实时性好，可以实时地捕获数据库的变更并及时推送到目标端；支持分布式环境下的数据同步；引入了ACK机制，可以有效地降低数据传输的风险，提高数据同步的可靠性。但只支持增量同步，不支持全量同步，且可能存在单点压力大和日志量大的问题。

2.1.2 DBSyncer

（1）简介：一款开源的数据同步中间件，支持MySQL、Oracle、SqlServer、ES、SQL等多种数据库类型。

（2）特点：支持上传插件自定义同步转换业务，用户可以通过编写插件来实现自己的同步转换逻辑，使得数据同步更加灵活和定制化；提供监控全量和增量数据统计图，用户可以实时查看数据同步的状态、结果和同步日志以及系统日志，方便故障排查和问题定位；支持自定义库同步到库组合，并可以实现关系型数据库与非关系型之间的组合，任意搭配表同步映射关系。但DBSyncer的开源社区相对较小，使用和配置相对复杂，且在某些场景下可能存在稳定性问题。

2.1.3 MaxScale

（1）简介：由MariaDB开发的MySQL数据中间件。

（2）特点：可以作为数据库的代理，通过路由转发完成读写分离。

2.1.4 MHA

（1）简介：一种强一致的主从切换工具。

（2）特点：可以与MaxScale等中间件结合使用，实现MySQL的高可用架构。

2.2 通用数据库中间件

2.2.1 Otter

（1）简介：由阿里巴巴开源的分布式数据库同步系统，尤其是在跨机房数据库同步方面功能强大。

（2）特点：基于数据库增量日志解析，实时将数据同步到本机房或跨机房的mysql/oracle数据库。目前嵌入式依赖Canal，部署为同一个jvm，目前设计为不产生Relay Log。允许自定义同步逻辑，解决各类需求。

2.2.2 Debezium

（1）简介：一个开源的分布式平台，提供变更数据捕获（Change Data Capture，CDC）功能。

（2）特点：支持多种数据库（包括MySQL、PostgreSQL、MongoDB等）的CDC，并将变更数据以事件的形式发送给Kafka等消息队列，从而实现数据的实时同步和处理。

在选择数据库中间件时，需要根据具体的业务需求、系统架构、数据一致性要求以及成本等因素进行综合考虑。不同的中间件有不同的特点和适用场景，例如Canal更适合于实时性要求较高的场景，而DBSyncer则提供了更灵活的自定义同步转换功能。同时，也需要注意中间件的稳定性、性能以及社区支持等因素。

此外，对于主从同步的数据一致性要求较高的场景，可以考虑使用半同步复制或全同步复制等同步方式，并结合数据库中间件来实现更高层次的数据一致性控制。

3.开源的主从复制框架有哪些？

关于开源的主从复制框架，以下是一些常见的选择。

3.1 数据库自带的主从复制功能

3.1.1 MySQL主从复制

MySQL数据库自带主从复制功能，通过配置主库和从库，可以实现数据的实时或异步同步。这是MySQL数据库最常用的高可用性和数据冗余方案之一。

3.1.2 Redis主从复制

Redis也支持主从复制功能，主节点负责处理写操作，从节点负责处理读操作，从而实现读写分离和数据冗余。

3.2 专门的数据库中间件

3.2.1 Canal

由阿里巴巴开源，基于MySQL数据库binlog的增量订阅&消费组件。Canal能够伪装成MySQL slave，解析binlog后提供给下游消费。它主要用于数据库变更日志的增量订阅和消费，适用于需要实时同步数据库变更到其他系统的场景。

3.2.2 Otter

阿里巴巴开源的分布式数据库同步系统，用于实现两个数据库之间的实时同步。它基于Canal进行增量数据同步，并提供了丰富的同步策略和监控功能。

3.2.3 Maxwell

一个开源的MySQL CDC（Change Data Capture）工具，能够实时捕获MySQL数据库中的变更数据，并以JSON格式发送到Kafka、Kinesis等消息队列中。

3.2.4 Debezium

一个开源的分布式平台，提供变更数据捕获（CDC）功能。它支持多种数据库（包括MySQL、PostgreSQL、MongoDB等）的CDC，并将变更数据以事件的形式发送给Kafka等消息队列。

3.3 其他相关工具和框架

3.3.1 SymmetricDS

一个开源的数据库复制和同步工具，支持多主复制、过滤同步和转换功能等。它可以与许多数据库进行压缩，并跨不同平台复制数据。

3.3.2 Talend

提供开源的数据集成工具，支持超过1000个连接器，可用于连接云中或本地的任何数据源。通过拖放功能使用GUI界面轻松开发数据管道，支持无时间线的海量数据复制。

3.4 选择和考虑因素

在选择开源的主从复制框架时，需要考虑以下因素：

（1）数据一致性要求：不同的框架提供不同的数据一致性保证，需要根据业务需求选择合适的数据一致性级别。

（2）性能需求：复制框架的性能会影响数据库的读写性能和吞吐量，需要选择能够满足性能需求的框架。

（3）易用性和维护性：选择易于配置、使用和维护的框架可以降低运维成本和提高系统稳定性。

（4）社区支持和文档：活跃的社区和完善的文档可以帮助快速解决问题和获取技术支持。

（5）扩展性和兼容性：随着业务的发展，可能需要扩展数据库架构或迁移到其他数据库系统。因此，需要选择具有良好扩展性和兼容性的复制框架。

请注意，以上列出的框架并非全部开源的主从复制框架，且随着技术的不断发展，新的框架和工具不断涌现。因此，在选择时建议根据最新的技术趋势和社区反馈进行综合考虑。