2021年10月6日
刘科，别再平合著
介绍
etcd是一种高度一致的分布式键值存储，它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。最值得注意的是，它为流行的容器编排平台kubernetes管理配置数据、状态数据和元数据。
etcd 集群旨在提供具有一流稳定性、可靠性、可扩展性和性能的键值存储。吞吐量和延迟是衡量性能的一些最常用方法。延迟是完成操作所需的时间。吞吐量是在给定时间段内完成的总操作。
在本博客中，我们比较了两个 Amazon EC2 实例系列上不同实例大小的 etcd 的吞吐量和延迟。这些实例系列是 Amazon EC2 M6g（基于 Arm Neoverse 驱动的 AWS Graviton2 处理器）和 Amazon EC2 M5（基于 Xeon Platinum 8000）。我们的结果表明，与 M5 实例相比，M6g 实例上的 etcd 部署实现了高达 18% 的性能优势。以下部分涵盖了我们的测试方法和结果的详细信息。
Benchmark设置和结果
对于基准设置，我们使用了集成在 etcd 项目中的默认基准CLI 工具，这是 etcd 集群的官方基准测试工具。
etcd 的性能测试通常有两种类型的“放置”工作负载：
- Write to leader
- Write to all members
etcd 使用 Raft 共识算法在成员之间复制请求并达成一致。Raft 是基于leader的；leader处理所有需要集群共识的客户端请求。但是，客户端不需要知道哪个节点是leader。任何需要共识发送给跟随者的请求都会自动转发给leader。不需要共识的请求（例如，序列化读取）可以由任何集群成员处理。
基本的放置逻辑使用以下内容。当客户端发起写请求时，如果leader收到写请求，就会将请求写入本地的WAL（Write-Ahead Log），并将请求广播给各个节点。如果超过一半的节点已经成功写入本地 WAL 并响应leader，则请求对应的日志条目被标记为已提交。然后leader会向client发送响应；如果follower收到写请求，它会将请求转发给leader，其余逻辑与上述情况类似。
该设置有四个 EC2 集群，具有以下配置，并为这些实例使用“集群”置放群组以减少网络延迟。基准测试客户端使用单个 m6g.4xlarge 实例。
基准测试使用以下软件版本和测试参数进行:
图3展示了benchmark程序的内部逻辑。每次测试运行会创建1000个客户端goroutines（对应配置的客户端参数），通过配置的100个keep-alive HTTP2连接（10个goroutine共享一个连接）发送请求。每次运行时，基准测试发送的请求总计达 10 万个。下表中显示的结果是作为预热阶段的 20 次测试运行迭代后 20 次连续测试运行迭代的汇总结果，报告平均吞吐量和平均延迟。通过在基于 Graviton2 的实例上运行开源 etcd 与在基于 Xeon 的实例上运行相比，我们观察到 18% 的性能提升。
“Write to leader” 案例:
“Write to all members” 案例:
下图显示了运行 etcd 的 M5 和 M6g 实例之间的吞吐量和延迟比较（Write to leader case）：
下图显示了运行 etcd 的 M5 和 M6g 实例之间的吞吐量和延迟比较（Write to all members案例）:
结论
总而言之，部署在 AWS Graviton2 上的 etcd 与等效的基于第 5 代 x86 的 EC2 实例相比具有以下优势。吞吐量增加 18%，延迟减少 18%，同时价格降低 20%。
在这些实例上部署应用程序既简单又高效，而且不会因主要复杂性而产生额外开销。有关如何将现有应用程序迁移到 AWS Graviton2 的详细信息，请查看此 github 页面。
