提供高性能的读写服务是分布式研发工程师一直追求的目标，譬如在 TiDB 中，我们就基于原生的一致性算法 Raft 做了非常多的改进和性能优化。当然，在分布式领域，复制协议不光只有 Raft 这么一种，譬如这段时间，我就看到了另一个不错的实现，叫做 Hermes，来自于 Paper Hermes: a Fast, Fault-Tolerant and Linearizable Replication Protocol。

通常我们说分布式系统的高性能，无非就是关注两点：低延迟和高吞吐，对于读写请求来说，无非就是：

• 读
  • 能从所有副本读取数据
• 写
  • 更少的网络交互
  • 去中心化，不需要有单独的地方进行 serialization 处理
  • 完全并发，任何 replica 都能进行写入

对于 TiDB 来说，虽然我们在 Raft 这边支持了 Follower Read，也就是能从任意副本读取数据，但在写入上面，还是只有 Leader 能提供写服务。但是 Hermes 却能做到任何副本写入，所以让我对这篇 Paper 非常有兴趣，读下来之后，其实会发现，原来 Hermes 的原理非常的简单。

在介绍原理之前，先阶段的说下，Hermes 使用的是非常通用的 logical timestamp 机制，后面用 LT 来表示，一个 LT 是一个 [V, Cid] 的 tuple，V 就是通常的 Lamport clock，而 Cid 则是 replica 的 Node ID。如果对于一个 Key 的并发写入 V 是相同的，则按照 Cid 进行排序。

Hermes 的 replica 有 Coordinator 和 Follower 两种，Coordinator 接受 client 的写入请求，参考论文的图，一次写入如下：

• Coordinator 接受 client 的 write 请求，将 Key 分配一个新的 LT，给其他 followers 也广播一个 Invalidation(INV) 消息。并且将 Key 变成 Write 状态。
• 其他 followers 收到 INV 之后，会比较 LT，如果收到消息的 LT 比本地的大，就会将 Key 变成 Invalid 状态（如果这个 Key 之前是 Write 或者 Replay，则会变成 Trans 状态），并且回复 ACK 消息。无论之前比较的结果怎样，ACK 里面的 LT 都是收到的 INV 的 LT。
• 如果所有的 ACK 都收到了，write 就认为完成，这个 Key 就变成 Valid 状态（如果之前处于 Trans 状态，则会变成 Invalid 状态）
• Coordinator 再次广播 Validation(VAL) 消息
• 当 Follower 收到 VAL 消息，只有 VAL 的 LT 等于之前本地的 local timestamp，才会将 Key 转成 Valid 状态，否则一律丢弃这个 VAL 消息

可以看到，流程非常的简单，那么 Hermes 是如何支持 fault tolerance， Linearizability 这些特性的呢？

Hermes 保证，如果读取的 Key 处于 Invalid 状态，那么 read 则会一直等待，直到 Key 处于 Valid 状态。所以这里可以看到，Hermes 采用 read wait 的方式满足了 Linearizability。

而对于 fault tolerance，则是使用的 replayable write 的方式，如果 Coordinator 在发送 VAL 消息之前跪了，那么就可能导致一个 key 处于 invalid 状态。这里可以直接 replay write，因为 Hermes 会做如下事情：

• INV 消息里面会带上写入的新值，这样收到 INV 的 replica 都能知道这个值，并且将其设置为 Invalid 状态
• Logical timestamp 能保证在每个 replica 上面的 write 顺序
• 基于上述两点，任何一个节点如果发现一个 key 处于 Invalid 状态超过一段时间，就可以认为自己是 coordinator，使用之前的 LT，重新传递之前的 INV 消息，安全的 replay 这个 write。

Membership 变更

再来说说另一个需要关注的 membership 变更，Hermes 采用的是比较常用的做法，叫做 m-update。一个 m-update 包括：

• 一个新的 lease
• 一批新的 live nodes
• 一个递增的 epoch ID

一个接受了 m-update 的 replica 就可以当成 coordinator 了，这里需要注意：

• 如果 read 处于 Valid 的 key，仍然是按照之前的方式处理
• 如果 write 或者 read 处于 Invalid 的 key，则需要等 m-update 里面的 live nodes 接受到 m-update
• 如果一个 follower 还没接受到 m-update，则会丢弃后续的消息，因为这些消息的 epoch ID 会比 follower 当前的 epoch ID 要大

Example

下面是 Paper 实际列举的一个例子：

1. Node 1 开始 write A = 1，同样，node 3 开始 write A = 3。
2. Node 2 收到 Node 1 的 INV 消息，回复了 ACK，并且将 Key A 变成了 Invalid 状态
3. Node 3 给 Node 1 也回复了 ACK，但 Node 3 并没有改变 A 或者它的状态，因为 A 的 LT 是比 Node 1 发过来的 INV 要大的。
4. Node 2 收到了 Node 3 的 INV，因为这个 INV 的 LT 比之前的要大，所以 Node 2 更新了本地 A 的 LT 和 value
5. Node 1 收到了 Node 3 的 INV，同理也更新了本地 A 的状态
6. Node 2 开始一次 read，因为 A 的状态是 invalid，所以 read 会 stalled，然后收到 VAL 的消息，就可以读取了，这时候读到的值是 3
7. Node 1 收到了所有的 ACKs，但仍然将 A 变成了 Invalid 状态，因为之前收到从 Node 3 发来的带有更大 LT 的 INV 消息，但还没收到 Node 3 发来的 VAL 消息
8. 如果 Node 3 跪掉了，Node 1 还没收到 VAL 消息
   1. Lease 过期，Node 3 仍然是 failed，membership 更新
   2. 从 Node 1 读取 A，会发现处于 Invalid 状态，Node 1 对 A 进行 replay 操作
   3. Node 2 收到消息不用处理，因为有同样的 LT
   4. Node 1 收到 Node 2 的 ACK，完成 replay，并且广播 VAL

写在最后

上面只是简单的介绍了 Hermes 常用的读写流程以及成员变更方式，其实 Hermes 还提供了 CAS 支持，不过我也懒得研究了，总得来说，Hermes 还是非常简单的，而且非常容易实现，更难得可贵的是，Hermes 提供了 TLA+ 的证明，我现在也佩服我自己，竟然还能看得懂，之前的辛苦学习没白费。。。

关于更多的信息，大家可以直接用官网 https://hermes-protocol.com/ 看看。