高并发、高可用下数据一致性问题分析

随着业务量的增加，目前的系统都朝着高并发、高可用的方向发展，同时带来了分布式数据的一致性问题。例如：

1. 数据库主从架构、读写分离，存在访问时的数据一致性问题
2. 为了进一步提高并发量，在数据库上层又引入一层缓存。现在又产生了缓存与数据库中的数据一致性问题
3. 然后为了缓存的高并发，缓存也采用主从架构，缓存间进行主从复制，访问时又有数据一致性问题

以下就上述问题进行分析讨论，缓存此处默认为redis。相关内容分布在其他的文章中，在此对其进行集中整合下。

面试：MySQL基础知识——六、3主从复制

面试：redis基础知识——八、主从复制；十、保证缓存与数据库的一致性

一、数据库主从架构一致性问题

1、半同步复制（不能保证强一致性）

是介于全同步复制与全异步复制之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全完成并且提交的反馈，如此，节省了很多时间。

介于异步复制和全同步复制之间，相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

2、组复制（强一致性）

组复制技术，简称MGR。是MySQL在5.7.17版本中推出的一种新的数据复制技术，这种复制技术是基于paxos协议的状态机复制。

MGR将MySQL带入了数据强一致性的时代，是一个划时代的创新，其中一个重要原因是MGR是基于paxos协议的。

异步复制和半同步复制都无法最终保证数据的一致性问题，半同步复制是通过判断从库响应的个数来决定是否返回给客户端，虽然数据一致性相比于异步复制有提升，但仍然无法满足对数据一致性要求高的场景，比如金融领域。MGR 很好地弥补了这两种复制模式的不足。

首先我们将多个节点共同组成一个复制组，在执行读写（RW）事务的时候，需要通过一致性协议层（Consensus）的同意，也就是读写事务想要进行提交，必须要经过组里“大多数人”（对应Node节点）的同意，大多数指的是同意的节点数量要大于N/2+1，这样才可以进行提交，而不是一方说了算。而针对只读（RO）事务则不需要经过组内同意，直接COM