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

　　MySQL头条创作挑战赛1。MySQL主从同步简介：
　　MySQL实例主从配置，可以实现数据同步、备份、读写分离、容灾：可以在主库挂掉后从备用从库中选举新Master进行数据恢复动作。
　　MySQL主从同步方案2。MySQL支持三种复制方式：
　　MySQL5。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返回clientSlave宕机或网络中断，Master暂停10s降级异步复制，Slave恢复后恢复半同步复制性能居中，可用性优先，极端场景少量不一致。
　　应用发起数据更新（含insert、update、delete操作）请求，Master在执行完更新操作后立即向Slave复制数据，Slave接收到数据并写到relaylog中（无需回放执行）后才向Master返回成功信息，Master必须在接受到Slave的成功信息后再向应用程序返回响应。
　　仅在数据复制发生异常（Slave节点不可用或者数据复制所用网络发生异常）的情况下，Master会暂停（MySQL默认10秒左右）对应用的响应，将复制方式降为异步复制。当数据复制恢复正常，将恢复为半同步复制。
　　3）强同步复制：CP模型
　　Master等待Slave写入relaylog返回client；Slave宕机或网络中断，Master不会降级为异步复制保证强一致性，暂停对应用响应，直到Slave恢复正常性能最差，强一致性强一致性：牺牲可用性，适合对一致性要求高，能够接收服务停机或暂时不可用，保证数据强一致性业务场景。
　　应用发起数据更新（含insert、update、delete操作）请求，Master在执行完更新操作后立即向Slave复制数据，Slave接收到数据并写到relaylog中（无需执行）后才向Master返回成功信息，Master必须在接受到Slave的成功信息后再向应用程序返回响应。
　　在数据复制发生异常（Slave节点不可用或者数据复制所用网络发生异常）的情况下，复制方式均不会发生降级，为保障数据一致性，此时Master会暂停对应用的响应，直至异常结束。3。MySQL主从同步方案：主库记录binlog日志从库dumpbinlog日志从库回放日志恢复数据数据最终一致性
　　MYSQL主从复制流程4。MYSQL主从复制原理：Master主库将数据变更DataChanges记录binlog日志中。Slave起一个IO线程连接到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协议）；比如：NewSQLTiDB采用Raft协议保证强一致性并且能够兼容MySQL协议。
　　TiDB采用Raft协议保证强一致性
　　补充：单线程复制造成延迟问题
　　1。1。主库记录日志从库异步拉取日志主从切换时新主丢日志（造成数据一致性问题）
　　1。2主库并发执行从库单线程执行主从同步延迟（幻读问题：主库新版本，从库老版本）
　　解决方案：
　　MYSQL分组半同步
　　采用强同步复制或半同步复制
　　日志发送到从库落盘事务提交；分组半同步
　　每个逻辑机房一个一致性群组
　　异步ACK提升性能
　　1。2解决方案：并行复制
　　并行复制
　　多worker并行复制原理：
　　SQL线程负责解析日志
　　多Worker并发执行
　　行级别冲突检测（dbtableprimarykey）：通过dbtableprimary唯一key做行级别冲突检测，如果已经消费则不再消费。
　　排队提交：按照主库提交顺序排队提交，保持一致性。如：Master先更新A表再更新B表，Slave也应按照此顺序排队提交从而保持数据最终一致性。
　　消除主从同步延迟
　　我是架构师kimze，喜欢我的文章欢迎关注我，
　　我会坚持分享干货：互联网微服务架构、云原生架构、行业动态、经典案例、技术趋势，
　　有问题欢迎关注私信或评论区回复交流
　　点赞、收藏、转发、评论对我是一种支持，感谢！
　　MySQL头条创作挑战赛