首页 >编程 >正文

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

1.MySQL主从同步简介:

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

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

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,喜欢我的文章欢迎关注我,

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

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

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

网友评论

验证码 换一张
取 消
暂无评论...
三日内热门评论文章
关键词
为您推荐
  • 相关阅读
  • 业界资讯
  • 手机通讯
  • 电脑办公
  • 新奇数码
  • 软件游戏
  • 科学探索