zookeeper-架构设计与角色分工-《每日五分钟搞定大数据》

本篇文章阅读时间5分钟左右

点击看《每日五分钟搞定大数据》完整思惟导图

  zookeeper做为一个分布式协调系统，不少组件都会依赖它，那么此时它的可用性就很是重要了，那么保证可用性的同时做为分布式系统的它是怎么保证扩展性的？问题不少，读完接下来的内容你会有答案。

  上图来自zookeeper的官方文档，我解释下这张图的各个角色（observer在上图中能够理解为特殊的follower）

角色	分工	数量
client客户端	请求发起方	不限
observer观察者	接受用户读写请求，写转发给leader，读直接返回（选主过程不参加投票）	不限
follower跟随者	接受用户读写请求，写转发给leader，读直接返回（选主过程参加投票）	奇数个（不可过多）
leader领导者	负责提议，更新系统状态	1个

另外：follower和observer同时均为learner（学习者）角色，learner的分工是同步leader的状态。

zk的读写

  zookeeper的各个复制集节点（follower，leader，observer）都包含了集群全部的数据且存在内存中，像个内存数据库。更新操做会以日志的形式记录到磁盘以保证可恢复性，而且写入操做会在写入内存数据库以前序列化到磁盘。

  每一个ZooKeeper服务器都为客户端服务。客户端只链接到一台服务器以提交请求。读取请求由每一个服务器数据库的本地副本提供服务。更改服务状态，写请求的请求由zab协议处理。

  做为协议协议的一部分，来自客户端的全部写入请求都被转发到称为leader的单个服务器。其他的ZooKeeper服务器（称为followers）接收来自领导者leader的消息提议并赞成消息传递。消息传递层负责替换失败的leader并将followers与leader同步。

  ZooKeeper使用自定义原子消息传递协议zab。因为消息传递层是原子的，当领导者收到写入请求时，它会计算应用写入时系统的状态，并将其转换为捕获此新状态的事务。

zk的CAP原则

  cap原则是指做为一个分布式系统，一致性，可用性，分区容错性这三个方面，最多只能任意选择两种。就是一定会要有取舍。

• 一致性C

  Zookeeper是强一致性系统，同步数据很快。可是在不用sync()操做的前提下没法保证各节点的数据彻底一致。zookeeper为了保证一致性使用了基于paxos协议且为zookeeper量身定作的zab协议。这两个协议是什么东西以后的文章会讲。

• 可用性A（高可用性和响应能力）

  Zookeeper数据存储在内存中，且各个节点均可以相应读请求，具备好的响应性能。Zookeeper保证了可用性,数据老是可用的,没有锁.而且有一大半的节点所拥有的数据是最新的,实时的。

• 分区容忍性P

  有2点须要分析的

1. 节点多了会致使写数据延时很是大（须要半数以上follower写完提交）,由于须要多个节点同步.
2. 节点多了Leader选举很是耗时, 就会放大网络的问题. 能够经过引入 observer节点缓解这个问题.

zk在CAP问题上作的取舍

  严格地意义来说zk把取舍这个问题抛给了开发者即用户。

  为了协调CA（一致性和可用性），用户能够本身选择是否使用Sync()操做。使用则保证全部节点强一致，可是这个操做同步数据会有必定的延迟时间。反过来若不是必须保证强一致性的场景，可不使用sync，虽然zookeeper同步的数据很快，可是此时是没有办法保证各个节点的数据必定是一致的，这一点用户要注意。实际的开发中就要开发者根据实际场景来作取舍了，看更关注一致性仍是可用性。

  为了协调AP（一致性和扩展性），用户能够本身选择是否添加obsever以及添加个数，observer是3.3.0 之后版本新增角色，它不会参加选举和投票过程，目的就是提升集群扩展性。由于follower的数量不能过多，follower须要参加选举和投票，过多的话选举的收敛速度会很是慢，写数据时的投票过程也会好久。observer的增长能够提升可用性和扩展性，集群可接受client请求的点多了，可用性天然会提升，可是一致性的问题依然存在，这时又回到了上面CA的取舍问题上。

  做为分布式集群，系统是如何保证各台机器间的状态是一致的？下一篇讲下paxos协议和一致性。

推荐阅读：

zookeeper-操做与应用场景

评论不能及时回复可直接加公众号提问或交流，知无不答，谢谢 。