16 | 性能及稳定性（上）：如何优化及扩展etcd性能？

唐聪



该思维导图由 AI 生成，仅供参考

你好，我是唐聪。
在使用 etcd 的过程中，你是否吐槽过 etcd 性能差呢？ 我们知道，etcd 社区线性读压测结果可以达到 14w/s，那为什么在实际业务场景中有时却只有几千，甚至几百、几十，还会偶发超时、频繁抖动呢？
我相信不少人都遇到过类似的问题。要解决这些问题，不仅需要了解症结所在，还需要掌握优化和扩展 etcd 性能的方法，对症下药。因为这部分内容比较多，所以我分成了两讲内容，分别从读性能、写性能和稳定性入手，为你详细讲解如何优化及扩展 etcd 性能及稳定性。
希望通过这两节课的学习，能让你在使用 etcd 的时候，设计出良好的业务存储结构，遵循最佳实践，让 etcd 稳定、高效地运行，获得符合预期的性能。同时，当你面对 etcd 性能瓶颈的时候，也能自己分析瓶颈原因、选择合适的优化方案解决它，而不是盲目甩锅 etcd，甚至更换技术方案去 etcd 化。
今天这节课，我将重点为你介绍如何提升读的性能。
我们说读性能差，其实本质是读请求链路中某些环节出现了瓶颈。所以，接下来我将通过一张读性能分析链路图，为你从上至下分析影响 etcd 性能、稳定性的若干因素，并给出相应的压测数据，最终为你总结出一系列的 etcd 性能优化和扩展方法。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

etcd性能优化与扩展是一篇深入探讨etcd高性能分布式键值存储系统的文章。文章从优化和扩展etcd性能的角度出发，分析了读性能的瓶颈和优化方法。首先介绍了负载均衡的重要性，特别是在etcd 3.4版本之前存在的连接数固定的缺陷，以及在3.4版本后引入的Round-robin负载均衡算法。其次，针对密码鉴权的性能问题，详细分析了Authenticate RPC调用的性能瓶颈，以及通过升级版本、使用证书鉴权、复用token等方法来解决密码鉴权的性能问题。文章还介绍了线性读实现机制、网络延时、磁盘IO性能、写QPS等对etcd性能的影响因素，以及针对这些因素的优化建议。此外，还探讨了RBAC规则数、Auth锁、expensive request、treeIndex锁等对性能的影响，并提出了相应的优化方案。通过具体的压测数据和实际案例，深入浅出地介绍了etcd性能优化和扩展方法，为读者提供了解决实际问题的指导和建议。文章内容涵盖了etcd性能优化的多个方面，包括负载均衡、密码鉴权、线性读实现、网络延时、磁盘IO性能、写QPS等因素对性能的影响，以及针对这些问题的解决方案和最佳实践。通过分析具体的性能瓶颈和优化方法，为读者提供了全面的etcd性能优化指南。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《etcd 实战课》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(7)

最新
精选

云原生工程师
分析透彻，还有压测数据，有两个收获，鉴权接口之慢，线性读性能随写请求下降之快，请问一下，增加节点能提升线性读性能吗，求压测数据，谢谢老师
作者回复: 感谢认可，非常好的问题，从原理上简单分析来看，若3个节点增大到5个节点，写请求至少要同步到3个节点，性能会略微下降，读请求的性能，主要是线性读涉及到与Leader交互，若写请求QPS非常小，Leader还未出现瓶颈的情况下，我认为是可以适当提升线性读性能的。我简单压测了以下，也验证结果符合预期。下面是3个节点的压测数据(写QPS为10）： Summary: Total: 2.7759 secs. Slowest: 0.2266 secs. Fastest: 0.0010 secs. Average: 0.0092 secs. Stddev: 0.0042 secs. Requests/sec: 108072.0685 下面是5个节点的测试结果，写QPS同样5. Summary: Total: 0.7235 secs. Slowest: 0.0530 secs. Fastest: 0.0009 secs. Average: 0.0070 secs. Stddev: 0.0048 secs. Requests/sec: 138215.9303 写QPS为5的情况下，非SSD磁盘集群，3个节点线性读性能为108072.0685/s, 5个节点线性读性能为138215.9303/s。
2021-02-24
4
8
写点啥呢
请问唐老师，能否详细介绍证书验证机制与密码验证机制的不同之处，为什么它相比密码验证能够提升性能并避免token复用问题？（我理解证书验证基于RSA非对阵加密算法，成本也高）。谢谢老师
作者回复: 证书认证它不需要调用Authenticate接口，这个接口专门是用来校验用户名密码用的。token机制也是为了优化密码认证性能，避免频繁调用Authenticate接口而设计出来的，因此它也跟证书认证没有关系。一般使用证书认证，都是长连接，在HTTPS连接建立时会有一定的开销，但是后续请求都不需要发起任何昂贵的认证操作，客户端证书的CN名字就是请求的用户名。建议你详细看看05鉴权篇。
2021-02-24

7
jeffery
图文并茂形象生动！每章都很👍！引入 cache 实现缓存 expensive read request 的结果后.怎么维护缓存数据与 etcd 保持强一致性.cache是指内核cache还是别的！突然宕机会不会丢数据.谢谢老师
作者回复: cache是指应用层的，比如kubernetes中的informer机制，你可以参考下client-go的实现，https://github.com/kubernetes/client-go/tree/master/tools/cache，宕机、重启后需要重新发起读请求向etcd查询最新的数据来填充cache, 随后通过watch机制监听后续数据变化，有新的key-value变化就更新cache
2021-02-25
2
6
孔宣
唐老师，kstone现在还在维护吗？加了微信没人回复。想在生产上使用，想咨询几个问题
2023-04-06归属地：北京


牛学真
收获很大
2022-03-25


Zhenng
老师，我在测etcd集群读性能的时候线性读的性能可以达到14w/s,但是串行读的性能跟线性读的性能相同，也是14w/s，这是为什么？我的etcd版本是3.5.2
2022-03-14


Simon😜
老师，多租场景下（不同业务做数据隔离，假设100个业务)，使用证书认证，假设10万个客户端连接，线性读的qps能达到多少呢？
2021-04-24



收起评论