-
Notifications
You must be signed in to change notification settings - Fork 688
/
ZooKeeper.md
100 lines (62 loc) · 6.01 KB
/
ZooKeeper.md
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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
(PS：扫描[首页里面的二维码](README.md)进群，分享我自己在看的技术资料给大家，希望和大家一起学习进步！)
#### [1.Zookeeper是怎么进行选举的？](#zookeeper是怎么进行选举的？)
### Zookeeper是怎么进行选举的？
##### 节点的状态
looking 正在参与竞选状态，会参与投票
leading 选举结束，主节点的状态
following 选举结束，从节点的状态
一开始所有节点都是looking状态，进行选举，选举出主节点后，
主节点的状态是leading，其他节点状态是following，主节点挂了之后，需要进行新一轮的选举，所有节点又变成looking。
所有节点都有两个属性，SID：节点ID，zoo.cfg中配置的myid，ZXID：节点当前的最大事务ID
选举的目的就是选目前所有节点中拥有最大ZXID的节点作为Leader，如果拥有的ZXID相同，就选取SID最大的节点作为Leader。
##### 全新的集群leader选举
启动时，当集群没有leader时，每个机器会将票投给SID最大的机器（越晚加入的机器SID越大）
有leader时会将票投给leader。
假设有五个节点，一开始A启动时之会将票投给自己，B启动时之后将票投给B，A也投给B，C启动时，A，B，C都投个C
C得票超过半数，C成为leader，之后加入的D，E也只会投给C。
#### 非全新的集群leader选举
##### 基本原则是
1.选epoch值大的，epoch值小的投票结果会被忽略掉。
2.epoch值相同时，把票投给ZXID大的节点。
3.ZXID相同时，把票投给SID（server id）大的节点。
得票超过半数的节点会成为leader。
通常是数据越新的节点越有可能成为主节点。
##### 投票阶段
##### 1.初始化选票
将逻辑时钟+1，初始化选票，
每个节点都会投给自己，然后选票发给其他节点
##### 2.处理选票信息
从其他节点B收到投票信息后，进行处理
2.1 如果本节点的逻辑时钟小于接受这条投票的逻辑时钟，
说明本节点之前错过了上一轮的投票，将当前存储的选票信息清空，
2.2 如果本节点的逻辑时钟大于接受的这条投票的逻辑时钟，那么忽略掉这条投票信息。
2.3 本节点的逻辑时钟等于接受的这条投票的逻辑时钟，那么进行处理，与本节点当前投票的结果进行比较
先比较ZXID（数据ID，越大代表数据越新），ZXID越大的应该当leader，ZXID相同比较SID，SID越大的当leader。
2.4如果比较的结果跟当前节点的投票结果不一致，那么需要更改选票，将更改后的选票结果发送给其他节点。
2.5 将其他节点B的投票结果记录下来
##### 3.统计选票
对当前收到的所有投票信息进行统计，看是否有节点获得半数以上的选票，有的话就将它设置为leader，然后终止投票，否则继续投票，继续步骤2。
##### 4.发现阶段
所有follower会向leader发送epoch和ZXID(最大事务ID),然后leader选取最大的事务ID作为当前最新的ID
##### 5.同步阶段
通知其他follower节点进行同步，将数据更新到最大的事务ID。
##### 原子广播阶段
这时正式向客户端提供服务，leader接受客户端的写请求后，会将请求通过队列发送个每个节点，每个节点收到消息后将记录写到磁盘，
并且返回ACK给leader，当半数以上的从节点返回ACK后，leader才commit这条更新。
https://www.ymq.io/2018/05/23/zookeeper-election/
https://blog.csdn.net/MuErHuoXu/article/details/85864535
https://blog.csdn.net/hotchange/article/details/81192122
### Zookeeper工作流程？
首先客户端连接zookeeper集群中的任何一个节点，可以是leader节点，也可以是follower节点，一旦连接，节点会给客户端分配会话ID，并向客户端发送确认，如果客户端收到确认，那么连接成功，客户端会有规律地给zookeeper发送心跳包，确保连接没有断开。
* 客户端向zookeeper从节点发送读请求，节点会直接从数据库中找到这个节点的数据然后返回。
* 客户端向zookeeper从节点发送写请求，节点会将znode路径和数据转发到leader节点，leader会将写请求转换为proposal提案，并且分配一个事务ID zxid，将这个proposal放到每个节点的队列（主节点会给每个从节点分配一个专用队列）中去，然后会根据先进先出的策略，将消息发送给从节点，从节点接收到后会将事务写入到磁盘中去，然后返回ACK响应给主节点，当主节点接收到半数以上的从节点的ACK响应后，主节点会认为这个事务提交成功，完成这个事务提交，同时给所有从节点发送commit消息，从节点接收到消息后，会将这条事务提交。
由此看来zookeeper没法保证客户端读取的都是最新的数据，
### 分布式
分布式最大的难点在于各个节点的状态怎么同步。
CAP理论
C是一致性,Consistency,就是各个节点保存的数据都是最新的。
A是Availability, 可用性，每次请求都可以获得响应，但是没法保证是最新的响应。
P是分区容错性（Partition tolerance），就是每个节点可能都存在于不同的子网络，也就是不同的分区，不同分区之间的通信总是有可能发生故障的，或者总是有可能存在一些节点挂了的情况。
可以认为P总是成立的，C和A是无法同时做到。所以一般对于数据一致性要求特别高的业务，例如支付，交易相关的业务，就是会优先保证一致性C和分区容错性P，就是保证数据一致性，例如让所有子节点都收到更新后才算提交成功，就像MySQL主从同步中的全同步模式一样。普通的业务是优先保证可用性A和分区容错性P，比如在MySQL主从同步时，默认就是异步的方式，我们执行一条更新SQL，只需要主节点更新成功就行就对事务进行提交，不需要等待从节点更新数据成功，主节点会异步把SQL发送给从节点。
### 分布式锁
https://mp.weixin.qq.com/s/32lWC4PA7nF13_2wRo6i3Q