ZooKeeper在大数据系统中的意义

举报
JavaEdge 发表于 2022/04/21 22:21:35 2022/04/21
【摘要】 服务器集群环境的各种故障随时可能发生,多台服务器对一个数据的记录保持一致是一项重大挑战。 HDFS为保证集群的高可用,需部署两台NameNode服务器:一台作为主服务器一台作为从服务器当主服务器不可用,就切换到从服务器访问。若不同应用程序(Client)或DataNode做出的关于主服务器是否可用的判断不同,就会导致HDFS集群混乱。比如两个应用程序都要对一个文件路径执行写操作,但若这俩应用...

服务器集群环境的各种故障随时可能发生,多台服务器对一个数据的记录保持一致是一项重大挑战。

HDFS

为保证集群的高可用,需部署两台NameNode服务器:

  • 一台作为主服务器
  • 一台作为从服务器

当主服务器不可用,就切换到从服务器访问。若不同应用程序(Client)或DataNode做出的关于主服务器是否可用的判断不同,就会导致HDFS集群混乱。

比如两个应用程序都要对一个文件路径执行写操作,但若这俩应用程序对哪台服务器是主服务器的判断不同,就会分别连到不同NameNode,并都得到对同一文件路径的写权限,这就会引起文件数据冲突,同一个文件指向了两份不同数据!

这种不同主服务器做出不同的响应,在分布式系统中被称作脑裂,这时集群处于混乱,无法使用。那引入一个专门进行判断的服务器当“裁判”,决定哪个服务器是主服务器不就完事了?

但这个做出决策的服务器也可能会出现故障不可访问呀,同样整个服务器集群还是不能正常运行。所以这个做出判断决策的服务器必须由多台服务器组成,保证高可用!

递归的问题来了,这几台做出决策的服务器又如何防止“脑裂”?的确很无奈,分布式系统设计就像递归无底洞。但问题必须要解决,比较常用的多台服务器状态一致性的解决方案就是ZooKeeper。

Paxos算法与ZooKeeper架构

比如一个提供锁服务的分布式系统,它是由多台服务器构成一个集群对外提供锁服务,应用程序连接到任一台服务器都能获取或释放锁,因此这些服务器必须严格保持状态一致,不能一台服务器将锁资源交给一个应用程序,而另一台服务器将锁资源交给另一个应用程序。

Paxos算法就是为解决该问题,多台服务器通过内部投票表决机制决定一个数据的更新与写入。

Paxos设计思想

img

应用程序连接到任一服务器后,发起状态修改请求(也可能是获得某个状态锁的请求),即服务器1,会将该请求发送给集群中其他服务器来表决。

若某服务器同时收到另一个应用程序同样的修改请求,它可能会拒绝服务器1的表决,并自己也发起一个同样的表决请求,则其他服务器就会根据时间戳和服务器排序规则进行表决。

表决结果会发送给其他所有服务器,最终发起表决的服务器(服务器1),会根据收到的表决结果决定该修改请求是否能执行,从而在收到请求时,就保证了数据的一致性。

Paxos很复杂,ZooKeeper简化实现,使用ZAB(ZooKeeper Atomic Broadcast,ZooKeeper原子消息广播协议)算法协议。基于ZAB,zk集群保证数据更新的一致性,并通过集群方式保证zk系统高可用。但zk系统中所有服务器都存储相同数据,即数据没有分片,因此不满足分区耐受性。

zk通过一种树状结构记录数据:

应用程序可通过路径的方式访问zk来修改、读取数据。zk还支持监听模式,当数据发生改变的时候,通知应用程序。

大数据系统通常主从架构,主服务器管理集群的状态和元信息(meta-info),为防止“脑裂”,所以运行期只能有一个主服务器工作(active master),但为保证高可用,必须有另一个主服务器保持热备(standby master)。应用程序和集群其他服务器如何知道实际工作的是哪个主服务器?

所以很多大数据系统依赖zk提供的一致性数据服务,来选举集群当前工作的主服务器。一台主服务器启动后向zk注册自己为当前工作的主服务器,因此另一台服务器就只能注册为热备主服务器,应用程序运行期都和当前工作的主服务器通信。

若当前工作的主服务器宕机(在zk上记录的心跳数据不再更新),热备主服务器通过zk的监控机制发现当前工作的主服务器宕机,就向zk注册自己成为当前工作的主服务器。应用程序和集群其他服务器跟新的主服务器通信,保证系统正常运行。

因为zk系统的多台服务器存储相同数据,并且每次数据更新都要所有服务器投票表决,所以和一般的分布式系统相反,ZooKeeper集群的性能会随着服务器数量增加而下降。

Zk通过Paxos实现数据强一致性,并为各种大数据系统提供主服务器选举服务。虽然zk并没有什么特异功能,但是在各类分布式系统和大数据系统中,zk是很多系统的基础设施。

总结

Paxos只考虑所有服务器都是可信任的情况。但在分布式系统中还有一类场景,需要考虑当集群中的服务器存在恶意服务器。当这些恶意服务器企图篡改伪造数据或传递虚假信息,如何保证系统继续有效运行?比如区块链就得考虑。

区块链采取的解决方案是工作量证明。一台服务器要想在分布式集群中记录数据(即所谓分布式记账),必须进行一个规模庞大的计算,比如计算一个256 Bit的hash值,这个值的前若干位必须为0。比特币区块链就是采用类似这样的工作量证明算法,为了进行这样的hash计算,目前比特币区块链消耗的电量相当于一个中等规模国家的用电量。

通过这种工作量证明方式,保证了恶意服务器要想伪造篡改数据,必须拥有强大计算能力(占整个集群服务器计算能力的51%以上),而只要我们认为大多数服务器是善意的,这样的区块链分布式集群就是可靠的。

参考

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。