主机与备机之间的物理延迟是不可控的，也是无法避免的。但是如果仅仅需要满足这种强一致性，是相对简单的事：只需要在主机写入时，确认更新已经同步到备机之后，再返回写操作成功即可。主流数据库均支持这种完全的同步模式。已经有人提到MySQL的Semi-sync功能（从MySQL 5.6开始官方支持，此前的版本可以考虑Google出的非官方补丁），就是基于这种原理。

不过，一般不建议使用这种同步模式。显而易见，如果写操作必须等待更新同步完成，肯定会极大地影响性能，除非你不在乎性能。

问题的关键在于，主从架构是一种用于数据容错的高可用性解决方案，而不是一种处理高并发压力的解决方案。它的目的是主机宕机以后备机可以马上顶上，而不是让备机来分担并发压力。完全同步机制也只是用于保证主机当机以后数据不会丢失，而不是保证从备机读取数据时的一致性。因此，我根本也不主张你使用从备机读取数据以分担并发压力这种方式。

解决方式是，不要试图在数据库层解决并发的读操作问题，至少不要在主从架构的数据库层解决。要在数据库层之上架构一个redis这样的分布式缓存来解决，它是专门干这个的。其性能肯定远高于从备机读取数据。

分布式缓存也存在着一些限制，例如不能完全支持事务处理。这取决于你的应用场景。对于一般的互联网应用，并发压力大但不要求支持事务，可以考虑分布式缓存。对于银行这样严格要求强一致性的应用，对于写入延迟一般没什么要求（延迟几个小时都可以接受，数据不出错就行），可以适用完全同步的模式。

另外，不建议你使用“通过版本库判断最新版本再分别路由到主机或备机”的山寨版解决方案。这会对应用层的代码造成严重污染。

主库针对写操作，顺序写binlog，从库单线程去主库顺序读”写操作的binlog”，从库取到binlog在本地原样执行（随机写），来保证主从数据逻辑上一致。mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率比较高，下一步，问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺序的，成本高很多，还可能可slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会问：“主库上那个相同的DDL也需要执行10分，为什么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。

MySQL数据库主从同步延迟是怎么产生的？当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。

• 首要原因：数据库在业务上读写压力太大，CPU计算负荷大，网卡负荷大，硬盘随机IO太高
• 次要原因：读写binlog带来的性能影响，网络传输延迟。