一篇彻底搞懂MySQL选择AP模型还是CP模型?

1.MySQL主从同步简介：

MySQL实例主从配置，可以实现数据同步、备份、读写分离、容灾:可以在主库挂掉后从备用从库中选举新Master进行数据恢复动作。

MySQL主从同步方案

2.MySQL支持三种复制方式:

MySQL 5.6、5.7、8.0 版本支持三种复制方式：异步、半同步、强同步；5.5 版本支持异步方式

1) 异步复制(MySQL默认) : AP模型

Master不等待Slave同步，直接返回client => 性能最高，数据可能出现不一致；可用性优先: 适合对性能要求，能够容忍计算场景少量数据丢失场景

应用发起数据更新（含 操作）请求，insert、update、deleteMaster 在执行完更新操作后立即向应用程序返回响应，然后 Master 再向 Slave 复制数据。

数据更新过程中 Master 不需要等待 Slave 的响应，因此异步复制的数据库实例通常具有较高的性能，且 Slave 不可用并不影响 Master 对外提供服务。但因数据并非实时同步到 Slave，而 Master 在 Slave 有延迟的情况下发生故障则有较小概率会引起数据不一致

2)半同步复制: AP模型

Master等待Slave写入relaylog返回client & Slave宕机或网络中断，Master暂停10s 降级 异步复制，Slave恢复后 恢复半同步复制 => 性能居中，可用性优先，极端场景少量不一致；

应用发起数据更新（含 insert、update、delete 操作）请求，Master 在执行完更新操作后立即向 Slave 复制数据，Slave 接收到数据并写到 relay log 中（无需回放执行）后才向 Master 返回成功信息，Master 必须在接受到 Slave 的成功信息后再向应用程序返回响应。

仅在数据复制发生异常（Slave 节点不可用或者数据复制所用网络发生异常）的情况下，Master 会暂停（MySQL 默认10秒左右）对应用的响应，将复制方式降为异步复制。当数据复制恢复正常，将恢复为半同步复制。

3) 强同步复制: CP模型

Master等待Slave写入relaylog返回client; Slave宕机或网络中断，Master不会降级为 异步复制 => 保证强一致性，暂停对应用响应，直到Slave恢复正常 => 性能最差，强一致性 =>强一致性: 牺牲可用性，适合对一致性要求高，能够接收服务停机或暂时不可用，保证数据强一致性业务场景。

应用发起数据更新（含 insert、update、delete 操作）请求，Master 在执行完更新操作后立即向 Slave 复制数据，Slave 接收到数据并写到 relay log 中（无需执行） 后才向 Master 返回成功信息，Master 必须在接受到 Slave 的成功信息后再向应用程序返回响应。

在数据复制发生异常（Slave 节点不可用或者数据复制所用网络发生异常）的情况下，复制方式均不会发生降级，为保障数据一致性，此时 Master 会暂停对应用的响应，直至异常结束。

3.MySQL主从同步方案：

1. 主库记录binlog日志
2. 从库dump binlog日志
3. 从库回放日志恢复数据
4. 数据最终一致性

MYSQL主从复制流程

4.MySQL主从复制原理：

1. Master主库将数据变更DataChanges记录 binlog日志中。
2. Slave起一个I/O线程连接到Master，dump读取Master的binlog日志并写入到Slave的中继日志Relaylog中。
3. Slave中的SQL线程读取中继日志Relaylog进行SQL回放执行操作，完成主从复制，保证主从最终一致性。

5.MySQL主从同步问题&优化：

1.MySQL 怎么保证数据强一致性?

需要保证强一致性场景建议 MySQL 采用强同步复制采用一主两备的架构，仅需其中一台 Slave 成功执行即可返回，避免了单台 Slave 不可用影响 Master 上操作的问题，提高了强同步复制集群的可用性。

2.MySQL 主从延迟如何解决?

主从同步机制决定本质上避免不了复制延迟问题, 只能缓解 。

MySQL主从Proxy读写分离方案

主从延迟缓解方案:

• 硬件加速: SSD高性能硬盘
• 读写分离，分担主库压力
• Sharding分库分表
• 从库关闭binlog
• 并行复制加速(商业化版本)
• GTID 事务组复制
• 应用层架构优化: MQ异步消息解耦、多级缓存加速处理

主从延迟兜底策略：

核心业务强制读主库(注意读写压力不大可以)

如果想从根本上解决同步延迟问题：

需要采用强一致性协议处理: Paxos 强一致性算法处理(实现起来相对复杂) 推荐使用TiDB(Raft协议) ; 比如: NewSQL-TiDB 采用Raft协议保证强一致性并且能够兼容MySQL协议。

TiDB 采用Raft协议保证强一致性

补充: 单线程复制造成延迟问题

#1.1. 主库记录日志-> 从库异步拉取日志-> 主从切换时新主丢日志（造成数据一致性问题）

#1.2 主库并发执行-> 从库单线程执行-> 主从同步延迟(幻读问题:主库新版本，从库老版本)

解决方案：

MYSQL分组半同步

采用强同步复制 或 半同步复制

• 日志发送到从库落盘事务提交; 分组半同步

• 每个逻辑机房一个一致性群组

•异步ACK提升性能

#1.2 解决方案：并行复制

并行复制

多worker并行复制原理：

• SQL线程负责解析日志

• 多Worker并发执行

• 行级别冲突检测(db+table+primary_key ):通过db+table+primary 唯一key做行级别冲突检测，如果已经消费则不再消费。

• 排队提交： 按照主库提交顺序排队提交，保持一致性。如：Master先更新A表再更新B表，Slave也应按照此顺序排队提交从而保持数据最终一致性。

• 消除主从同步延迟

我是架构师kimze，喜欢我的文章欢迎关注我,

我会坚持分享干货: 互联网微服务架构、云原生架构、行业动态、经典案例、技术趋势，

有问题欢迎关注私信或评论区回复交流

点赞、收藏、转发、评论 对我是一种支持，感谢！