浅析ETCD

作为协调中心与Zookeeper对比

尽管etcd 和 Zookeeper都是服务的协调中心，随着需求的演进，两者都有了自己一定的生态（感觉这一带你也蛮重要的，k8s本身就是用go写的，如果掺进去一个java总感觉怪怪的）。

在详细对比与ZK的特性差异之前，请允许我先介绍一下ETCD与Zookeeper的架构差异。

ZooKeeper 的结构是一个树状的文件系统结构，每一个节点Node就是一个小文件，然后客户端通过对节点的增删改查来进行服务的协调。

zk使用ZAB算法进行集群状态的同步。

ETCD 有序的KV对来实现类似的树状结构、对于 etcd 来说，key=/test/key1 只是一个字符串而已，但是对我们而言却可以模拟出目录层级关系。

etcd使用Raft算法进行集群状态的同步。

https://etcd.io/docs/v3.6/learning/why/

这是etcd 开源社区总结的一个详细对比项，他们从并发原语、健康检查及服务发现、数据模型、Watch 特性等功能上详细比较下它们功能和区别。

作为非关系型KV数据库与Redis对比

尽管etcd 和 redis 都是键值存储，随着技术的演进，二者在功能上也有逐渐相似的趋势，但二者在许多方面都有很大区别。

etcd 的红火来源于 k8s 用 etcd 做服务发现，而 redis 的兴起则来源于 memcache 缓存本身的局限性。

数据复制上Redis是主备异步复制、etcd使用的是Raft，前者可能会丢数据，为了保证读写一致性，etcd读写性能相比Redis差距比较大。

数据分片上Redis有各种集群版解决方案，可以承载上T数据，存储的一般是用户数据，而etcd定位是个低容量的关键元数据存储，db大小一般不超过8g。

存储引擎和API上Redis内存实现了各种丰富数据结构，而etcd仅是kv API, 使用的是持久化存储boltdb。

（毕竟redis设计出来就是干缓存的。

思考

任何分布式系统之间比较、选型，我们都可以从分布式系统的核心要素，API、数据复制及共识算法、数据分片算法、数据模型及存储引擎、事务实现、CAP等维度来进行比较。这是个通用的方法论，希望以后能帮助你解决更多问题。