ETCD、Zookeeper和Consul 分布式数据库的魔法银弹

etcd是一个非常可靠的kv存储系统，常在分布式系统中存储着关键的数据。它是由coreos团队开发并开源的分布式键值存储系统，具备以下特点：提供定义明确且面向用户的API、支持SSL证书验证、基准压测支持1w+/sec写入、采用Raft协议保证分布式系统数据的可用性和一致性。etcd的这些特性，使得它常常出现在分布式设计场景下的工具集中。etcd具有键值存储、查询功能（支持精准查询、range操作、ttl机制、key版本等），一致性机制（采用raft协议保证强一致性），可用性机制（提供集群和leader选举机制），SSL认证机制，watch机制。

许多现代分布式应用程序都建立在分布式一致键值存储之上。这里仅仅举各个方向应用的典型案例：

• Hadoop生态系统中的应用程序和“Netflix栈”的许多部分都使用Zookeeper。
• Consul公开了服务发现和运行状况检查API，并支持Nomad等集群工具。
• Kubernetes容器编排系统
• MySQL的Vitess水平扩展
• Google Key Transparency项目以及许多其他系统都是基于etcd构建的。

这篇博文是探索分布式、一致性键值数据存储软件（etcd、Zookeeper和Consul）在国内比较典型分布式数据库中的应用。

patroni

PostgreSQL数据库高可用patroni组件通过ETCD等Distributed configuration system (DCS)解决了如下问题：提升一个复制节点时无响应的情况下,存在脑裂的可能、单一的monitor节点对于集群的监控缺陷以及失败节点必须被清理的问题、多点监控中的分布一致性的问题。

https://blog.csdn.net/liuhuayang/article/details/108839892
https://blog.csdn.net/liuhuayang/article/details/120030752

TBASE

Tbase数据库在设计时就考虑了两地三中心的架构（如下图所示）。简单来说，通过让Datanode（数据DN） 节点实现，同城节点强同步，异地节点异步同步的3节点部署架构实现高可用。同时，让每台主机部署Agent，负责采集各个节点运行状态，上报给所有 Center，同时负责执行 Center 下发的各种操作指令。Center负责状态汇总，并将状态信息写入 Zookeeper集群；监听各个节点的运行状态，异常时发起仲裁流程，根据仲裁结果，发起容灾切换流程。当然，Center也支持接收外部用户操作指令，生成分布式指令计划，下发给 Agent 执行，并监控 Agent 的执行状态。

GaussDB

GaussDB300数据库在200的基础上新增了etcd集群，用于保存gtm的全局事务id号，同时数据节点由原来的主-备-从（从节点不含数据，当主节点宕机切换后，从节点才有数据）变为现在的一主多备模式，每个备节点都有数据，节点间使用quorum协议。 Gtm集群由原来的一主一备变为了一主多备。Gtm组件是集群的心脏，每个事务的开启都需要cn与gtm的交互，需要取gxid和快照信息，所以在高并发的情况下交互十分频繁，所以gtm的网络流量是非常大的，gtm可能来不及分配事务号，很容易成为瓶颈。 同时，gtm主备节点之间同步信息会造成高可用的问题，任何一个事务号都要到备节点进行sync操作，如果发生某个gtm节点宕机，会造成超时等待，整个集群会hang，造成高可用的问题。 针对上面两个问题，GaussDB300引入了第三方etcd集群，etcd集群是基于raft协议的高可用强一致集群，最少三个节点，比较轻量化，十分适合用来存储gxid，这样一来，gtm的工作就剥离一部分到etcd了，高可用就依赖于etcd集群的成熟高可用方案，大大缩短了gtm宕机对集群的影响。 Gtm就只负责从etcd集群读写事务号。

https://blog.csdn.net/enmotech/article/details/103154268

TiDB

Placement Driver (后续以 PD 简称) 是 TiDB 里面全局中心总控节点，它负责整个集群的调度，负责全局 ID 的生成，以及全局时间戳 TSO 的生成等。PD 还保存着整个集群 TiKV 的元信息，负责给 client 提供路由功能。作为中心总控节点，PD 通过集成 etcd ，自动的支持 auto failover，无需担心单点故障问题。同时，PD 也通过 etcd 的 raft，保证了数据的强一致性，不用担心数据丢失的问题。
在架构上面，PD 所有的数据都是通过 TiKV 主动上报获知的。同时，PD 对整个 TiKV 集群的调度等操作，也只会在 TiKV 发送 heartbeat 命令的结果里面返回相关的命令，让 TiKV 自行去处理，而不是主动去给 TiKV 发命令。这样设计上面就非常简单，我们完全可以认为 PD 是一个无状态的服务（当然，PD 仍然会将一些信息持久化到 etcd），所有的操作都是被动触发，即使 PD 挂掉，新选出的 PD leader 也能立刻对外服务，无需考虑任何之前的中间状态。
https://pingcap.com/zh/blog/placement-driver
https://pingcap.com/zh/blog/pd-scheduler
https://pingcap.com/zh/blog/best-practice-pd
https://pingcap.com/zh/blog/how-do-we-build-tidb
https://pingcap.com/zh/blog/the-design-and-implementation-of-multi-raft

可以发现一个趋势，ETCD、Zookeeper和Consul等作为靠谱的kv存储系统，变身成为分布式系统中存储着关键的数据的关键组件。
参考：https://blog.csdn.net/github_32521685/article/details/89953710