启动或leader宕机选举leader流程

myid：当前服务机器的id
ZXID：是64位长度的Long类型，其中高32位表示纪元epoch，低32位表示事务标识xid。即zxid由两部分构成 epoch 和 xid。每个leader都会具有不同的epoch值，表示一个纪元，每个新的选举开启时都会生成一个新的epoch，新的leader产生，会更新所有的zkServer的zxid和epoch，xid是一个依次递增的事务编号。
image.png

leader选举多层队列架构

整个zookeeper选举底层可以分为选举应用层和消息传输层，应用层有自己的队列统一接收和发送选票，传输层也设计了自己的队列，但是按发送的机器分了队列，避免给每台机器发送消息时相互影响，比如某台机器如果出问题发送不成功则不会影响对正常机器的消息发送。
image.png

源码流程图

未命名文件.png

问题一：zk 节点宕机如何处理？

Zookeeper 本身也是集群，推荐配置不少于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时，其他节点会继续提供服务。
如果是一个 Follower 宕机，还有 2 台服务器提供访问，因为 Zookeeper 上的数据是有多个副本的，数据并不会丢失；
如果是一个 Leader 宕机，Zookeeper 会选举出新的 Leader。
ZK 集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在 ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。
所以
3 个节点的 cluster 可以挂掉 1 个节点(leader 可以得到 2 票>1.5)
2 个节点的 cluster 就不能挂掉任何 1 个节点了(leader 可以得到 1 票<=1)

问题二：为什么推荐使用自增整型的主键而不是UUID？

a）整型占用空间更少，查找过程中值比较效率也更高
b）自增主键与索引有序的特性相吻合，在新增主键时一般不会导致叶子节点频繁分裂以及平衡

问题三：ZK集群最少要几台机器，集群规则是怎样的？集群中有 3 台服务器，其中一个节点宕机，这个时候 Zookeeper 还可以使用吗？

集群规则为 2N+1 台，N>0，即 3 台。可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。

问题四：什么是事务id和trx_id？

如果是只读事务：只有在它第一次对某个用户创建的临时表执行增删改操作时，才会为这个事务分配一个事务id，否则是不分配的。如果是读写事务：只有在它第一次对某个表（包括用户创建的临时表）执行增删改操作时，才会为这个事务分配一个事务id，否则是不分配的。综上所述，只有在事务对表中的记录进行改动时才会为这个事务分配一个唯一的事务id，否则事务id值默认为0。事务id本质上就是一个数字，事务id生成策略如下： 内存中维护一个全局变量，每当需要为某个事务分配事务id时，就会把该变量值当作事务id分配给该事务，并且自增1。 每当这个变量的值为256的倍数时，就会将值刷新到系统表空间中页号为5的页面中一个名为Max Trx ID的属性中（占用8个字节）。 当系统下一次启动时，会将Max Trx ID的值加载到到内存中，并加上256之后赋值给前面提到的全局变量。 因为上次关机时，该全局变量的值可能大于磁盘页面中的Max Trx ID属性值。 trx_id的含义 表示对这个聚簇索引记录进行改动的语句所对应的事务id。

问题五：简单描述一下ZK选举机制

zookeeper是按照ZAB算法进行选举的，这个算法也称之为半数选举机制。
所有节点都有投票权，当一个几点票数过半，这个节点就是leader。
zookeeper机制规定，当有新的节点加入时，没有选举出leader时之前票数作废，重新投票。
leader产生后，其他节点投票给leader。
1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

问题六：Jedis 与 Redisson 对比有什么优缺点？

Jedis 是 Redis 的 Java 实现的客户端，其 API 提供了比较全面的 Redis 命令的支持；
Redisson 实现了分布式和可扩展的 Java 数据结构，和 Jedis 相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等 Redis 特性。Redisson 的宗旨是促进使用者对 Redis 的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。

问题七：ZAB 和 Paxos 算法的联系与区别？

相同点：
（1）两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower 进程的运行
（2）Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提案进行提交
（3）ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader周期，Paxos 中名字为 Ballot
不同点：
ZAB 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建分布式一致性状态机系统。

问题八：Redis 集群会有写操作丢失吗？为什么？

Redis 并不能保证数据的强一致性，这意味着在实际中集群在特定的条件下可能会丢失写操作