mysql数据结构模型属于什么模型

1.MySQL主从同步简介：

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

MySQL主从同步方案

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

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

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

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

应用发起数据更新（含 操作）请求，ｉｎｓｅｒｔ、ｕｐｄａｔｅ、deleteMaster 在执行完更新操作后立即向应用程序返回响应，然后 Master 再向 Slave 复制数据。

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

2)半同步复制: AP模型

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

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

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

3) 强同步复制: CP模型

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

应用发起数据更新（含 ｉｎｓｅｒｔ、ｕｐｄａｔｅ、ｄｅｌｅｔｅ 操作）请求，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，喜欢我的文章欢迎关注我,

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

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

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