10bet游戏平台
  咨询电话:13984066134

十博10BET官方网站

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点需要分析的

    节点多了会导致写数据延时非常大(需要半数以上follower写完提交),因为需要多个节点同步.节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入 observer节点缓解这个问题.

zk在CAP问题上做的取舍

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

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

  为了协调AP(一致性和扩展性),用户可以自己选择是否添加obsever以及添加个数,observer是3.3.0 以后版本新增角色,它不会参加选举和投票过程,目的就是提高集群扩展性。因为follower的数量不能过多,follower需要参加选举和投票,过多的话选举的收敛速度会非常慢,写数据时的投票过程也会很久。observer的增加可以提高可用性和扩展性,集群可接受client请求的点多了,可用性自然会提高,但是一致性的问题依然存在,这时又回到了上面CA的取舍问题上。

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

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

, 1, 0, 9);