大数据协议知识

发表于 更新于 分类于

空闲整理下协议相关知识

协议总览

1
2
3
4
5
ZAB
Paxos
Raft
2PC
Quorum

ZAB协议

介绍_ZK选举

1
2
3
4
5
6
7
8
9
10
11
全程Zookeeper Atomic Broadcast(ZK原子广播)
使用场景,Zookeeper
过程:
    实现了主备模型的系统架构来保证集群中各个副本之间数据的一致性
    Leader将客户端的操作转化为Proposal,Leader在操作完数据后向所有Follower发送广播请求,等待反馈
    ZAB协议中,超过半数Follower节点反馈成功,Leader向所有Follower发送Commit消息
    Follower进行数据操作.

看上面的过程,Leader先是将操作广播给Follower,等待反馈,然后再将Commit消息发送给Follower.
这个过程和2PC很相似,只不过2PC要么全部反馈成功,要么全部反馈失败(精确一次).
而ZAB只需要半数反馈成功即可.

疑问点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
1.为什么ZAB协议不会同步阻塞?
    因为Leader和每一个Follower之间收发消息都有单独的队列,做到了异步.
2.ZAB只要半数反馈成功,怎么保证的数据一致性?
    首先ZAB中只能是Leader接收写请求,其次如果Leader宕机,ZAB要求集群进行崩溃恢复和Leader选举
    其中崩溃恢复必须确保:
        1.已经被Leader提交的Proposal必须被所有Follower提交
        2.丢弃Leader没有提交Proposal(保证Follower没有未提交Proposal,一定比宕机Leader的Proposal小)
    Leader宕机时存在未提交的Proposal在崩溃恢复后,新选举的Leader肯定是换了节点
    新Leader会把自身最大Proposal的ZXID发送给其他Follower
    Follower对比自身Proposal的ZXID,自身大则回退,自身小则进行数据同步.
3.ZXID是什么?
    64位的数字,低32位按照数字递增,客服端发送Proposal,低32位简单加1
    高32位是Leader周期的epoch编号,每选举出新的Leader,Leader都从本地Proposal获取ZXID,解析出高32位epoch编号,进行加1
    低32位全部设置为0,保证ZXID的唯一性,并且递增.
4.Leader崩溃,已经提出但是未提交的Proposal被丢弃,是不是意味着ZK丢失了一次请求?
    我个人认为是丢失了,没有重试机制的话,对应就应该是ZK请求失败.

Paxos

介绍

1
2
3
4
5
6
解决问题:
    每个人都有提出建议,同意建议,接受建议的权利
    最终的采纳哪个建议,采取少数服从多数的方式
采纳方式:
    只有被提出的建议才能被大家同意
    只能采纳一个建议

流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
A,B,C三个人提议吃东西(对吃什么各持己见)
A-->日料
B-->法餐
C-->中餐

提议顺序 A->B->C

Prepare阶段
    A将提议(1)发送给BC
        BC没有接受小于编号为1的提议,BC接受,并不再接受小于1的提议
    B将提议(2)发送给AC
        A没有接受小于编号为2的提议,A接受,并不再接受小于2的提议
        C接受过编号为1的提议,但是2>1,C接受,并不再接受小于2的提议
    C将提议(3)发送给AB
        A接受过编号为2的提议,但是3>2,A接受,并不再接受小于3的提议
        B接受过编号为2的提议,但是3>2,B接受,并不再接受小于3的提议

Accept阶段
    A将提议(1,日料)发送给BC
        B不接受小于3的提议,拒绝
        C不接受小于2的提议,拒绝
        A的票数0,再次进入Prepare阶段
    B将提议(2,法餐)发送给AC
        A不接受小于3的提议,拒绝
        C不接受小于2的提议,接受
        B的票数为1
    C将提议(3,中餐)发送给AB
        A不接受小于3的提议,接受
        B不接受小于3的提议,接受
        C的票数为2

C(3,中餐)获得多数人同意

Raft

介绍_动画

1
2
3
4
5
个人看Raft和ZAB很是相似,也是超过半数选举成功即可
角色:
    Leader
    Follower
    Candidate(候选)

选主

1
2
3
4
5
6
7
8
多Candidate选主
    4个节点都是Follower,有两个Follower同时Timeout,变成Candidate
    Candidate: A B
    Follower: C D
    分别给另外的Follower发送投票请求(自身给自身投一票),此处遵循先后的关系,分为下列情况:
        A->C,B->D,A->D,B->C,投过票的Follower会拒绝请求,即AB各2票,进入下一轮投票
        A->C,A->D,B->C,B->D,A率先获得3票,会转化为Leader,期间B可以发起投票,但CD不会同意
    Leader进行心跳,Candidate接收到会转化为Follower

2PC

介绍

1
2
3
4
两阶段提交,强一致性,中心化的原子提交协议
Coordinator(协调者)
Partcipant(参与者)
顾名思义,两阶段提交,分为两个阶段:投票阶段,提交阶段

流程

1
2
3
4
5
6
7
8
9
10
11
12
13
第一阶段
    Coordinator向所有的Partcipant发送Prepare,并等待反馈
    Partcipant接收到了Prepare,先执行本地事务操作(不会真正的执行),向Coordinator发送反馈
    结果产生:1.所有Partcipant都反馈成功,2.存在反馈不成功的情况,只有1才会进入第二阶段
第二阶段
    Coordinator向所有的Partcipant发送Commit
    所有Partcipant执行Commit操作

如果有出现反馈不成功情况
    Coordinator向所有的Partcipant发送Rollback
    Partcipant执行回滚操作

2PC是有很多坑的

Quorum

介绍

1
2
3
4
5
6
准确来讲是一种机制,确保一次写操作在多个副本中有半数副本操作成功,则说明这次写操作成功
读操作也确保读超过半数的副本,则总会读取到最新的数据

使用场景:Hadoop HA的QJM(Quorum Journal Manager)
当Active Namenode向QJM写入Editlog时,要求半数以上的QJM写入成功,才算操作成功
Standby Namenode定期从QJM上获取最新的Editlog更新自身的数据