#数据库配置信息 #DBCP dbcp.driverClassName=com.MysqL.jdbc.Driver dbcp.dbJDBCUrl=jdbc:MysqL://127.0.0.1:3306/lagou-test dbcp.username=zm dbcp.password=1234 dbcp.maxActive=30 dbcp.maxIdle=10配置获取 集群中每台机器在启动初始化阶段，⾸先会从上⾯提到的ZooKeeper配置节点上读取数据库信息，同 时，客户端还需要在该配置节点上注册⼀个数据变更的 Watcher监听，⼀旦发⽣节点数据变更，所有订 阅的客户端都能够获取到数据变更通知。 配置变更 在系统运⾏过程中，可能会出现需要进⾏数据库切换的情况，这个时候就需要进⾏配置变更。借助 ZooKeeper，我们只需要对ZooKeeper上配置节点的内容进⾏更新，ZooKeeper就能够帮我们将数据变 更的通知发送到各个客户端，每个客户端在接收到这个变更通知后，就可以重新进⾏最新数据的获取。 命名服务 全局唯⼀ID⽣成的ZooKeeper节点示意图
说明，对于⼀个任务列表的主键，使⽤ZooKeeper⽣成唯⼀ID的基本步骤： 1. 所有客户端都会根据⾃⼰的任务类型，在指定类型的任务下⾯通过调⽤create（）接⼝来创建⼀个 顺序节点，例如创建“job-”节点。 2. 节点创建完毕后，create（）接⼝会返回⼀个完整的节点名，例如“job-0000000003”。 3. 客户端拿到这个返回值后，拼接上 type 类型，例如“type2-job-0000000003”，这就可以作为⼀个 全局唯⼀的ID了。 在ZooKeeper中，每⼀个数据节点都能够维护⼀份⼦节点的顺序顺列，当客户端对其创建⼀个顺序⼦节 点的时候 ZooKeeper 会⾃动以后缀的形式在其⼦节点上添加⼀个序号，在这个场景中就是利⽤了 ZooKeeper的这个特性 分布式锁 都是使用zk的创建节点实现：排他锁通过创建临时解点。共享锁：临时顺序节点。 分布式队列 分布式队列可以简单分为两⼤类：⼀种是常规的FIFO先⼊先出队列模型，还有⼀种是 等待队列元素聚 集后统⼀安排处理执⾏的Barrier模型。 ① FIFO先⼊先出 FIFO（First Input First Output，先⼊先出）， FIFO 队列是⼀种⾮常典型且应⽤⼴泛的按序执⾏的队列 模型：先进⼊队列的请求操作先完成后，才会开始处理后⾯的请求。使⽤ZooKeeper实现FIFO队列，和之前提到的共享锁的实现⾮常类似。FIFO队列就类似于⼀个全写的共 享锁模型，⼤体的设计思路其实⾮常简单：所有客户端都会到/queue_fififo 这个节点下⾯创建⼀个临时 顺序节点，例如如/queue_fififo/host1-00000001。 ② Barrier：分布式屏障 Barrier原意是指障碍物、屏障，⽽在分布式系统中，特指系统之间的⼀个协调条件，规定了⼀个队列的 元素必须都集聚后才能统⼀进⾏安排，否则⼀直等待。这往往出现在那些⼤规模分布式并⾏计算的应⽤ 场景上：最终的合并计算需要基于很多并⾏计算的⼦结果来进⾏。这些队列其实是在 FIFO 队列的基础 上进⾏了增强，⼤致的设计思想如下：开始时，/queue_barrier 节点是⼀个已经存在的默认节点，并且 将其节点的数据内容赋值为⼀个数字n来代表Barrier值，例如n=10表示只有当/queue_barrier节点下的 ⼦节点个数达到10后，才会打开Barrier。之后，所有的客户端都会到/queue_barrie节点下创建⼀个临 时节点。 ZAB协议介绍 ZAB协议包括两种基本的模式：崩溃恢复和消息⼴播 进⼊崩溃恢复模式： 当整个服务框架启动过程中，或者是leader服务器出现⽹络中断、崩溃退出或重启等异常情况时，ZAB 协议就会进⼊崩溃恢复模式，同时选举产⽣新的leader服务器。当选举产⽣了新的leader服务器，同 时集群中已经有过半的机器与该leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式，其 中，所谓的状态同步 就是指数据同步，⽤来保证集群中过半的机器能够和leader服务器的数据状态保 持⼀致 进⼊消息⼴播模式： 当集群中已经有过半的Follower服务器完成了和leader服务器的状态同步，那么整个服务框架就可以进 ⼊消息⼴播模式，当⼀台同样遵守ZAB协议的服务器启动后加⼊到集群中，如果此时集群中已经存在⼀ 个leader服务器在负责进⾏消息⼴播，那么加⼊的服务器就会⾃觉地进⼊数据恢复模式：找到leader 所在的服务器，并与其进⾏数据同步，然后⼀起参与到消息⼴播流程中去。Zookeeper只允许唯⼀的⼀ 即：所有事务请求必须由⼀个全局唯⼀的服务器来协调处理，这样的服务器被称为leader服务器，余下的 服务器则称为Follower服务器，leader服务器负责将⼀个客户端事务请求转化成⼀个事务Proposal（提 议），并将该Proposal分发给集群中所有的Follower服务器，之后leader服务器需要等待所有 Follower服务器的反馈，⼀旦超过半数的Follower服务器进⾏了正确的反馈后，那么leader就会再次向 所有的Follower服务器分发Commit消息，要求其将前⼀个Proposal进⾏提交个leader服务器来进⾏事务请求的处理，leader服务器在接收到客户端的事务请求后，会⽣成对应的 事务提议并发起⼀轮⼴播协议，⽽如果集群中的其他机器收到客户端的事务请求后，那么这些⾮leader 服务器会⾸先将这个事务请求转发给leader服务器。 ① 消息⼴播 ZAB协议的消息⼴播过程使⽤原⼦⼴播协议，类似于⼀个⼆阶段提交过程，2pc，针对客户端的事务请求， leader服务器会为其⽣成对应的事务Proposal，并将其发送给集群中其余所有的机器，然后再分别收集 各⾃的选票，最后进⾏事务提交。 ② 崩溃恢复 ZAB协议的这个基于原⼦⼴播协议的消息⼴播过程，在正常情况下运⾏⾮常良好，但是⼀旦在leader服 务器出现崩溃，或者由于⽹络原因导致leader服务器失去了与过半Follower的联系，那么就会进⼊崩溃 恢复模式。在ZAB协议中，为了保证程序的正确运⾏，整个恢复过程结束后需要选举出⼀个新的leader 服务器，因此，ZAB协议需要⼀个⾼效且可靠的leader选举算法，从⽽保证能够快速地选举出新的 leader，同时，leader选举算法不仅仅需要让leader⾃身知道已经被选举为leader，同时还需要让集 群中的所有其他机器也能够快速地感知到选举产⽣出来的新leader服务器。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
