• 欢迎访问蜷缩的蜗牛博客 蜷缩的蜗牛
  • 微信搜索: 蜷缩的蜗牛 | 联系站长 kbsonlong@qq.com
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

Zookeeper 与 Kafka (3) : Zookeeper

Zookeeper 蜷缩的蜗牛 5个月前 (05-25) 48次浏览 已收录

0. Chubby 协议

面向松耦合分布式系统的锁服务, 解决分布式中的一致性问题.

锁服务:

粗粒度的锁服务: 客户端会长时间持有锁.
锁在分布式系统中的用途:

允许客户端进程同步彼此的操作, 并对当前所处环境的基本信息达成一致.

通过”文件”实现锁:

首先, Chubby 是一个分布式文件系统, 对其而言: 锁就是文件.

创建文件就是进行”加锁”操作, 而成功创建文件的服务器就抢占到了”锁”.
用户通过打开, 关闭, 读取文件获取共享锁或者独占锁.
文件有更新时, 会通知相关的用户.

系统架构图

分为两个部分: 服务器称为 Chubby cell;�每个 client 都有一个 Chubby library。

两端使用 RPC 进行通信.
客户端通过 Chubby library 的接口调用, 在 Chubby cell 上创建文件来获取锁.

优势

开发人员对基于锁的接口更为熟悉, 远比一致性协议的库更为友好.

对上层应用程序的侵入性更小, 易于保持系统已有的程序结构和网络通信模式.

便于提供数据的发布与订阅, 以让客户端实时地感知到 Master 的变化.
允许客户端在�服务器上进行小文件的读写操作.
更便捷地构建更可靠的服务. 需要 Quorum 机制进行数据项值的选定.

Master 服务器

master lease

mater 在运行过程中,不断续租来延长 lease.

客户端向记录有服务器机器列表的 DNS 来请求所有的服务器,然后逐个询问是否为 Master

非 Master 会将当前 Master 表示回馈给客户端, 达到了非常快的定位.

若集群中服务器崩溃且无法恢复, 则需要加入新机器, 并更新 DNS 列表(启动服务端程序,更新 DNS 上的机器列表).

Master 会周期性轮训 DNS 列表, 并很快感知到服务器地址的变更, 然后通知集群.

1. Ensemble

为了达到高可用性, 会同时运行多个 Zookeeper 服务器, 称为 ensemble.

zookeeper_ensemble.png

复制服务.

需要服务器集中中大多数机器正常工作, 才能提供服务.
崩溃掉的服务器, 可以使用 crash-recovery 协议来恢复并重新进入到 ensemble.

primary 服务器接收并执行所有的请求, 然后传播执行结果.

当 primary 崩溃掉后, 执行恢复协议来统一一致性状态, 并建立新的 primary.
所有读操作都是 in-memory 的, 拥有很高的速度.

每个服务器会在内存中维持一个(代表 ensemble 节点组成的)分布式文件系统的副本.
每个 client 一个到服务器的 session. 并由 ensemble 提供以下特性:

自动且透明化的故障转移.
自动化的 keep-alive.
客户请求超时.

2. 数据一致性

最终一致性(Eventual Consistency)

followers may lag(迟于) leader.

顺序的一致性(Sequential Consistency)

客户端的更新请求, 会以请求发送的顺序来被应用.

3. �节点

临时的(Ephemeral)节点

会话过期时消亡.
由其生命周期决定, 并不会有子节点.
使用场景: 组成员, leader 选举.

持久化的(Persistent)节点可以含有子节点, 类似于目录.
节点的用途:

节点可以持有(小于 1M 的)数据, 类似于文件.
提供像 创建,删除, 检查存在性的基本节点操作.

由节点构成 Group Membership

提供事件驱动模型, 客户端可以监听特定节点的变化.
对外暴露的是文件系统模型, 有层级的命名空间.

4. Replication

复制是以软件手段来增加数据的可用性.

常用于数据库和分布式系统中, 提供合理的性能, 并维持数据一致性.
在数据库中,使用延迟(deferred)更新模型.

事务由本地的服务器(replica manager)处理, 并在提交时, 转发给其它服务器.
与之相对的是立即更新模型, 它会在所有的服务器间同步事务.

复制数据库模型

由一系列运行在不同处理器上的 process 组成.
每个 process 都有数据库的一个副本, 被称为 replica manager.
每个 process 有两种状态: Up && Down.

终止协议(Termination Protocol).

向其它 process 提交事务, 并确认该动作.
在 CS 分布式系统中, 使用原子广播(atomic broadcast).
可以向多个 process 发送同一消息, 并且保证消息顺序为发送顺序.
certifier 向 Data Manager 询问已提交事务的信息, 如果该事务已经被验证通过, 它的写操作会被提交给 Lock Manager.

5. Zookeeper 的典型应用场景
5.1 配置中心: 数据的发布/订阅

推拉结合的方式:

客户端注册的关注节点发送数据变更时, 会向客户端发送 watch 事件通知.
客户端在接收到通知后, 需要主动向服务索取最新数据.

将配置信息放到 Zookeeper 上进行集中管理,

应用在启动时主动向 Zookeeper 服务器索取配置, 同时监听配置的变化.
典型场景: 全局配置信息

包含: 机器列表, 运行时开关配置, 数据库配置.
特性: 数据量小; 运行时动态变化; 各机器共享; 配置一致.

5.2 负载均衡

动态 DNS 服务. 超大规模的分布式(域名到 IP 的)映射表.

使用本地 host 绑定可以实现域名解析.

但是当主机规模庞大, 或需要更新域名时,有致命缺陷.

Dynamic DNS. 创建一个节点进行域名配置.

域名解析过程�需要每个应用自己负责.

5.3 命名服务.

资源定位不是真正的实体资源.
分布式全局唯一 ID 的分配机制.

UUID 的缺陷:长度过长,含义不明.

通过调用 Zookeeper 节点创建 API 可以创建顺序节点, 并在 API 返回值中会返回这个节点的完整名字.

创建顺序子节点时, 自动以后缀形式在子节点上添加序号.

5.4 分布式协调/通知

MySQL 数据复制总线. Mysql_Replicator.

在不同 MySQL 实例间进行异步数据复制和数据变化通知.
让不同的机器都在 Zookeeper 的�指定节点下创建临时节点, 不同机器间根据这个临时节点判断对应的客户端机器是否存活.

解耦了检测和被检测系统.
同时可实时地将自己任务执行进度写入临时节点.

5.5 集群管理

集群监控(运行时状态的收集)和集群控制(上下线操作).
基于 Agent 体系的集群管理:

每台机器上的 Agent 主动向指定的监控中心系统汇报状态.
当集群规模变大后会造成问题:

大规模升级困难; 统一的 agent 无法满足定制需求; 编程语言多样性.

特性:

当客户端对数据节点注册 watcher 监听后, 当数据节点的内容或子节点列表发生变更时,会收到通知.
临时节点会在客户端与服务器的会话失效后,被自动清除.

分布式日志收集系统.

把所有需要收集的日志机器分为多个组, 每个组对应一个后台机器作为收集器.
�特性: 变化的日志源机器, 变化的收集器机器.�达到了快速合理动态地为每个收集器分配对应的日志源机器..

本文转载自 title


蜷缩的蜗牛 , 版权所有丨如未注明 , 均为原创丨 转载请注明Zookeeper 与 Kafka (3) : Zookeeper
喜欢 (0)
[]
分享 (0)