共计 628 个字符，预计需要花费 2 分钟才能阅读完成。
读写拆散
基于 MySql 本身提供的主从复制架构，写操作申请发往主库，读操作申请发往从库。一个主库能够挂多个从库。主库实现写操作后，将数据通过 binlog 形式同步给从库。
主从复制工作原理
主库实现写操作后，将变更写入 binlog 日志，从库的 IO 线程从主库的 binlog 日志拉取拷贝数据变更日志，写入到 relay 中继日志，而后从库的 SQL 线程从 relay 日志中重放 sql 写操作，实现数据的同步。
主从复制延时较长解决方案
因为从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发状况下，从库与主库的数据同步是有延时的。换句话说，在主库刚写入的数据，在从库不肯定立马能读到。这就须要肯定的策略来解决这个问题。
常见的解决方案有两种（均基于 MySql 提供的机制）：
1. 半同步复制：在主库写入数据时，强制串行同步到从库，期待至多一个从库的 IO 线程写入 relay 中继日志并回复 ack 报文后，才认为写操作实现。
2. 并行复制：从库开启多个 SQL 线程，并行执行 relay 日志的不同库的 binlog 变更操作，而后并行重放 SQL 变更操作，相比串行可能达到升高延时的目标。
另外，在应用程序和 MySql 架构层面，也有如下计划：
1. 设计多主构造，单个主库写压力过大导致的延时问题，摊派到多个主库，可能升高同步延时。
2. 刚写入的数据，如果想立马读出来，就不从从库读，改为强制从主库读取，防止延时导致的读取不到数据问题。
3. 重写代码，对于不要求立马读出来的业务场景，尽可能不立马读数据，等一会再读。
正文完
