1 CAP定理
- 一致性(Consistency):所有节点访问时都是同一份最新的数据副本(强一致性)。
- 可用性(Availability):每次请求都能获取到非错的响应,但是不保证获取的数据为最新数据。
- 分区容错性(Partition tolerance):分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障。
CAP三者如何权衡
- 分布式系统下,经常会出现网络问题,所以分区容错性是比须满足。不然容易因为网络分区导致系统不可用。
- CP:满足分区容错性之后选择一致性,会牺牲一部分未同步数据节点的可用性。适用于一些银行业务要求强一致性的场景。
- AP:满足分区容错性和可用性,可能会出现节点数据不一致场景。适用于电商对可用性要求高的业务。
- CA:放弃分区容错性。不能容忍网络错误或者分区问题,一旦出现就会拒绝请求。
2 Base理论
Base理论是对CAP理论一致性和可用性权衡的结果。
- Basically Available(基本可用):允许响应上的损失,响应时间变长;允许功能上的损失,降级处理。
- Soft state(软状态):允许数据存在中间状态,就是节点之间允许存在短暂的数据不一致。
- Eventually consistent(最终一致性):数据允许一定期限的软状态,期限过后,所有副本的数据需要达到一致。
3 分布式一致性协议
两阶段提交协议(2PC)
- 2PC协议存在Prepare和Commit两个阶段
- Prepare阶段:协调者向各参与者询问是否可以正常执行事务,参与者执行事务,但未提交事务,然后向协调者进行响应。
- Commit阶段:协调者根据参与者的响应决定事务是commit还是callback。向参与者发送commit或callback请求。
2PC存在问题
- 同步阻塞:在二阶段提交的执行过程中,所有参与该事务操作的逻辑都处于阻塞状态,即当参与者占有公共资源时,其他节点访问公共资源会处于阻塞状态。
- 单点问题:若协调器出现问题,那么整个二阶段提交流程将无法运转,若协调者是在阶段二中出现问题时,那么其他参与者将会一直处于锁定事务资源的状态中,而无法继续完成事务操作
- 数据不一致:2阶段commit时候,如果有部分参与者未收到协调者进一步的请求,会导致数据不一致情况。
- 太过保守:协调者收不到参与者响应时,只能通过超时机制进行判断是否需要中断事务。
三阶段提交协议(3PC)
- 第一阶段(CanCommit 阶段):协调者询问参与者事务是否可以正常执行。
- 第二阶段(PreCommit 阶段):协调者根据参与者的反应情况来决定是否可以执行事务的PreCommit操作。决定是进行事务预提交还是abort中断事务请求。
- 第三阶段(doCommit 阶段):根据二阶段响应决定提交事务还是回滚事务。此阶段若参与者超时未收到协调者的请求,则会自己进行事务的提交。
3PC的优缺点
- 协调者也引进了超时机制,避免了长时间未收到协调者的请求导致的资源占用。
- 增加了一个阶段进行事务提交前的确认。
- 依旧未解决数据一致性问题。
4 NWR协议
- N:在分布式存储系统中,有多少份备份数据
- W:代表一次成功的更新操作要求至少有w份数据写入成功
- R: 代表一次成功的读数据操作要求至少有R份数据成功读取
- 当W+R>N时,可以保证数据的强一致性。这样成功写和成功读的数据保证有交集。
5 Gossip协议
- Gossip 协议也叫 Epidemic 协议 (流行病协议)。原本用于分布式数据库中节点同步数据使用,后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。
- gossip 协议利用一种随机的方式将信息传播到整
个网络中,并在一定时间内使得系统内的所有节点数据一致。Gossip 其实是一种去中心化思路的分布式协议,解决状态在集群中的传播和状态一致性的保证两个问题。
传播模式
- 反熵传播:是以固定的概率传播所有的数据。所有参与节点只有两种状态:Suspective(病原)、Infective(感染)。过程是种子节点会把所有的数据都跟其他节点共享,以便消除节点之间数据的任何不一致,它可以保证最终、完全的一致。缺点是消息数量非常庞大,且无限制;通常只用于新加入节点的数据初始化。
- 谣言传播:是以固定的概率仅传播新到达的数据。所有参与节点有三种状态:Suspective(病原)、Infective(感染)、Removed(愈除)。过程是消息只包含最新 update,谣言消息在某个时间点之后会被标记为 removed,并且不再被传播。缺点是系统有一定的概率会不一致,通常用于节点间数据增量同步
6 Paxos协议
Paxos算法是基于消息传递且具有高度容错特性的一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一。
Paxos通过引入多个协调者,解决2PC和3PC协调者单点的问题。
Basic Paxos
- Proposer提出一个提案,编号为N, 此N大于这个Proposer之前提出所有提出的编号, 请求Accpetor的多数人接受这个提案
- 如果编号N大于此Accpetor之前接收的任提案编号则接收, 否则拒绝
- 如果达到多数派, Proposer会发出accept请求, 此请求包含提案编号和对应的内容
- 如果此Accpetor在此期间没有接受到任何大于N的提案,则接收此提案内容, 否则忽略
存在问题
- 需要两次RPC调用
- 多个提案者并发时可能存在活锁问题。可通过随机时间进行避免
Multi-Paxos
- 首次提案时确定Acceptor议员的leader,后续直接由leader确定提案是否成功。只有首次提案需要次RPC,后续只需要一次RPC调用
- Multi-Paxos协议的落地方案有Raft和ZAB
7 Raft协议
- 竞选阶段:Follower会有一个定时时间,这个时间到达还未收到Leader节点的心跳信息,Follower就会成为 Candidate节点。 Candidate会向其他节点发送投票信息(携带任期),当收到过半票数就会成为Leader,并且会周期性的向其他节点发送心跳。
- 多个 Candidate节点:当同时出现多个 Candidate时,可能会出现相同票数导致重新选举,这样通过给一个随机竞选超时时间,避免出现多个 Candidate。
- 日志复制:Leader节点收到数据更新请求后,修改数据后并不会立刻提交,需要同步多数的Follower节点进行修改后,才会进行提交,然后通知Follower节点提交。
- 网络分区:网络问题导致部分节点收不到Leader节点心跳,这些节点会重新进行选举。
- 网络分区日志复制:分区下节点数量少的,可能因为更新数据时候达不到过半节点的同意,导致无法更新数据。当分区合并时,选取任期大的分区主节点作为Leader节点,然后进行数据的同步。
8 Lease机制
- 什么时Lease机制?节点向Lease颁发者申请Lease,申请成功的作为Leader节点,Lease保证这个节点这段时间内都会是主节点。
- 解决了什么问题?防止主节点因为网络短暂问题(未宕机),与其他从节点失去联系,而其他从节点马上进行了选举新的主节点。采用Lease机制,在主节点Lease的有效期内,其他节点无法申请到Lease。保证同一时刻只有一个主节点。
- Lease的租期不宜过长,不然主节点真出现问题,系统可用性就降低了。