分布式系统需要了解的概念

互联网高速发展,大数据、AI成为时代的热门话题,智慧应用、云计算成为主流,分布式理论必须扎实,在这些理论的基础上学习和使用框架进行开发可以避免很多问题。

CAP理论

一致性、可用性、分区容灾性是分布式系统的三大问题,CAP理论在一个分布式系统中最多只能满足两项,即CA、CP或AP。

C:一致性,保证更新操作后,所有节点中的数据保持一致。

A:可用性,服务是可用的,和平常没区别。

P:分区容灾性,节点或者网络分区故障时,仍然能够保证提供满足一致性和可用性的服务。

在不同的业务场景中,需要对CAP进行取舍。

BASE

BASE是CAP的延伸,它的核心思想是无法做到强一致性,也要达到最终一致性。

BA(Basically Available):基本可用,指的是分布式系统出现故障时,可以损失部分可用性,保证核心功能可用。

S(Soft State):软状态,指的是允许分布式系统存在中间状态,即允许不同节点间的副本存在同步的延时。

E(Eventual Consistency):最终一致性,允许系统的数据经历一段时间后,最终能够达到一致的状态。

2PC和3PC

分段提交协议,由协调者和参与者组成,协调者在多个参与者之间发送命令进行协调。

2PC(Two-Phase Commit):两段提交协议,第一阶段为预提交,第二阶段才是真正的提交。

  • 协调者先发送preCommit给参与者,参与者进入预提交状态。
  • 协调者收到全部预提交相应,并且都为接收时,发送doCommit给参与者,参与者进行提交操作。

3PC(Three-Phase Commit):三段提交协议,第一阶段是询问是否可以提交,第二阶段为预提交,第三阶段为真正的提交。

  • 协调者先向参与者询问事务,如果参与者响应能够顺利完成事务,返回Yes,否则协调者将中断该事务。
  • 协调者发送preCommit请求,让参与者预提交事务,如果返回是Yes,进行下一阶段;否则放弃该事务。
  • 协调者发送doCommit请求,让参与者提交事务。一段时间后如果参与者没收到该请求,则会自动提交。

3PC是针对2PC的改进,在2PC的基础上添加的一个阶段,防止预提交阶段完成后,协调者宕机无法发送提交请求,造成资源锁定,影响系统吞吐量。

Paxos

Paxos算法属于一个分布式的共识算法,Paxos将系统分为提议者(Proposal)、决策者(Acceptor)和最终学习者(Leaner)。主要是由提议者发出提案,如果该提案被半数以上的决策者同意,则认定该提案,由决策者告诉学习者进行设置值。其过程为:

  • 提议者发出n号提案,发送给决策者。
  • 决策者接收了这个n号提案,将回复该请求,并承诺不再接收低于n号的提案。
  • 如果提议者收到了多数决策者的回复,则发一个accept请求给决策者。

Raft

Raft是一种更容易理解的一致性算法,意在取代难以理解的Paxos算法。它将系统分为FollowerCandidateLeader三种状态,下面就是各状态的转变:

  • 系统在初始时都为Follower状态,设定了一个定时器,规定在150ms~300ms的随机时间内没接收到来自Leader的数据,则将状态转换为Candidate
  • 所有进入Candidate状态的系统将会向其他节点拉取选票,当获取到大多数选票后,会将状态变为Leader

这一个过程被称为Leader选举(Leader Elaction)

所有对系统的修改都需要经过Leader,每个修改都会写一条日志,Leader将会把这些日志复制到所有Follower节点,大部分节点响应后将日志提交,并通知所有Follower节点进行提交,提交成功后,系统处于一致性状态。这个过程称为日志复制(Log Replication)

如果想要更好理解raft,请看动画图解raft

ZAB协议

ZAB是Zookeeper专门设计的一种支持崩溃恢复的一致性协议,它只允许有一个Leader接收/处理客户端请求。它设计了三种角色:LeaderFollowerObserver,并分了三种状态:LookingFollowerLeading

ZAB协议在系统启动时,初始状态都为Looking,没有发现Leader则进行选举,选举成功后进入消息广播模式,集群中各节点的状态变为FollowerLeader的状态则为Leading。当Leader崩溃后,进入崩溃恢复模式,即重新选举Leader。当崩溃的Leader恢复后发现已经有Leader了,则退为Follower。

消息广播模式具体流程如下:

  • Leader接收到请求后,为该事务分配ZXID,并进行广播。
  • Leader为Follower各自分配了一个单独的队列,以FIFO的策略进行消息发送,因此Leader只需要将消息依次放入队列中广播。
  • Follower接收到事务消息后,会以日志的形式写入磁盘,写入成功则响应ACK。
  • Leader接收到半数以上的ACK时,将发送Commit广播。

那么ZXID是什么呢?它是一个全局的单调递增唯一ID,用于保证事务的顺序处理。它是一个64位的数字,主要由两部分组成:高32位是epoch(纪元),低32位是counter(计数器),以epoch为Leader的届数,就像改朝换代那样,当一个Leader挂掉后,进行选举,选举出来的新Leader的epoch将会进行+1,并将counter重置。counter则是每一次事务都会递增。这样就能保证旧的Leader挂掉后恢复了,也不会对系统产生不好的影响。

崩溃恢复流程如下:

当Leader崩溃后,各节点发起投票选举,统计票数确认超过半数的节点确认Leader后,Follower将同步Leader数据,完成后进入消息广播模式。

总结

分布式内含大学问,在单机应用中,一切都非常简单,因为所有操作都由同一台机子处理,而分布式则跟我们的大脑一样,由多个神经元组成,如果一个神经元出现故障,如何保证整个大脑的正常运作?理解分布式中的各种理论,能够提高我们的业务意识,在设计的时候考虑多一些。

参考资料

【理论篇】浅析分布式中的 CAP、BASE、2PC、3PC、Paxos、Raft、ZAB