MAR 强同步复制方案是基于 MySQL 协议的异步多线程强同步复制方案，只有当备机数据完全同步后，才由主机给予应用事务应答，保障数据不丢失。
数据库作为系统数据存储和服务的核心能力，其可用性要求非常高。在生产系统中，通常都需要用高可用方案来保证系统不间断运行，而数据同步技术是数据库高可用方案的基础。MySQL的数据复制默认是异步复制，但异步复制对于核心交易业务场景下，要求数据强一致性是不够的。
Google提供了一个半同步插件，确保必须收到一个备机的应答才让事务在主机中提交，但是当备机应答超时的情况下，半同步复制会由超时时间退化为异步，这在金融场景下风险是比较大的。按照CAP的原理，宁愿牺牲一定的可用性也不愿意把数据丢失，假设备机异常了，退化为异步了，主机继续交易。如果此时主机再发生故障，数据库层面很可能出现数据丢失，一旦数据库层面出现数据丢失，事后要去修复是非常困难的，所以这种时候我们是不让它退化，继续强同步（可能交易失败）。所以在复制这块，我们主要是去解决这两个问题。刚才讲的，而且半同步复制在跨IDC情况下性能也会有问题的。
基于MySQL协议的异步多线程强同步复制方案（Multi-thread Asynchronous Replication 简称MAR），一主两备的高可用，这两个备机是都做强同步复制的，只有当备机数据同步后，才由主机向应用返回事务应答，能够保证数据不丢不错。Percona XtraDB Cluster和MariaDB Galera Cluster在同城跨数据中心的情况下，在MySQL 5.6版本性能损耗非常大，而MySQL5.7版本虽然做了一些异步化处理，但依然会有性能损耗。MAR强同步复制技术的异步化改造，采用与Linux内核处理中断的思路，通过将串行的同步线程并行化，利用线程池和GroupCommit等技术大幅提高性能，大幅度提高性能。在性能方面可以做到同城跨数据中心，5毫秒以内的延迟的情况下，能够保证数据强同步TPS（Transactions Per Second）不会下降。
强同步复制技术原理，如图所示。上半部分：任务执行到写binlog为止，然后将会话保存到session中，接着执行下一轮循环去处理其他请求了，这样就避免让线程阻塞等待应答了；然后MySQL自身负责主备同步的dump线程会将binlog立即发送出去，备机的IO线程收到binlog并写入到relay log之后，再通过UDP给主机一个应答；在主机上，开一组线程来处理应答，收到应答之后找到对应的会话，执行下半部分的commit，send应答，绑定到epoll等操作。绑定到epoll之后这个连接又可以被其他线程检测到并执行了。
综合来看，MAR强同步复制的特点保证节点间数据强一致性，又将串行同步线程异步化，引入线程池能力，保证跨IDC情况下TPS不会下降。
来源：51CTO
作者：songlihuan
链接：https://blog.51cto.com/songlihuan/2481144