Zookeeper之基于Observer部署架构

最新推荐文章于 2025-02-08 07:43:56 发布

置顶

qianshanding0708

最新推荐文章于 2025-02-08 07:43:56 发布

阅读量1.2w

点赞数 5

分类专栏： Zookeeper 文章标签： Observer zookeeper

本文链接：https://blog.csdn.net/qianshangding0708/article/details/50160891

版权

本文介绍了Zookeeper中的Observer节点，它在不影响写性能的情况下提升系统的可扩展性。Observer不参与投票，只接收结果，增加了 Observer 不会影响集群写性能。此外，Observer的部署可以跨越数据中心，提高本地读请求响应速度，但无法完全消除跨数据中心延迟。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Observers：在不伤害写性能的情况下扩展Zookeeper

尽管通过Client直接连接到Zookeeper集群的性能已经非常好了，但是这种架构如果要承受超大规模的Client，就必须增加Zookeeper集群的Server数量，随着Server的增加，Zookeeper集群的写性能必定下降，我们知道Zookeeper的Znode变更是要过半数投票通过，随着机器的增加，由于网络消耗等原因必然导致投票成本增加，从而导致写性能的下降。

Observer是一种新型的Zookeeper节点，可以帮助解决上述问题，提供Zookeeper的可扩展性。Observer不参与投票，只是简单的接收投票结果，因此我们增加再多的Observer，也不会影响集群的写性能。除了这个差别，其他的和Follower基本上完全一样。例如：Client都可以连接到他们，并且都可以发送读写请求给他们，收到写请求都会上报到Leader。

Observer有另外一个优势，因为它不参与投票，所以他们不属于Zookeeper集群的关键部位，即使他们Failed，或者从集群中断开，也不会影响集群的可用性。根据Observer的特点，我们可以使用Observer做跨数据中心部署。如果把Leader和Follower分散到多个数据中心的话，因为数据中心之间的网络的延迟，势必会导致集群性能的大幅度下降。使用Observer的话，将Observer跨机房部署，而Leader和Follower部署在单独的数据中心，这样更新操作会在同一个数据中心来处理，并将数据发送的其他数据中心（包含Observer的），然后Client就可以在其他数据中心查询数据了。但是使用了Observer并非就能完全消除数据中心之间的延

最低0.47元/天解锁文章