MySQL主从复制有几种模式
① 强同步（全同步），强同步的意思是主节点在接收到curd指令后，必须同步该指令到至少一个从节点，并且从节点需要收到binlog并且执行relaylog成功后，才算事务提交完成
② 半同步，主节点收到curd操作指令后，从节点只需要收到日志就算事务完成了（这里收到日志的标准是从库接受到binlog,并且成功写入到relaylog），不需要等待从节点执行日志内容
半同步有两种模式 1. AFTER_COMMIT：主库将binlog传递给从库的同时，也提交了事务，然后等待从库返回ACK，然后返回结果给客户端 2. AFTER_SYNC：主库同步binlog给从库，等待从库返回写入relaylog日志成功的ACK后再返回结果给客户端 ③ 异步，主节点接收操作后完成操作，立即响应客户端，同时异步复制数据给从节点
说明：对于从节点而言，收到binlog之后会先写入relaylog（中转日志）然后有专门的线程sql_thread读取中转日志解析并执行的。 对于强同步和异步都比较极端，一个是性能堪忧一个是数据一致性比较弱，所以半同步是一个还不错的折中方案 但是有几个问题需要注意下
1. 对于模式AFTER_COMMIT模式而言，由于主库先提交了事务，这就导致一个用户两次查询可能导致不一样的结果（即幻读），比如第一次请求打在主库上有数据，而第二次打在从库上（或者因为主库宕机发生主从切换），而从库还没来得及执行relaylog同步数据，所以查不到
2. 对于AFTER_SYNC模式而言，如果你的系统监听了binlog做业务逻辑，等你的系统接收到binlog的时候，从库还没执行完（因为IO竞争激烈等原因），这个时候你如果去查主库，那你是查不到的，造成了数据不一致 对于模式AFTER_SYNC模式而言，我们可以根据业务的具体情况选择
① 重试
② 延迟队列
③ 不依赖binlog使用MQ等方法避免此类问题
