mysql主从复制原理和binlog模式、主从延时解决

（1）master记录一个binlog日志，该日志存储着sql语句。

（2）slave启动一个IO线程负责把master的 bin-log 文件 sql 语句复制过来写到本地的relay-log(中继日志)文件中;

（3）slave同时启动一个SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行。

主从同步事件binlog模式有3种形式：statement、row、mixed。

1. statement： 会将对数据库操作的 sql 语句写入到 binlog 中。
2. row： 会将每一条数据的变化写入到 binlog 中。
3. mixed： statement 与 row 的混合。MySQL 决定什么时候写 statement 格式的，什么时候写 row 格式的 binlog。

主从延时解决方案：

• 主服务器要负责更新操作，对安全性的要求比从服务器要高，所以有些设置参数可以修改，比如 sync_binlog=1，innodb_flush_log_at_trx_commit =  1   之类的设置等。
• 选择更好的硬件设备作为 slave。
• 把一台从服务器当度作为备份使用， 而不提供查询， 那边他的负载下来了， 执行relay log 里面的 SQL 效率自然就高了。
• 增加从服务器喽，这个目的还是分散读的压力，从而降低服务器负载。

备注：一般订单、出库单、入库单、冻结库存、在库库存等单据，这些单据在并发较大时（笔者遇到最大的不过是8000tps）左右，项目会经常出现当时无法从slave中查到单据数据情况。

一般这种情况下，最贴近实际的就是直接强制读主库即可（加@Transaction）即可。还有一种就是使用dubbo重试机制重试3次即可，这里需要额外考虑幂等。

特别是下单即支付场景，前段更加应该设计一个交互页面面向用户友好，并且定时重查是否立即支付成功场景。