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

码上得天下

已于 2023-06-07 12:17:37 修改

阅读量906

点赞数

分类专栏： Mysql 文章标签： mysql 数据库

于 2023-06-07 11:56:52 首次发布

原文链接：https://blog.csdn.net/weixin_38410337/article/details/128581125

版权

Mysql 专栏收录该内容

107 篇文章 14 订阅

订阅专栏

文章介绍了MySQL主从同步的三种方式：异步复制、半同步复制和强同步复制，以及它们在性能、一致性和可用性之间的权衡。半同步复制在数据安全和性能间取得平衡，而强同步复制确保数据强一致性但可能牺牲性能。此外，文中提出了主从延迟的缓解方案，包括硬件加速、分库分表、并行复制等，并提到了TiDB这样的分布式数据库系统作为解决一致性问题的选项。

摘要由CSDN通过智能技术生成

1.MySQL主从同步简介：

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

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

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

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

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

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

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

2)半同步复制: AP模型

MySQL从5.5开始引入了半同步复制，半同步复制介于异步复制和同步复制之间。主库在提交事务时先等待，必须确认至少一个从库收到了事件（从库将事件写入relaylog，不需要重放和提交，并向主库发送一个确认信息ACK），主库收到确认信息后才会正式commit。

与同步复制相比，半同步复制速度快很多，因为他只需要至少1个从库确认写入relaylog，并不需要完成在从库上的事务提交，同时又比异步复制更安全，因为主库在提交时，事务至少已经存在2个地方（主库的binlog和从库的relaylog）。由于半同步复制在提交事务前，需要从库返还确认信息，所以这里涉及到网络的往返通信开销，因此半同步复制只适合在网络条件较好的且地理上距离不远的环境部署，否则可能会因为网络延迟大幅降低主库性能。

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 会暂停对应用的响应，直至异常结束。