【ZooKeeper高手实战】ZooKeeper 集群读写性能及生产环境参数配置-Toy模板网

这篇具有很好参考价值的文章主要介绍了【ZooKeeper高手实战】ZooKeeper 集群读写性能及生产环境参数配置。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

🌈🌈🌈🌈🌈🌈🌈🌈
欢迎关注公众号（通过文章导读关注：【11来了】），及时收到 AI 前沿项目工具及新技术 的推送
发送 资料 可领取 深入理解 Redis 系列文章结合电商场景讲解 Redis 使用场景、中间件系列笔记和编程高频电子书！
文章导读地址：点击查看文章导读！
🍁🍁🍁🍁🍁🍁🍁🍁
zk并发写性能怎么样,Zookeeper,zookeeper,分布式,云原生

ZooKeeper 集群读写性能及生产环境参数配置

zk 中的 Observer 节点在集群中到底发挥着什么作用？

zk 集群其实是适合 写少读多 场景的，因为整个集群只有 1 个 Leader 可以写，对于集群的读性能，可以通过 添加 Observer 节点来增强

Observer 节点Observer 是只读的、不参与 Leader 选举、也不参与 ZAB 协议同步时过半 Ack 的环节，只是单纯的接收数据，同步数据，达到数据顺序一致性的效果

Observer 的作用就是提供读服务，当读并发请求过高时，可以通过不断添加 Observer 节点来分散读请求的压力

那这里可能大家就会有问题了：既然想要增强读的性能，多添加点 Follower 节点不就可以了吗？

其实不行的，zk 是适合于 小集群部署 的，这是因为在集群中 Leader 完成写请求是需要经过半数以上的 Follower 都 Ack 之后，才可以成功写入的，如果集群中 Follower 过多，会大大增加 Leader 节点等待 Follower 节点发送 Ack 的时间，导致 zk 集群性能很差，因此 zk 集群部署一般都是 3 台或者 5 台机器

如下图，zk 集群部署为 1 主 2 从，通过添加 Observer 可以不断提升读性能：

zk并发写性能怎么样,Zookeeper,zookeeper,分布式,云原生

zk 集群的性能瓶颈在哪里呢？

瓶颈在于 Leader 的 写性能，如果 zk 集群挂掉的话，那么很有可能就是 Leader 的写入压力过大，这对一个公司的技术平台打击是巨大的，因为像 kafka 之类的技术都是强依赖 zk 的，dubbo + zk 去做服务框架的话，当服务实例达到上万甚至几十万时，大量服务的上线、注册、心跳的压力达到了每秒几万甚至十万，单个 Leader 抗几万的请求还行，十几万的话 zk 单个 Leader 是扛不住这么多的写请求的

想要提升 Leader 的 写性能，目前来说也就是提升部署 zk 的机器性能了，还有一种方式也就是将 dataLogDir 目录挂载的机器上配置 SSD 固态硬盘，以此来提升事务日志 写速度 来提升写性能（这个在后边将 zk 核心参数 dataLogDir 时会讲到）！

zk 集群推荐机器配置：

zk 作为 基础架构类别 的系统，对于部署的机器要求还是比较高的

推荐配置：3 台机器，8 核 16G 或者 16 核 32G，三台机器的小集群每秒抗十几万的并发读是没有问题的

zk 版本选择一般使用 3.4.5 版本

不同机器配置所能承载的并发量都是不同的：

在 3 台机器组成的 zk 集群中，1 个 Leader 抗几万 并发写 是可以的，每秒抗 5~10 万的 并发读 是没有问题的

zk 集群中，写性能无法提升，读性能提升可以通过添加 Observer 节点来实现

如何合理设置 ZooKeeper 的 JVM 参数以及内存大小？

JVM 参数设置的话，主要设置三个方面：堆内存、栈内存、Metaspace 区域的内存

机器如果有 16G 的内存：