(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