游戏后端分布式学习——etcd

基础概念是什么强一致的分布式 KV 存储基于 Raft 共识算法定位分布式系统的协调大脑——存元数据、配置、协调状态不存业务热数据对比Redis 是 AP 系统高性能弱一致etcd 是 CP 系统强一致性能次之数据模型强一致的分布式 KV 存储基于 Raft 共识算法定位分布式系统的协调大脑——存元数据、配置、协调状态不存业务热数据对比Redis 是 AP 系统高性能弱一致etcd 是 CP 系统强一致性能次之集群与 Quorum需要补充这里设计的原因奇数节点3/5/7生产最常用 5 节点Quorum n/2 13 节点容忍 1 节点故障5 节点容忍 2 节点故障为什么不能偶数4 节点和 3 节点都只能容忍 1 节点故障但 4 节点需要 3 票75%故障代价更高存储引擎WALWrite-Ahead Log预写日志任何修改先追加到 WAL 并 fsync 到磁盘再应用到状态机作用节点崩溃后能从 WAL 恢复性能关键WAL fsync 延迟直接影响 etcd 写吞吐99分位应 10msSnapshot快照定期将状态机的当前状态序列化到磁盘作用压缩 WAL 大小防止日志无限增长触发–snapshot-count 控制默认 10000 条日志触发一次Copy-on-Write快照过程中不阻塞正常读写v3的底层存储引擎BoltDB存储KV 数据 索引 MVCC 版本读路径内存中的 BTree 索引 → 定位到数据文件偏移 → 读取写路径WAL 先写 → BoltDB 事务提交、MVCC 多版本每次写操作生成新的 revision全局递增revision 由 main 和 sub 组成{main: 全局版本, sub: 同一事务内的序号}Watch 机制的基础通过 revision 可以精确订阅从某个版本开始的所有变更核心原语待详细学习Lease租约带 TTL 的租约对象TTL 到点自动过期一个 Lease 可绑定多个 keyLease 过期则所有绑定的 key 全部删除KeepAlive客户端定期续租防止 Lease 过期游戏场景服务注册TTL5s KeepAlive 心跳 1s、选主Txn事务IF-Then-Else​ 结构IF compare THEN success ops ELSE failure ops比较操作version / ! / / / modCompare-and-Swap (CAS)​ 的基础IF version 0 THEN PUTkey 不存在才能 put所有 etcd 操作都是原子 TxnWatch监听监听 key 或 key 前缀的变化基于 MVCC可以指定 start_revision从历史事件开始回放事件类型PUT创建/更新、DELETE删除Watch 流长连接服务端持续推送事件游戏场景配置推送、状态变更通知、选主 key 删除事件Compact压缩定期压缩旧版本的 MVCC 数据防止历史版本无限增长压缩后Watch 只能从压缩点之后的 revision 开始生产配置–auto-compaction-moderevision --auto-compaction-retention1000关键操作选主流程etcd 实现1. 创建 LeaseTTL10s 2. Txn: IF key 不存在 THEN PUT(key, node_id, lease) 3. 成功 → 成为 Leader启动 KeepAlive 续租 4. 失败 → 成为 FollowerWatch key 的 DELETE 事件 5. Leader 续租失败 → Lease 过期 → key 自动删除 → Follower 通过 Watch 感知 → 重新选主分布式锁流程etcd 实现1. 创建 LeaseTTL5s 2. Txn: IF lock_key 不存在 THEN PUT(lock_key, token, lease) 3. 成功 → 获取锁启动 KeepAlive 4. 失败 → Watch lock_key 的前一个 key公平锁或自旋重试 5. 释放锁 → 删除 lock_key 或撤销 Lease读写路径写路径客户端 PUT → Leader 接收 → 创建 Raft 日志条目 → Raft 广播 AppendEntries → 多数派确认 → 提交 → 应用到 BoltDB 状态机 → 返回客户端读路径线性一致客户端 GET → Leader 接收 → ReadIndex确认自己仍是 Leader心跳确认多数派 → 从 BoltDB 读取 → 返回客户端概念自检清单为什么 etcd 集群节点数必须是奇数3 节点和 4 节点有什么区别WAL 和 Snapshot 各自解决什么问题它们的关系是什么Lease 过期后绑定的 key 会怎样客户端如何防止 Lease 过期Txn 的 IF-Then-Else 结构中compare 可以比较哪些条件Watch 机制为什么能精确订阅历史事件MVCC revision 在其中起什么作用etcd 的线性一致性读是如何保证的ReadIndex 和 Lease Read 有什么区别选主时如果 Leader 崩溃Lease 过期后 Follower 如何感知并重新选主分布式锁的公平锁是如何通过 Watch 实现的网络分区时etcd 集群会怎样数据会不一致吗为什么游戏后端中哪些数据应该存 etcd哪些应该存 Redis判断标准是什么