浅析分布式主从架构下数据一致性问题_主从架构的数据一致性

主从架构

常见的主从架构，即为一主多从，常见的读写策略为写主读从，并由主节点写日志并通过网络传输来维护从节点的数据库状态，但是这个常见的策略会产生一系列的分布式数据一致性问题。

通常我们使用主从架构，主要是处于以下几个目的：

• 提高服务的容错性，即使一个节点崩溃了，还存在多个节点可以对外提供服务；
• 提高服务的响应速度与QPS，存在多个冗余节点可以对外提供服务，自然会降低响应的延迟与提高服务的承受能力；常见的使用策略为CDN，通过在全国各地部署服务器，使得用户可以通过请求最靠近自身的服务器而无需跨较远距离访问源站，从而提高了响应速度。

基础概念：

复制状态机：

注意与设计模式中的状态机模式进行区分，核心要点在于各自状态的含义是什么？

• 复制状态机中的状态一般是指集群节点中数据库的状态，集群节点通过不断接收、应用事件日志使得自身状态与主节点同步；
• 状态机模式中的状态是指程序对象的状态，程序通过不断响应定义好的状态变更事件使得程序对象的状态在恒定的几个状态间流转；

复制状态机基于集群节点初始状态一致，并且导致状态变更的事件在每个节点中应用的顺序一致，那么集群所有节点的状态最终必然是一致的这个理念，并通过事件日志传输维持集群节点的状态同步；

如上图所示，复制状态机算法下定义的每个节点含有：自身状态机、本地日志；

而如何保证事件日志的应用顺序一致，这个则由具体的分布式一致性算法（共识算法） 实现，如ZAB、Raft通过实现了全序广播算法对此进行保证，这个下面会具体讲。

分布式系统模型概念：

当我们要研究分布式系统时，首先是要使用形式化的语言描述分布式系统会出现的问题，然后根据这些问题总结出相应的系统模型，最后再基于系统模型提供的前置条件定义算法，并通过算法属性基于系统模型论证算法的有效性。

分布式系统中常见的问题场景为：

• 节点宕机：节点宕机后可能会一直宕机下去，又或者在经过一段时间后恢复正常运行并重新加入集群；而基于这个问题场景，定义了节点崩溃的两种系统模型-崩溃-中止模型、崩溃-恢复模型，在日常生产中，显然崩溃-恢复模型更加通用；ZAB与Raft等共识算法基于该系统模型，并解决了该模型下，诸如主节点崩溃后恢复加入集群可能会导致脑裂等问题；
• 节点间通信无响应或通信信息错位： 分布式系统因为网络问题导致无响应的原因可能包括：网络延迟较高超过程序预设的超时时间、进程暂停无法响应(如正在GC)；而出现信息错位是因为集群中每个节点间墙上时钟(本地时间) 存在一定的漂移，在多主架构下依据不同节点的本地时间判断全局的操作次序可能会导致对于操作先后的判断错误，并造成错误的数据覆盖：因此基于该问题场景，定义了节点网络通信的三种系统模型-同步模型、部分同步模型、异步模型，部分同步模型更加适合描述日常生产，网络在大部分时候都是稳定、具有响应时间上限的，但是在一些时候也会出现较长时间无响应的场景；ZAB与Raft等共识算法亦基于该系统模型，并解决了该计时模型下，如何在不确定网络响应时间上限的条件下判定节点是否失效、墙上时钟会出现震荡等问题。

共识算法：

共识：集群中半数以上节点就某项提议达成一致；提出共识的主要原因是集群中每个节点是无法仅凭借自身信息做出正确决策的；

如多个客户端同时请求分布式系统尝试获取最后一张电影票，此时可以通过共识算法决定哪个客户端为获胜者；

共识算法用于容忍部分同步，崩溃-恢复分布式系统模型下的节点通信、节点失效等问题；

接着我们首先讲复制状态机的实现手段-日志：

日志

日志同步方式

• 同步：主节点的一条日志只有所有子节点都复制成功后才可以进行提交；这种方式很明显可以完全保证主从之间日志的一致性，但是一旦某个子节点出现了网络问题，会导致日志无法提交直到该节点被判定为失效，在此之间集群无法提供写服务；
• 异步：主节点的一条日志只负责发给所有的子节点后便进行提交；这种方式使得客户端的响应时间得到保证，但很明显主从之间会存在日志复制的延迟，如果一条日志在主节点上提交后主节点便崩溃了，此时这条日志会存在丢失的隐患；
• 半同步：即对同步与异步的折中，在集群中选择一定数量的从节点为同步更新日志，其他的从节点为异步更新数据；这样既不会过于影响效率，又保证了在主节点崩溃时存在一个可以替换的节点。

同步日志内容

• 基于语句的复制：如主节点上需要执行update、insert、delete语句时，便会按照其sql语句生成相应的日志，而从节点应用日志的方式即为在本地执行相应的sql&#