分布式系统需要了解的概念
分布式系统需要了解的概念
互联网高速发展,大数据、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算法。它将系统分为Follower
、Candidate
、Leader
三种状态,下面就是各状态的转变:
- 系统在初始时都为
Follower
状态,设定了一个定时器,规定在150ms~300ms的随机时间内没接收到来自Leader
的数据,则将状态转换为Candidate
。 - 所有进入
Candidate
状态的系统将会向其他节点拉取选票,当获取到大多数选票后,会将状态变为Leader
。
这一个过程被称为Leader选举(Leader Elaction)
。
所有对系统的修改都需要经过Leader
,每个修改都会写一条日志,Leader
将会把这些日志复制到所有Follower
节点,大部分节点响应后将日志提交,并通知所有Follower
节点进行提交,提交成功后,系统处于一致性状态。这个过程称为日志复制(Log Replication)
。
如果想要更好理解raft,请看动画图解raft。
ZAB协议
ZAB是Zookeeper专门设计的一种支持崩溃恢复的一致性协议,它只允许有一个Leader
接收/处理客户端请求。它设计了三种角色:Leader
、Follower
、Observer
,并分了三种状态:Looking
、Follower
、Leading
。
ZAB协议在系统启动时,初始状态都为Looking
,没有发现Leader
则进行选举,选举成功后进入消息广播模式
,集群中各节点的状态变为Follower
,Leader
的状态则为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数据,完成后进入消息广播模式。
总结
分布式内含大学问,在单机应用中,一切都非常简单,因为所有操作都由同一台机子处理,而分布式则跟我们的大脑一样,由多个神经元组成,如果一个神经元出现故障,如何保证整个大脑的正常运作?理解分布式中的各种理论,能够提高我们的业务意识,在设计的时候考虑多一些。