作者介绍:简历上没有一个精通的运维工程师,下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

数据库是一个系统(应用)最重要的资产之一,所以我们的数据库将从以下几个数据库来进行介绍。
MySQL
PostgreSQL
Redis
Etcd(本章节)
我们在讲解Kubernetes(k8s)的时候虽然有提到过,但是并没有详细介绍,我们把他单独列出来讲解的一个原因也是他在Kubernetes里面使用,一般业务到目前为止,我也只见过一个应用使用这个数据库。
Etcd(读作“et-cee-dee”,来源于“/etc”目录和“d”istributed system的组合)是一个分布式、可靠的键值存储系统,专门用于存储分布式系统中的关键数据。它由CoreOS团队于2013年创建,使用Go语言编写,采用Raft一致性算法来保证数据的强一致性。
强一致性:所有数据访问都通过Raft协议提供严格的可序列化一致性,确保所有节点看到相同的数据顺序。
高可用性:采用多副本机制,允许部分节点故障而不影响服务。通常部署奇数个节点(3、5或7),以容忍(n-1)/2个节点故障。
持久化:数据不仅存储在内存中,还持久化到磁盘,确保重启后数据不丢失。
Watch机制:客户端可以监听键的变化,实时获取更新通知,这是许多协调场景的基础。
租约(Lease)机制:支持键与租约绑定,租约过期后相关键自动删除,非常适合实现服务健康检查和分布式锁。
典型的Etcd集群由3到7个节点组成,每个节点包含以下核心组件:
+-------------------------------------------------------------+
| Etcd节点 |
| +---------------------+ +--------------------------+ |
| | Raft共识模块 |<---->| 存储引擎 | |
| | • Leader选举 | | • 键值存储(B-tree) | |
| | • 日志复制 | | • 持久化(WAL+快照) | |
| | • 安全性保证 | +--------------------------+ |
| +---------------------+ | |
| | | |
| +---------------------+ +--------------------------+ |
| | 客户端API层 |<---->| MVCC多版本控制 | |
| | • gRPC网关 | | • 版本管理 | |
| | • HTTP/JSON代理 | | • 并发控制 | |
| +---------------------+ +--------------------------+ |
+-------------------------------------------------------------+Etcd对Raft算法的实现进行了多项优化:
日志压缩:定期创建快照,减少日志大小和恢复时间。
领导者租约:领导者定期发送心跳,维持领导地位,减少不必要的选举。
批处理与管道化:将多个请求打包处理,提高吞吐量。
Etcd v3版本使用BoltDB作为后端存储(在v3.5+中改为Bbolt),提供:
每个键的修改都会创建新版本,旧版本保留直到压缩。这提供了: