--- url: /zookeeper.md --- ## zookeeper简介 一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。 文件系统 + 监听通知机制 数据发布/订阅 负载均衡 命名服务 分布式协调/通知 集群管理 Master选举 分布式锁 分布式队列 数据同步通常分为四类 ``` 直接差异化同步（DIFF 同步） 先回滚再差异化同步（TRUNC+DIFF 同步） 仅回滚同步（TRUNC 同步） 全量同步（SNAP 同步） ``` ## 相关 CAP 理论 CAP 理论指出对于一个分布式计算系统来说，不可能同时满足以下三点： 一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。 可用性：每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。 分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。 一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 在这三个基本需求中，最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择，zookeeper 保证的是 CP，对比 spring cloud 系统中的注册中心 eruka 实现的是 AP。 ## BASE 理论 BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。 基本可用：在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。 软状态：允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。 最终一致性：data replications 经过一段时间达到一致性。 BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。 ## 四字命令使用 echo stat | nc 192.168.3.38 2181 查看 zk 的状态信息 echo ruok | nc 192.168.3.38 2181 查看当前 zkserver 是否启动，若返回 imok 表示正常 echo dump | nc 192.168.3.38 2181 列出未经处理的会话和临时节点 echo conf | nc 192.168.3.38 2181 查看服务器配置 echo cons | nc 192.168.3.38 2181 展示连接到服务器的客户端信息 echo envi | nc 192.168.3.38 2181 查看环境变量 ## acl Access Control List，访问控制表 acl 通过 \[scheme:id:permissions] 来构成权限列表 ## 选举机制 FastLeaderElection（FLE）算法‌是 Apache ZooKeeper 中默认的‌领导者选举算法 myId：节点唯一标识（Server ID） zoo.cfg 中的 server.id=host:port1:port2 配置（id 即 myId） zxId：事务ID（ZooKeeper Transaction ID） 高32位：epoch（选举纪元）——代表 Leader 的任期编号 低32位：counter（计数器）——当前纪元内的事务序号 epoch：选举纪元（Election Epoch）——核心演进要点 先比 epoch，再比 zxId，最后比 myId FastLeaderElection 算法通过 (epoch, zxId, myId) 全序比较，实现了高效、可靠的 Leader 选举： epoch 保障选举轮次隔离，避免旧信息干扰 zxId 保障数据一致性优先，确保新 Leader 数据最新 myId 作为打破平局的最终手段，保证结果唯一 选举完成后，新 Leader 通过 DIFF、TRUNC、SNAP 等机制完成数据同步，确保集群状态一致后对外服务 server.A=B:C:D A：其中 A 是一个数字，表示这个是服务器的编号； B：是这个服务器的 ip 地址； C：表示的是这个服务器与集群中的 Leader 服务器交换信息的端口； D：表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。 初始化期间： 在初始化的时候，一般到过半的机器数的时候谁的 myid 最大一般就是 leader 运行期间： (3) 接收来自各个服务器的投票。与启动时过程相同。 (4) 处理投票。与启动时过程相同，由于 ZK1 事务 ID 大，ZK1 将会成为 Leader。 (5) 统计投票。与启动时过程相同。 (6) 改变服务器的状态。与启动时过程相同。 zk 是 cp 的，不一定保证可用性，在选举的过程中，不能对外提供服务。但在选举的过程中，首先选 zxid（zk 的事务 ID）最大的为 leader,zxid 最大，表示数据是最新的，然后广播给 follower，这样避免数据丢失。 leader 选举 原子广播 所谓整个集群是否可用，隐含的一个意思就是整个集群还能够选举出一个"Leader"。ZooKeeper 默认设置的是采用 Majority Qunroms 的方式来支持 Leader 选举。在 ZooKeeper 中 Quorums 有 2 个作用： 1. 集群中最少的节点数用来选举 Leader 保证集群可用 2. 通知客户端数据已经安全保存前集群中最少数量的节点数已经保存了该数据。一旦这些节点保存了该数据，客户端将被通知已经安全保存了，可以继续其他任务。而集群中剩余的节点将会最终也保存了该数据 采用 Quoroms 投票的方式来选举 Leader 主要是为了解决“Split-Brain”问题 节点为啥最好是基数？ 偶数的话,选取可能会产生 2 个 leader，两个 Leader 都不能满足大多数选票的原则，这时就会出现脑裂问题。 ZXID：节点本地的事务编号，由 64 位的数字组成，包含纪元值（ epoch ）和计数两部分 Zookeeper 使用 ZAB 协议来保证 Zookeeper 的数据一致性，ZAB 协议全称 Zookeeper Atomic Broadcast ，原子消息广播协议 分布式锁 InterProcessMutex：分布式可重入排它锁 InterProcessSemaphoreMutex：分布式排它锁 InterProcessReadWriteLock：分布式读写锁 SID：服务器ID。用来标识一台zookeeper集群中的机器，每台机器不能重复，和myid一致。 ZXID：事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致。 Epoch：每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟是相同的。每投完一次票这个数据就会增加。 提议proposal ## dubbo 服务治理，实时监测、管控集群状态 超高性能，面向百万实例集群设计 灵活部署模式 一键拉起服务治理体系，屏蔽底层跨平台的微服务基础设施复杂度，支持虚拟机、Docker、Kubernetes、服务网格等多种部署模式。 服务发现 Dubbo 提供了高性能、可伸缩的服务发现机制，面向百万集群实例规模设计，默认提供 Nacos、Zookeeper 等注册中心适配并支持自定义扩展。 流量管控 Dubbo 提供的基于路由规则的流量管控策略，可以帮助实现全链路灰度、金丝雀发布、按比例流量转发、动态调整调试时间、设置重试次数等服务治理能力。 通信协议 支持 HTTP/2、gRPC、TCP、REST 等任意通信协议，切换协议只需要修改一行配置，支持单个端口上的多协议发布。 多语言 SDK 提供 Java、Golang、Rust、Node.js、Python 等多语言 SDK 实现，支持基于 IDL 的跨语言服务定义和基于 Protobuf、Json 的数据编码 可扩展性 一切皆可扩展，通过扩展 (Filter、Router、Service Discovery、Configuration 等) 自定义调用、管控行为，适配开源微服务生态。 可观测性 多维度的可观测指标（Metrics、Tracing、Accesslog）帮助了解服务运行状态，Admin 控制台、Grafana 等帮助实现数据指标可视化展示。 认证鉴权 支持基于 TLS 的传输链路认证与加密通信以及基于请求身份的权限校验，帮助构建零信任分布式微服务体系。 服务网格(Service Mesh) 灵活的数据面 (Proxy & Proxyless) 部署形态支持，无缝接入 Istio 控制面治理体系。 丰富生态 一站式微服务生态适配：注册中心、网关、限流降级、负载均衡、一致性事务、异步消息、Tracing 等。 zookeeper =文件系统+通知机制 logicalclock（electionEpoch）：本地选举周期，每次投票都会自增 epoch（peerEpoch）：选举周期，每次选举最终确定完leader结束选举流程时会自增(真正zxid的前32位) zxid：数据ID，每次数据变动都会自增（真正zxid的后32位，zxid一共64位）前32位是epoch，后32位递增序列。 sid：该投票信息所属的serverId leader：提议的leader（被提议的server的serverId，即sid） 投票规则： epoch大的胜出，否则进行步骤2 zxid大的胜出，否则进行步骤3 sid大的胜出 Quorums(法定人数)法 quorum 仲裁模式 ZooKeeper ensemble ZooKeeper集合 paxos的核心就是少数服从多数 ``` proposer：提案Proposal提出者。 Acceptor：决策者，可以批准议案。 Learner：最终决策的学习者。 ``` Raft管理复制日志的一致性算法 ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。 ZAB协议中，每个Proposal中都包含一个 epoch 值来代表当前的Leader周期，Paxo标识为（Ballot ） Paxos算法用于构建一个分布式的一致性状态机系统 ZAB算法用于构建一个高可用的分布式数据主备系统 ## dubbo https://cn.dubbo.apache.org/zh-cn/overview/quickstart/ ## 核心功能 * **数据发布/订阅**：适合小型、频繁变化的数据存储与监听，客户端通过监听节点变更获取最新数据。 * **分布式锁**：主要有两种实现方式：**独占锁**（可能导致“羊群效应”）和**控制时序锁**（通过临时顺序节点实现更高效的锁机制）。 * **负载均衡**：用于在客户端实现服务发现与负载均衡，区别于 Nginx 是通过客户端主动从 Zookeeper 获取可用服务实例。 * **命名服务**：通过创建全局唯一的路径实现服务或资源的命名。 * **分布式协调/通知**：通过 **Watcher** 机制实现节点状态变更通知。 * **集群管理**：支持机器的动态上下线和 Leader 选举。Leader 选举基于 **EPHEMERAL_SEQUENTIAL** 节点的顺序性和 **强一致性**。