在学习了Zookeeper(后文都简称zk)的介绍和功能后,您已经很好地理解了zk。现在,在这个zk教程中,我们将讨论zk的优点和局限性。zk有几个功能对用户非常有益,但同时也存在一些局限性,所以在我们使用zk前,必须先了解一下。让我们分别学习一下zk的优点与局限性
下面列出了使用zk的各种优点
zk节点之间的协调过程非常简单
zk高度同步,这意味着服务器进程之间既存在互斥又存在合作,同步有助于Apache HBase进行配置管理。
zk跟踪一个数字,表示每个更新的顺序,保证消息有序
根据具体规则,zk对数据进行编码。另外,它还可确保我们的应用程序始终如一地运行。但是,在MapReduce中,我们使用此方法(序列化)来协调队列以执行正在运行的线程
在读请求多的情况下,能以很快的速度运行
此外,可以通过部署更多机器来加强zk的性能
众所周知,zk中的消息是有序的。所以,为了实现更高级别的抽象,需要有序性。这就是有序性对我们有利的方式
在读多的情况下,zk会非常快
zk非常可靠,因为一旦zk更新了,更新后的数据会一直保持,直到被覆盖更新
zk只有两种情况,要么全部成功,要么全部失败,没有中间状态的情况
zk保证在一定时间段内,客户端最终一定能从服务器上读到最新的数据状态
正所谓,"每个硬币都有两面",zk在有这么多优点的同时也存在一些缺点,下面就是zk不足的列表
在现有服务器中,当新zk服务器数量超过zk服务中已存在的数量时数据会丢失。同时,向zk服务发出Start命令,新服务器可能形成仲裁
在没有用户干预的情况下,zk服务器无法从版本3.4迁移到3.3,然后再迁移到3.4。
只允许3或5个这样奇数个zk节点(要求奇数是为了保证选举的正常进行因为leader选举要求 可用节点数量 > 总节点数/2,防止脑裂造成集群不可用。同时在容错能力相同的情况下,奇数个节点更节省资源)
目前,它不支持机架放置和感知
不支持减少pod的数量,以防止意外数据丢失
不支持在初始部署后更改volume要求,以防止重新分配意外丢失数据
当服务部署在虚拟网络上时,如果没有完全重新安装,服务可能无法切换到主机网络。另外,对于尝试从主机切换到虚拟网络,它们是相同的情况
在虚拟网络上,它目前不支持启用Kerberos
对跨群集方案的支持非常有限。但是,没有CP系统会一直支持跨集群。虽然我们可以说consul似乎在这方面做得更好
它非常重,所以它需要我们维持一个相当大的堆栈