流数据分析技术笔记3 服务配置与协调

Posted 2021-06-28 Lora青蛙

服务与协调系统产生
分布式系统需要共享某些系统元数据，以及关于分布式系统本身的某些状态：元数据通常是某些配置信息；系统状态通常是用来对应用进行协调的数据；
配置和协调系统的研发动机：提供一个系统范围的服务，以便正确、可靠地实现分布式配置和协调原语

维护分布式状态
不可靠的网络连接
策略：进入降级状态；允许其中一个分区保留全部功能，而对其他的分区功能进行降级。
时钟同步
策略：使用网络定时协议（NTP）进行时钟同步
不可靠环境下的一致性
策略：Paxos算法（四种角色Proposer提议者、Acceptor决策者、Client产生议题者、Learner最终决策学习者）、Multi-Paxos算法（基于进程相对稳定、集群领导者很少发生变化这一情况）

Apache ZooKeeper

ZooKeeper是一个开源的分布式协调服务
ZooKeeper的重要概念
会话（Session）：指的是ZooKeeper服务器与客户端会话，在ZooKeeper客户端与服务端成功完成连接创建后，就创建了一个会话，在整个运行期间的生命周期中，会在不同的会话状态中进行切换，会话可以分为CONNECTING、CONNECTED、RECONNECTED、CLOSE等
Znode：ZooKeeper的节点分为两类，第一类是指构成集群的机器，称为机器节点；第二类是数据模型中的数据单元，称之为数据节点（znode）
Znode分为两类：持久节点和临时节点
持久节点：指一旦这个znode被创建，除非主动进行znode的移除操作，否则这个znode一直保存在Zookeeper上
临时节点：它的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除
版本号：ZooKeeper的每个znode上都会存储数据，对应于每个znode，ZooKeeper 都会为其维护一个叫Stat的数据结构，stat中记录了这个znode的三个数据版本，分别是version（当前znode的版本）、cversion（当前znode子节点的版本）和 aversion（当前znode的ACL版本）。
监视和通知：事件等待是ZooKeeper的主要用例之一。事件主要指znode或znode的子节点中的数据发生改变，ZooKeeper不使用轮询方式，而是使用通知（notification）系统将变化通知客户端。这里的通知也被称为监视（watch），应用要向ZooKeeper注册，才可以获悉特定znode路径上的变化。这是一次性操作，因此当通知被触发后，客户端必须注册监视来接收关于变更的通知。持续监控某个路径时，有可能丢失通知。这可能发生在客户端接收到通知之后路径发生变化，但还没有对下一次通知设置监视时，设置了一个也能从znode中读取数据的监视。这种有效方法使得客户端可以对通知进行合并。
ACL：使用Access Control Lists 策略来进行权限控制，ZooKeeper定义了以下五种权限（CREATE 创建子节点的权限、READ 获取节点数据和子节点列表的权限、WRITE 更新节点数据的权限、DELETE 删除子节点的权限、ADMIN 设置节点ACL的权限）

保持一致性
ZAB（ZooKeeper Atomic Broadcast 原子广播）协议是分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议，且主要依赖他来实现分布式数据一致性，也实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。
ZAB协议并不像Paxos算法那样，是一种通用的分布式一致性算法，它是一种特别为ZooKeeper设计的崩溃可恢复的原子消息广播算法，包括两种基本的模式，分别是崩溃恢复和消息广播。
与Paxos算法的区别：当有变化发生时，Paxos算法会更新整个状态，ZAB算法会根据状态变化的顺序来运行。
与Paxos算法的共同点：领导者节点的选举需要经过提案阶段，并在接收到仲裁的接收者发回的确认之后，才能提交提案。
ZAB协议实现的作用：
（1）使用一个单一的主进程（Leader）来接收并处理客户端的事务请求（也就是写请求），并采用了Zab的原子广播协议，将服务器数据的状态变更以 事务proposal（事务提议）的形式广播到所有的副本（Follower）进程上去。
（2）保证一个全局的变更序列被顺序引用。Zookeeper是一个树形结构，很多操作都要先检查才能确定是否可以执行，比如P1的事务t1可能是创建节点"/a"，t2可能是创建节点"/a/bb"，只有先创建了父节点"/a"，才能创建子节点"/a/b"。（为了保证这一点，Zab要保证同一个Leader发起的事务要按顺序被apply，同时还要保证只有先前Leader的事务被apply之后，新选举出来的Leader才能再次发起事务。）
（3）当主进程出现异常的时候，整个zk集群依旧能正常工作。

ZooKeeper的功能
ZooKeeper维护一个类似文件系统的数据结构，每个子目录项都被称作为 znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。（PERSISTENT：持久化目录节点、 PERSISTENT_SEQUENTIAL：持久化顺序编号目录节点、 EPHEMERAL：临时目录节点、EPHEMERAL_SEQUENTIAL：临时顺序编号目录节点）
统一命名服务：在分布式环境下对应用、服务进行统一命名，便于识别不同服务；按照层次结构组织应用、服务名称；
配置管理：
集群管理：
分布式锁：ZooKeeper是强一致的；实现锁的独占性；控制锁的时序；
分布式队列：当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种事同步队列；队列按照FIFO方式进行入队和出队操作。

ZooKeeper集群
ZooKeeper集群角色：ZooKeeper中没有选择传统的Master/Slave概念，而是引入了Leader、Follower和Observer三种角色。（Leader：投票的发起和决议，更新系统状态；Follower：接收客户请求并向客户端返回结果，在选举过程中参与投票；Observer：接收客户端连接，并将写请求转发给Leader节点，不参与投票，只同步Leader状态。）
ZooKeeper节点数据流操作：
（1）在Client向Follwer发出一个写的请求；
（2）Follwer把请求发送给Leader；
（3）Leader接收到以后开始发起投票并通知Follwer 进行投票；
（4）Follwer把投票结果发送给Leader；
（5）Leader将结果汇总后如果需要写入，则开始写入 同时把写入操作通知给Follwer ，然后commit
（6）Follwer把请求结果返回给Client

ZooKeeper安装部署
安装的三种模式：单机模式（stand-alone 单机单server）、集群模式（多机多server形成集群）、伪集群模式（单机多server形成伪集群）