zetcd：让应用解除对ZooKeeper的依赖(2)

发布时间：2021-01-16 03:44 所属栏目：53 来源：网络整理

导读：跟etcd性能工具的接口及报告形式类似,zetcd命令行工具zkboom可以用来判断一个zetcd的性能基准是否满足要求.其它ZooKeeper性能工具应该也可以用在zetcd；zkboom为用户提供了便利,我们不妨试试用它来做下创建key的测

跟etcd性能工具的接口及报告形式类似,zetcd命令行工具zkboom可以用来判断一个zetcd的性能基准是否满足要求.其它ZooKeeper性能工具应该也可以用在zetcd；zkboom为用户提供了便利,我们不妨试试用它来做下创建key的测试：

go?get?github.com/coreos/zetcd/cmd/zkboom?
zkboom?--conns=50?--total=10000?--endpoints=localhost:2181?create

zetcd应当可以为小负载提供充分的性能保障.一个简单两节点配置的延迟基准表明zetcd是可以承受大量请求的.具体配置为两台Linux服务器通过一个千兆交换机互联,其中一台设备在RAID磁盘配置上运行代理和和服务端,另外一台设备用于产生客户请求.zkbook通过创建一个空的key存储,然后从中读取128Kbytes的键值对来进行测量.用户请求被限制在每秒2500个请求,然后逐渐增加并发客户端数量.ZooKeeper 3.4.10和etcd结果对比见下图.

下图揭示了zetcd客户端并发数与创建key的平均延迟之间的关系.由于etcd在延迟上比ZooKeeper要有5-35ms的优势,zetcd有足够余地处理由于额外负载和网络跳转造成的延迟.比起ZooKeeper,zetcd代理始终还是存在20ms左右的差距,但是从处理2500请求的吞吐量数据来看,并没有出现队列堵塞.一种对zetcd写比较慢的解释是,与读不一样,由于数据模型上存在差异,所以在每个ZooKeeper key写时需要写多个key.

下图揭示了zetcd客户端并发数与key取值的平均延迟之间的关系.由于ZooKeeper的取值延迟比etcd要快那么2ms左右,想要zetcd提供数据的速度快过ZooKeeper的话恐怕还得依赖于etcd本身性能的进一步提升.然而,尽管zetcd需要从etcd请求额外的key来模拟Zookeeper znode的元数据,zetcd的命中延迟在等待etcd key提取数据方面只增加了大概1.5ms.zetcd在key的数据提取操作方面仅需一次往返,因为读请求会被打包到一个etcd事务中.

未来

zetcd承诺上述性能基准测试的结果是合理的,在可接受的延迟情况下,可以轻松支撑每秒上千个操作.以上模拟对于Mesos,Kafka和Drill替代ZooKeeper提供了一个替代选择.但是对于zetcd本身来说性能方面仍有不少的提升空间.与此同时测试更多的ZooKeeper应用也会进一步推动zetcd成为ZooKeeper服务器的替代品.

zetcd从去年十月开始在开源社区发行,最近刚发布第一个版本：zetcd v0.0.1.尽管是第一个beta发行版,但是已经为未来生产系统提供稳定管理和部署.如果跟etcd配合起来使用,运行zetcd的系统将会一套自驱动的“ZooKeeper”集群,它可以自动后台升级,备份和TLS管理.如想了解更多,请参阅?https://github.com/coreos/zetcd/.

深入浅出学习etcd

etcd为分布式系统提供可靠、高效的配置管理服务,在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色.作为2013年开始的项目,它还很年轻,官方文档中缺乏实现上全面、系统的介绍,本课程深入浅出地介绍了etcd的实现,并为运维和二次开发提供了系统的指导和建议.

文章来自微信公众号：Docker

（编辑：ASP站长网）