一篇彻底搞懂MySQL是AP模型还是CP模型？

　　#MySQL# #头条创作挑战赛# 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主从同步方案：主库记录binlog日志 从库dump binlog日志 从库回放日志恢复数据 数据最终一致性
　　MYSQL主从复制流程4.MYSQL主从复制原理：Master主库将数据变更DataChanges记录 binlog日志中。 Slave起一个I/O线程连接到Master，dump读取Master的binlog日志并写入到Slave的中继日志Relaylog中。 Slave中的SQL线程读取中继日志Relaylog进行SQL回放执行操作，完成主从复制，保证主从最终一致性。 5.MySQL主从同步问题&优化：
　　1.MySQL 怎么保证数据强一致性?
　　需要保证强一致性场景建议 MySQL 采用强同步复制采用一主两备的架构，仅需其中一台 Slave 成功执行即可返回，避免了单台 Slave 不可用影响 Master 上操作的问题，提高了强同步复制集群的可用性。
　　2.MySQL 主从延迟如何解决?
　　主从同步机制决定本质上避免不了复制延迟问题, 只能缓解 。
　　主从延迟缓解方案
　　2.1 主从延迟缓解方案:硬件加速: SSD高性能硬盘读写分离，分担主库压力Sharding分库分表从库关闭binlog并行复制加速(商业化版本)GTID 事务组复制应用层架构优化: MQ异步消息解耦、多级缓存加速处理
　　2.2 兜底策略：
　　核心业务强制读主库(注意读写压力不大场景可以)
　　3.3 解决同步延迟：
　　如果想从根本上解决同步延迟问题,需要采用强一致性协议处理: 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，喜欢我的文章欢迎关注我,
　　我会坚持分享干货: 互联网微服务架构、云原生架构、行业动态、经典案例、技术趋势，
　　有问题欢迎关注私信或评论区回复交流
　　点赞、收藏、转发、评论 对我是一种支持，感谢！
　　#MySQL# #头条创作挑战赛#