使用hashicorp/raft

hashicorp/raft 代码: https://github.com/hashicorp/raft

一个参考示例：https://cloud.tencent.com/developer/article/1183490

hashicorp/raft是一个go的package，可以使用它来构建强一致的分布式系统。这个包完整的实现了raft协议，我们在编写应用程序时，无需关心raft的内部，只把它当作一个一致性模块来用。

假设我们要构建一个分布式应用，需要部署多个节点，每个节点上的状态都要一致。现在来考虑一下，如果raft已经实现为一个库，我们该怎么使用它，它应该提供哪些接口。

建立raft节点

每个应用程序都应该实现为一个raft节点，节点和节点之间通过raft协议来保证状态的一致。每个节点都需要能够处理raft协议中的各种细节，比如leader要定时发送心跳，follower要正确的响应心跳消息以及日志复制消息等。

在hashicorp/raft提供的api中，提供了 NewRaft() 来新建一个Raft 结构，这个结构代表着一个raft节点。

处理日志条目

只有leader能够追加日志条目，因此hashicorp/raft需要提供一个接口让应用程序判断自己是不是leader。hashicorp/raft里的Config.NotifyCh可以用来判断leader的状态变化。

追加日志条目的过程：需要写本地存储，以及发送给所有的follower，并确认是否commit。这个操作在hashicopr/raft中是由Raft.Apply()来完成，这个函数返回一个Future，其实就是一个channel，在以上操作完成后，可以从这个channel中读取出处理结果。

这个Apply和应用程序自己定义的FSM上的Apply不是同一个，后者是在日志条目commit后，将日志条目应用到应用程序的FSM上的方法，需要由应用程序来实现。

应用程序的FSM

应用程序有自己的数据处理逻辑，hashicopr/raft规定了一个FSM interface，其中有个Apply方法，应用程序在这里实现自己的逻辑。比如，对于存储系统来说，FSM的Apply可能就是把数据写入到本地磁盘。

当一条日志条目被commit后，就可以安全的应用到程序的FSM上。这个过程由raft来完成，我们只需负责实现Apply。

快照的处理

当日志条目过多时，raft会对日志文件进行compaction，形成一个快照。 当有新节点加入，或者某个节点因为故障而落后了很多日志条目时，leader可以直接发送快照给这个节点，而不需要将之前所有日志条目都发送过去。

这种情况下，应用程序的FSM也需要能够支持生成快照，以及从快照恢复的功能。hashicopr/raft在FSM interface中规定了这两个api: Snapshot() 以及 Restore()。

raft对自己的日志条目压缩得到的快照，和应用程序FSM调用Snapshot得到的快照，从逻辑上说指的不是同一个。具体可以参考论文第七章的描述。不过我们在使用hashicopr/raft时并不用太关心这些细节，只要把Snapshot()以及 Restore()实现好就可以了。

集群的变更

新加入节点到raft中，可以调用hashicopr/raft提供的Raft.AddVoter()方法。这个方法也可以用来启动集群，比如，先启动一个节点，然后把其他节点依次通过AddVoter()添加到集群中。