营销型网站建设长沙seo霸屏
备库在消费中转日志时，其实可以分多个线程同时对多个事务进行消费，但是要满足2个基本原则：
1.涉及同一行数据的多个事务必须在同一个线程中执行，否则会导致数据不一致
2.同一个事务不能被拆开
MYSQL 5.6的并行复制策略（按库并行）
不同的worker执行不同的库上的事务
如果多个库的压力均衡，那效果就还可以。
MariaDB 的并行复制策略（模拟主库的并行模式）
MariaDB的思路是：
1.能在同一组（组提交）提交的事务，一定不会修改同一行
2.主库上可以并行执行的事务，在备库上也一定可以并行执行。
在实现上：
在一组里面提交的事务，有个共同的commit_id。
把commit_id写到binlog里面
在备库分发任务的时候，相同的commit_id就可以分到多个不同的线程并发执行。
这一组事务全部执行完成后，再取下一组。
MYSQL 5.7 的并行复制策略
参数slave-parallel-type，如果参数值为DATABASE,那就是MYSQL5.6的并行策略。
参数值是 LOGICAL_CLOCK，那就是类似于MariaDB的策略。
在主库“同时执行”的策略，在从库是可以同时执行的吗，不能的，因为主库同时执行时还有锁机制来控制各个事务的先后顺序。
MariaDB的策略其实是：同时处于commit状态的事务可以并行执行？？？
实际上，同时处于prepara阶段的事务就可以并行执行了，因为这时事务就已经执行完了。
而且，在prepara阶段的事务和处于commit状态的事务之间，在备库上也是可以并行执行的。
MYSQL 5.7.22 的并行复制策略
binlog-transaction-dependency-tracking 参数选择三种策略
1.根据多个事务是否在prepara阶段的事务和处于commit状态的事务之间
2.对于每一行计算出hash，如果2个事务的所更改的行的集合没有交集，就是可以并行的
3.在第二种的基础上加了一个约束：在主库中同一个线程先后执行的事务，在从库也要保持先后关系