关于Zookeeper

Posted 2020-11-19 canmeng-cn

数据访问：
zookeeper节点上的数据都是以原子的方式读取和写入的。读取时获取节点下的所有数据，写入将替换节点下的所有数据。每个节点都有一个访问控制列表，控制谁可以做什么
zookeeper会话安全的保证，当zookeeper客户端与服务端建立连接时，zookeeper会创建一个会话session发送给客户端。为保证会话安全，服务端会为每一个会话id创建一个密码
发送给客户端，并将该密码同步到集群的其他服务器，客户端连接服务器时会通过会话id将该密码发送到服务端进行验证
zookeeper集群的每个节点都存储了全量数据信息，以此来提高读性能，适用于读多写少的场景
zookeeper采用事务日志文件和快照文件两种方式来保证数据安全

ZAB协议：
    一、广播：zab协议中，所有的写请求，都由leader来处理，并将更新广播到整个系统
        1、leader接收到新的请求后，生成一个全局唯一的64位自增的zxid，通过zxid的大小实现因果有序
        2、leader通过队列，将带有zxid的消息作为一个案例（proposal）分发给所有的follower
        3、follower接收到提案后（proposal）后，现将proposal写到磁盘，写入成功后向leader发送一个ack消息
        4、leader接收到一半以上的follower的ack消息后，向所有的follower发送commit命令，同时本地执行该命令
        5、follower接收到commit并执行
        
    zab协议不能终止事务，follower要么回ack给leader，要么抛弃leader，在某一个时刻，follower和leader的状态可能是不一致，因此它不能处理leader挂掉的情况，所以引入
    恢复来解决这一问题
    
    二、恢复：当服务初次启动、或者leader挂掉，系统自动进入恢复模式，直到选出合法的leader，然后由新leader负责将整个系统同步到最新状态
    已处理的消息不能丢失
        1、选举拥有最大的zxid的节点作为新的leader，
        2、新leader将自己事务日志中的proposal单位commit的消息处理完成
        3、新leader与follower之间建立一个队列，将自身有但是follower没有的proposal发送给follower，再将这些proposal的commit发送给follower，以此来保证所有的follower
        都处理了所有的消息
        
    被丢弃的消息不能再次出现
        考虑这样的一个场景，leader接收到新的消息并生成了一个proposal，但并未将该proposal发送出去就挂掉了，因此所有follower节点上面都没有该proposal信息，因此经过
        恢复模式选举出新的leader后该消息将被跳过。此时该节点重新恢复并注册成为follower，他保留了被跳过消息的proposal状态，与整个系统状态是不一致的，需要将其删除
        
        

两阶段锁/三阶段锁

一、两阶段锁：
    第一阶段：
        1、协调者询问所有参与者节点，是否可以执行提交操作
        2、各参与者开始事物执行的准备
        3、准备完成，回复协调者可以提交或不可以提交
    第二阶段
        1、如果所有参与者都回复“可提交”，则协调者发出“正式提交”命令，否则发送“回滚”命令
        2、协调者接收各参与者处理结果信息，完成整个事务

二、三阶段提交
    第一阶段：协调者向所有参与者节点询问是否可以提交，并接收所有参与者节点的返回信息
    第二阶段：协调者向所有参与者节点发送准备提交命令，参与者节点执行准备工作（锁定资源、记录日志等）
    第三阶段：协调者向所有参与者节点发送正式提交命令，参与者执行提交并返回执行结果，协调者处理完之后结束整个事务