协议 (集群) —— 服务器 ↔ 服务器 ​

对端 RPC 协议,仅在集群模式下使用。节点通过 Raft 共识共享同一份锁状态 —— 每一次锁状态变更(获取、释放、过期)都要经过 leader 提案 → 多数派复制 → 提交之后才会被应用,因此即使在网络分区或故障切换期间,互斥性依然成立。 概念性说明见工作原理。

流程 —— 从一次获取到其提交 ​

leader 会把锁命令转换为已复制命令, 装载进一次 AppendEntries RPC 中,一旦 包含自身在内的多数派记录了该命令就会提交(3 个节点时,leader 加上 跟随者 1 就足够了 —— 无需等待其余节点)。客户端响应只会在提交之后发出, 因此一旦你收到响应,那把锁就已经写入了多数派。

端口与地址规则 ​

• 对端 RPC 使用专属的 Raft 端口 = 客户端端口 + 1000(例如 5225 → 6225)。 它是自动推导出来的,无需单独的配置项,并且只在集群模式下监听。 防火墙需要同时开放这两个端口。
• 配置项(cluster_self/cluster_peers)始终保存的是客户端地址。 只有拨号连接对端时才会在端口上 +1000 —— 发给客户端的 M(已转移)重定向地址 始终是普通的客户端地址。
• 角色纯粹通过端口区分——协议内部没有专门的步骤来区分客户端和对端。 连接顺序与认证/TLS 规则见连接与认证。

目录 ​

• 服务器间
  • 连接与认证
  • 帧结构
  • RPC 类型
  • 已复制命令
  • 快照 (Snapshot)
• Raft 参数
• 配置 (环境变量)
• 滚动重启流程

另请参阅 ​

• 关于 leader 选举、多数派提交、故障场景的通俗解释 —— 工作原理
• 客户端如何找到 leader —— M · 已转移、 响应匹配规则
• 实际部署方式(Docker、Kubernetes 等)—— Ticketing 服务器部署