分布式一致性原理、Paxos算法与Zookeeper的ZAB协议、Zookeeper使用场景与在电商系统中的应用

阳光穿透心脏的1/2处 2022-05-24 06:48 125阅读 0赞

### 分布式一致性原理 ###

1.CAP定理：一个分布式系统不可能同时满足一致性（C），可用性（A）和分区容错性（P）这三个基本需求，最多只能同时满足其中的两项。

2.2PC：   
Prepare（投票）；Commit（事务提交），中断Rollback（事务回滚）   
优点：原理简单，实现方便   
缺点：同步阻塞，单点问题，脑裂（主从数据不一致）、保守（协调者超时机制判断是否要中断事务）等

> 案例：
> 
> 1.引申：淘宝TCC 分布式事务框架（Try-Commit-Cancel）   
> 2.应用：交易柔性分布式事务处理框架（Horcrux）。基于 Try-Commit 阶段 RPC 处理；Commit-Failure 与Cancel-Failure 采用超时机制（Activity 表超时处理）；对于 Cancel 与Timeout 采用 Spark Streaming/Storm+MQ+Dubbo 实现异步补偿与回滚。

3.3PC：事务询问（CanCommit）；执行事务预提交（PreCommit）；执行提交（DoCommit），中断 Rollback。

存在问题：协调者故障，或者协调者与参与者之间网络故障，此时通过参与者超时机制，继续提交事务。

优点是降低了参与者的阻塞范围，能够在先单点故障后继续达成一致。

缺点是在参与者接收到预提交消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务提交，这必然出现数据的不一致性。

### Paxos描述 ###

参见链接：[Paxos定于与描述][Paxos]

### ZAB协议 ###

1.ZAB架构设计   
[Architecture of ZAB – ZooKeeper Atomic Broadcast protocol][Architecture of ZAB _ ZooKeeper Atomic Broadcast protocol]

2.ZAB 与 Paxos比较   
[ZAB vs Paxos][]   
ZAB集群机器越多，写性能会有所降低、读性能得到水平扩展。然而基于Paxos实现的Chubby读写相对ZK复杂。   
同时ZK的每一个操作都具有隐形事务要求，通过强一致性保证数据节点的数据的顺序性（FIFO）。Paxos协议无法实现多个写操作的顺序性，或者通过串行操作实现，如此则以牺牲效率为代价。

### ZooKeeper应用 ###

1.ZK可以实现发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

*  发布/订阅模式：   
    
    
     *  在处理自定义事件时，观察者模式和发布/订阅模式经常使用，起初不了解这两个模式的实现时，在网上看一些资料，很多介绍都将两种模式混淆在一起，认为他们是同一个模式、一样的实现。后来看了一些设计模式的书籍，感觉两种模式还是有本质的区别，具体如下：   
        
        
         *  观察者模式至少需要维护两个对象   
            
            
             *  顾名思义：有观察者对象，肯定也得有观察者需要关注的目标对象，在观察者模式实习的时候，观察者对象需要定义一个统一的接口，在目标对象发生某些改变时，调用（触发）观察者的对应的方法，通知观察者到底发生了那些变化。
             *  而发布订阅模式，只需要注册订阅器上的一个事，而订阅器发生某些事件，则会触发事件通道里面的函数，触发器并不会关心其他任何对象和任何接口
         *  在实现自定义事件方面我觉得使用发布/订阅模式更为合适，简单、耦合性比较低。使用发布订阅模式时，我们关注那个对象，只需要在这个注册这个对象的对应的事件即可，降低了订阅者和发布者直接的耦合。
 *  负载均衡：   
    
    
     *  本质是利用zookeeper的配置管理功能
     *  步骤为：   
        
        
         *  服务提供者把自己的域名及IP端口的映射注册到zk中
         *  服务消费者通过域名从zk中获取到对应的IP及端口，这个IP及端口有多个，只是获取其中一个
         *  当服务宕机时，对于的域名与IP的对于就会减少一个映射
 *  命名服务：   
    
    
     *  Zookeeper 的 Name Service 与 JNDI 能够完成的功能是差不多的，它们都是将有层次的目录结构关联到一定资源上。也许你并不需要将名称关联到特定资源上，你可能只需要一个不会重复名称，就像数据库中产生一个唯一的数字主键一样。
 *  分布式协调/通知：   
    
    
     *  通过watcher的通知机制实现   
        
        
         *  通过 watcher 实现分布式数据的发布/订阅功能
         *  watcher 包括客户端线程，客户端 WatcherManager ， Zookeeper 服务器三个部分
         *  客户端在向 zk 服务器注册 watcher 的同时，会将 watcher对象存储在客户端的WatcherManager 中，当 Zookeeper 服务器端触发 Watcher 事件后，会向客户端发送通知，客户端线程从 WatcherManager 中取出对应的 Watcher 对象来执行回调逻辑。   
            ![这里写图片描述][20161204204823580]
 *  分布式锁：共享锁，排他锁
    
     *  排他锁（Exclusive Locks）   
        
        
         *  引申：又成为写锁或独占锁，Java 中使用 synchronized 机制和 JDK5提供的 ReentrantLock 定义锁，数据对一个事务可见。
         *  Zookeeper 使用数据节点（ZNode）表示一个锁，即只存在/exclusive\_lock/lock。   
            ![这里写图片描述][20161204204904824]
     *  共享锁（Shared Locks）   
        
        
         *  引申：又成为读锁，数据对所有事务可见。
         *  存在/shard\_lock/lock\_no1，/shard\_lock/lock\_no2等多个临时顺序节点
         *  读写请求：   
            
            
             *  读请求：如果没有比自己序号小的子节点，或者所有比自己序号小的子节点都是读请求，表明自己获取到了共享锁，开始读取逻辑。如果比自己序号小的子节点中有写请求，则进入等待
             *  写请求：如果自己不是序号最小的子节点，则进入等待
             *  如图，可以避免 ZooKeeper 发送节点变更 Watcher 通知给所有机器，即『羊群效应』。   
                ![这里写图片描述][20161204204952091]
     *  分布式事务
    
    > 案例：
    > 
    > 1.引申：基于MQ的分布式事务补偿机制   
    > 2.应用：交易和资金对资源回滚不做同步 RPC调用，而是通过MQ（事务 MQ 或 Mysql+Canal+RocketMQ）交互，通过将消息发送到MQ,然后由资源应用自己去监听MQ的事件
 *  集群管理
    
     *  通过管理 zk 临时节点的顺序子节点，实现集群管理
 *  Master选举   
    
    
     *  原理：   
        
        
         *  服务器争抢创建标志为Master的临时节点
         *  服务器监听标志为Master的临时节点，当监测到节点删除事件后展开新的一轮争抢
         *  某个服务器成功创建则为Master   
            ![这里写图片描述][20161204205111546]
 *  分布式队列   
    
    
     *  业界参考Alibaba RocketMQ
     *  FIFO队列：利用zk的共享锁机制实现
     *  分布式系统协调：如合并计算结果等   
        ![这里写图片描述][20161204211134699]

2.ZK可以保证顺序一致性、原子性、单一视图、可靠性、实时性的功能。

3.Zookeeper并发控制

*  Zookeeper 版本号机制，通过乐观锁进行并发控制   
    
    
     *  乐观锁又成为乐观并发控制，适用于数据并发竞争不大，事务冲突较少的应用中
     *  悲观所适用于数据更新竞争十分激烈的场景，如分布式 DB SequenceID 申请
     *  乐观锁事务分为三个阶段：数据读取，写入校验，数据写入
     *  写入校验阶段是乐观锁的关键，事务会检查数据在读取阶段后是否有其他事务对数据进行过更新，以确保数据更新的一致性。通过 JDK 中的 CAS 乐观锁实现

4.Zookeeper角色

*  Leader（设计模式：责任链模式）   
    
    
     *  事务请求的唯一调度和处理者，保证集群事务处理的顺序性
     *  集群内部各个服务器的调度者
 *  Follower（设计模式：责任链模式）   
    
    
     *  处理客户端非事务请求，转发事务请求给Leader服务器
     *  参与事务请求Proposal投票
     *  参与Leader选举投票
 *  Observer   
    
    
     *  只提供非事务服务，事务请求（Proposal投票与Leader选举）会转发给Leader服务器
     *  用于不影响集群事务处理能力条件下提升集群的非事务处理能力

5.集群间消息通信   
6.znode的类型

*  persistent znode，如/path，只能通过zk的api删除（delete）
 *  ephemeral znode，当创建该节点的客户端崩溃或关闭了与zk的连接时，这个节点就会被删除。
 *  有序节点：一个有序znode节点被分配唯一一个单调递增的整数。

8.zk服务器端运行在两种模式下：独立模式（standalone）和仲裁模式（quorum）。standalone下zk状态无法复制，quorum下会有一组zk服务器，即zk集合，可以进行状态复制。

转载于：https://blog.csdn.net/zhengzhihust/article/details/53456371

[Paxos]: http://paxos.systems/why.html
[Architecture of ZAB _ ZooKeeper Atomic Broadcast protocol]: https://distributedalgorithm.wordpress.com/2015/06/20/architecture-of-zab-zookeeper-atomic-broadcast-protocol/
[ZAB vs Paxos]: https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab+vs.+Paxos
[20161204204823580]: /images/20220524/ab040debb329430a9bc4ecda0cf1e68a.png
[20161204204904824]: /images/20220524/3a5f7d401a59413fa3954fc9457dd8c9.png
[20161204204952091]: /images/20220524/13c4647afc284dbc9fe1e98454a6a5f1.png
[20161204205111546]: /images/20220524/462c58047f4945a8a0225d65d714f8fd.png
[20161204211134699]: /images/20220524/a4968cfeae974719b7563f968b30b684.png