1. etcd简介
etcd是一个非常可靠的kv存储系统，常在分布式系统中存储着关键的数据。它是由coreos团队开发并开源的分布式键值存储系统，具备以下特点：
- 简单：提供定义明确且面向用户的API
- 安全：支持SSL证书验证
- 性能：基准压测支持1w+/sec写入
- 可靠：采用Raft协议保证分布式系统数据的可用性和一致性。
etcd的这些特性，使得它常常出现在分布式设计场景下的工具集中。
1.1 etcd常见功能
- 键值存储、查询功能：支持精准查询、range操作、ttl机制、key版本等。
- 一致性机制：采用raft协议保证强一致性。
- 可用性机制：提供集群和leader选举机制。
- SSL认证机制。
- watch机制。
1.2 etcd常见应用场景
1. 配置中心
etcd是一个分布式的键值存储系统，其优秀的读写性能、一致性和可用性的机制，非常适合用来做配置中心角色。
2. 分布式锁
etcd的强一致性保证，可以用来做分布式场景下的同步机制保证。
3. leader选举组件
分布式场景下，常采用leader-follower模式来保证有状态服务的高可用（即使leader挂掉，其他follower立马补上），比如k8s和kafka partition高可用机制。可以很方便的借助etcd来实现leader选举机制，这里有个leader election实现：https://github.com/willstudy/leaderelection
4. 服务注册与服务发现
为了解决微服务场景下，服务地址的注册和发现问题，和配置中心类似，不同之处在于服务注册和服务发现，还伴随着状态检测。
5. 消息订阅和发布
etcd内置watch机制，完全可以实现一个小型的消息订阅和发布组件。
6. more and more
etcd优秀的特性，适合的场景很多。
2. etcd和同类型产品的对比
2.1 etcd vs redis
etcd诞生之日起，就定位成一种分布式存储系统，并在k8s 服务注册和服务发现中，为大家所认识。它偏重的是节点之间的通信和一致性的机制保证，并不强调单节点的读写性能。
而redis最早作为缓存系统出现在大众视野，也注定了redis需要更加侧重于读写性能和支持更多的存储模式，它不需要care一致性，也不需要侧重事务，因此可以达到很高的读写性能。
总结一下，redis常用来做缓存系统，etcd常用来做分布式系统中一些关键数据的存储服务，比如服务注册和服务发现。
2.2 etcd vs consul
consul定位是一个端到端的服务框架，提供了内置的监控检查、DNS服务等，除此之外，还提供了HTTP API和Web UI，如果要实现简单的服务发现，基本上可以开箱即用。
但是缺点同样也存在，封装有利有弊，就导致灵活性弱了不少。除此之外，consul还比较年轻，暂未在大型项目中实践，可靠性还未可知。
2.3 etcd vs zookeeper
etcd站在了巨人的肩膀上。。zookeeper有如下局限性：
- 不能动态的变更节点，需要人工修改配置 & 重启进程。
- 大规模链接时，读写性能表现差。
3. etcd性能表现
来自于官网介绍：https://etcd.io/docs/v3.4.0/op-guide/performance/ 大致总结一下：
- 读：1w ~ 10w 之间
- 写：1w左右
建议：
- etcd需要部署到ssd盘（强烈建议）
- 多个写采用batch操作。
- 非必要情况下，避免range操作。
etcd集群更偏重一致性和稳定性，并不强调高性能，在绝大部分场景下均不会到达etcd性能瓶颈，如果出现瓶颈的话，需要重新review架构设计，比如拆分或者优化流程。
4. 总结
etcd是一个分布式的可靠的键值存储系统，是分布式架构设计的常见组件。
每个轮子都有好有坏，正是坏的那一点的存在，才能将好的那一点发挥到极致。在架构设计中，需要根据业务场景选择适合的轮子，避免坏的那一面，并将好的那一面发挥到极致。