随着业务量的增加,目前的系统都朝着高并发、高可用的方向发展,同时带来了分布式数据的一致性问题。例如:
- 数据库主从架构、读写分离,存在访问时的数据一致性问题
- 为了进一步提高并发量,在数据库上层又引入一层缓存。现在又产生了缓存与数据库中的数据一致性问题
- 然后为了缓存的高并发,缓存也采用主从架构,缓存间进行主从复制,访问时又有数据一致性问题
以下就上述问题进行分析讨论,缓存此处默认为redis。相关内容分布在其他的文章中,在此对其进行集中整合下。
面试: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)事务则不需要经过组内同意,直接COMMIT即可。
在一个复制组内有多个节点组成,它们各自维护了自己的数据副本,并且在一致性协议层实现了源自消息和全局有序消息,从而保证组内数据的一致性。