MySQL的Group Replication各节点之间需要通过Paxos协议来进行通讯，通讯模型远比Semi-sync复杂。同时，Group Replication还需要检查是否写冲突（即使在single primary的模式下，也存在需要进行检查冲突的可能）。所以，在处理事务时，不管是通讯模型还是处理流程，Group Replication都要比Semi-sync复杂得多。因此，可能就会理所当然地得出Semi-sync比Group Replication要快，至少不会慢。这个结论应该没毛病。
以上是推论，为了更严谨一些，咱们来做一下测试，实践出真知嘛（其实，有的时候，也会表象掩盖事实）。
测试环境：
下面是Group Replication的测试结果：
TPS：8887，最短响应时间0.99ms，最大响应时间1260.68ms，也就是1.2秒。性能还不错。
我们再来看看Semi-sync的测试结果：
半同步的模式：1主2从，ack count设置为1，接到一个从库的ack后事务完成并返回客户端。
Semi-sync的测试结果：TPS 7555，最短响应时间0.84ms，最大响应时间228.44，平均响应时间3.97ms。
结果对比：
Group Replication的TPS比Semi-sync高，最短的响应时间，Group Replication都比Semi-sync要大，因为Group Replication要多进行一次通讯，所以最短的响应时间长。但平均响应时间，居然Group Replication比Semi-sync要短。为什么？ 后面解释。
对比TPS之后，前面提过，Group Replication各节点之间通讯模型比semi-syn复杂得多，我们来证明一下。
因为主节点需要处理SQL，有SQL输入还有执行结果返回带来的额外流量，所以我们来仅仅比较从库节点的流量。
Group Replication从节点的流量（secondary节点）
从图片可以看到，Group Replication的从节点：接收流量大约12.5M/s，发送流量5.1M/s。
再来看看Semi-sync的从节点
Semi-sync从节点，发送流量183K/s，接收流量4081KB 。
放在一起进行比较：
Group Replication的TPS8887，Semi-sync7555，除去这个（8887-7555)/7555=0.149， 即149%的TPS差异。假如Group Replicaiton 也按照7555的TPS执行，网络流量大概是：接收流量10.6M/S，发送流量为4.1M/S。发送流量跟Semi-sync模式下的接收流量大致相等。因此，猜测从节点从主节点接收到binlog的之后，还会将binlog发送给另外一个从节点（Paxos协议在Group Replication还在学习中，尚未完全确认其内部通讯机制，Paxos协议的实现还是比较复杂）。
一个事务的执行，在Semi-sync跟Group Replicaiton模式下，在binlog提交之前所有的处理逻辑是一模一样的，唯一的差别就是binlog复制到从库的方式不一样，完全相同的单个事务，
在Group Replication模式下节点间的网络通讯流量要比Semi-sync大一倍多（仅比较接收流量），但是Group Replication却比Semi-sync有更高的TPS，
只能说，Semi-sync的日志传输效率太low。
确实如此，Semi-sync模式下，发送接收日志后ack的信息的线程只有一个， 主库发送日志的时候，也是一个一个Event的发送，而不是作为一个大包发送。
而Group Replication采用是多个Paxos Machine来接收跟发送日志，Paxos Machine之间可以并行，因此它的通信效率远比Semi-sync的模式高。
因此， 如果Semi-sync的日志发送机制采用类似Group Replication这样的发送机制，将大大提高Semi-sync的性能
（半同步跟异步之间的性能差别太大，唯一的区别就是需要多等一个ack，如果半同步的通信效率倍增，性能将也几乎倍增），在这方面，优化的余地是非常大的。希望官方在这方面进行更多的改进。 但道听途说，以后Group Replication是MySQL的发展方向，不知官方是否还有兴趣继续优化Semi-sync的通讯机制。
测试之后，Group Replication的表现还是让作者有点意外，居然比Semi-sync快。这个确实始料不及，也证明MySQL在Group Replication通讯机制上下了不少功夫，目的是实现Paxos协议的同时解决可能存在的网络通讯效率瓶颈。
作者介绍 徐春阳
