说到MySQL数据库主从提前疑问，我还是深有体会的，由于我之前经常遇到。
我之前在一家餐饮上班公司中，过后咱们的系统属于订单的下游业务系统。
在半夜和早晨的用餐高峰期，用户并发量还是不小的。订单系统为了保障性能和高可用，做了主从分别架构。
一个主库，两个从库。
主库关键用来写数据，从库关键是用来读数据，主库的数据会实时同步到从库。
但偶然会出现主从提前疑问。
而咱们划菜系统跟订单系统之间，是经过MQ启动通讯的，流程如下：
用户下单之后，订单系统会出现一条MQ信息，信息体只蕴含id等关键信息。
划菜系统消费这条MQ信息之后，会经过订单id，调用订单系统的订单查问接口查问出订单的概略数据。
订单查问接口的数据，是从订单的从库查问出来的。
假设一旦出现数据库主从同步提前的疑问，就或者会出现订单查问接口前往的数据不完整。
会造成划菜系统的表写入数据失败。
MySQL的主库会将数据库的变动，以二进制的方式，保留到磁盘上的binlog文件中。
主从同步就是将主库上的binlog文件，传输到从库上。
这个环节通常状况下是异步的。
流程图如下：
假设两边的任何一个环节出现疑问，都或者会造成数据库主从提前的疑问。
3 如何处置主从提前疑问？
网络疑问，会造成binlog从主库出现到主从时，出现疑问。
咱们可以参与网络的带宽，由100M更新到300M。
普通状况下，主库的性能要比从库的要好。
假设高并发的写入数据，会造成发生少量的binlog数据，在从库经过replay log回放的环节会比拟慢。
从而造成从库写入数据的速度。
这种状况下，可以更新从库的主机性能，跟主库坚持分歧。
业务系统中的大事务，不光会造成主库写数据的速度变慢，还会造成主从数据同步时，从库写数据的速度雷同变慢。
咱们须要防止大事务疑问，对业务代码中的大事务做排查，缩大事务的范畴。
有些业务代码，可以放到事务之外的，尽或者放到事务之在口头，比如：有些查问方法。
有些可以异步口头的代码，尽或者异步口头。
MySQL的低版本，只允许复线程同步binlog，同步速度十分慢。
这种状况下，可以更新MySQL版本到5.6以上，允许多线程同步。
在主从同步时，假设从库太多，或者会造成同步速度变慢。
主从同步，要一切从库的数据，都同步成功了，才算真正的成功了。
针对这种状况，倡导缩小，从库的数量，普通不倡导超越5个。
接上去，聊聊咱们过后遇到了数据库主从提前疑问的处置打算。
咱们过后先找运维更新了网络带宽。
确保在高并发时，带宽不会被打满。
而后，提升了业务代码，缩小了代码中的大事务，将非**业务剥离出来了，而后经常使用异步处置这一局部逻辑。
这样可以缩小同一时辰的数据库写操作。
此外，参与了智能重试机制。
假设MQ消费者调用订单查问接口时，出现了数据不完整的状况。
咱们的程序会将意外数据写入数据库，有专门的job智能动员重试。
经过上方的这些提升之后，咱们数据库主从提前的疑问基本上被处置了。
最后留一个疑问：假构想要主从强迫分歧性该怎样办？