当您的 Raft 节点被触发并运行时，Raft 应该进入 Ready 状态。您需要首先使用 has_ready 来检查 Raft 是否已准备好。如果是，则使用 ready 函数获取一个 Ready 状态。

#
#
if !node.has_ready() {
return;
}

// The Raft is ready, we can do something now.
let mut ready = node.ready();

Ready 状态包含大量信息，您需要逐个检查和处理它们。

1. 检查 messages 是否为空。如果不为空，则表示节点将向其他节点发送消息。

#
#
#
if !ready.messages().is_empty() {
for msg in ready.take_messages() {
// Send messages to other peers.
}
}

2. 检查 snapshot 是否为空。如果不为空，则表示 Raft 节点已从领导者接收 Raft 快照，我们必须应用该快照。

#
#
#
if !ready.snapshot().is_empty() {
// This is a snapshot, we need to apply the snapshot at first.
node.mut_store()
.wl()
.apply_snapshot(ready.snapshot().clone())
.unwrap();
}

3. 检查 committed_entries 是否为空。如果不为空，则表示有一些新的已提交日志条目，您必须将这些条目应用到状态机。当然，在应用后，您需要更新已应用索引，并在稍后恢复 apply。

#
#
#
#
#
#
let mut _last_apply_index = 0;
for entry in ready.take_committed_entries() {
// Mostly, you need to save the last apply index to resume applying
// after restart. Here we just ignore this because we use a Memory storage.
_last_apply_index = entry.index;

if entry.data.is_empty() {
// Emtpy entry, when the peer becomes Leader it will send an empty entry.
continue;
}

match entry.get_entry_type() {
EntryType::EntryNormal => handle_normal(entry),
// It's recommended to always use `EntryType::EntryConfChangeV2.
EntryType::EntryConfChange => handle_conf_change(entry),
EntryType::EntryConfChangeV2 => handle_conf_change_v2(entry),
}
}

注意，尽管 Raft 保证只有已持久化的已提交条目才会被应用，但它不保证在应用之前提交索引已被持久化。例如，如果应用在将提交索引持久化之前应用了已提交条目后重新启动，则应用索引可能大于提交索引，从而导致恐慌。为了解决这个问题，在应用条目之前或同时持久化提交索引。您也可以在重启后始终将提交索引分配给 max(commit_index, applied_index)，这可能有效，但可能忽略潜在日志丢失的风险。

4. 检查 entries 是否为空。如果不为空，则表示有一些新添加的条目但尚未提交，我们必须将这些条目附加到 Raft 日志中。

#
#
#
if !ready.entries().is_empty() {
// Append entries to the Raft log
node.mut_store().wl().append(ready.entries()).unwrap();
}

5. 检查 hs 是否为空。如果不为空，则表示节点的 HardState 已更改。例如，节点可能会为新领导者投票，或者提交索引已增加。我们必须持久化更改后的 HardState。

#
#
#
if let Some(hs) = ready.hs() {
// Raft HardState changed, and we need to persist it.
node.mut_store().wl().set_hardstate(hs.clone());
}

6. 检查 persisted_messages 是否为空。如果不为空，则表示节点将在持久化硬状态、条目和快照后向其他节点发送消息。

#
#
#
if !ready.persisted_messages().is_empty() {
for msg in ready.take_persisted_messages() {
// Send persisted messages to other peers.
}
}

7. 调用 advance 来通知先前工作已完成。获取返回值 LightReady 并像步骤 1 和步骤 3 一样处理其 messages 和 committed_entries。然后调用 advance_apply 来推进内部的应用索引。

#
#
#
#
let mut light_rd = node.advance(ready);
// Like step 1 and 3, you can use functions to make them behave the same.
handle_messages(light_rd.take_messages());
handle_committed_entries(light_rd.take_committed_entries());
node.advance_apply();

有关更多信息，请参阅示例。

有时在 IO 操作中不阻塞 raft 机器会更好，这样读写延迟就可以更可预测，fsync 频率也可以得到控制。该包支持异步就绪，可以将 IO 操作卸载到其他线程。用法与上面相同，除了

1. 所有写操作都不需要立即持久化，它们可以写入内存缓存；
2. 在所有相应的写入都持久化之后，应该发送持久化消息；
3. 当所有写入都完成时，使用 advance_append_async 而不是 advance/advance_append。
4. 只有已持久化的条目才能提交和应用，因此为了取得进展，所有写入都应该在某一点被持久化。

任意成员变更

在构建一个健壮、可扩展的分布式系统时，强烈需要能够动态地更改对等组（peer group）的成员，而无需停机。这个Raft crate通过联合共识（Raft论文，第6节）支持这一点。

它允许健壮的任意动态成员变更。成员变更可以执行以下任一或所有操作

• 将Peer（学习者或投票者）n添加到组中。
• 从组中移除学习者n。
• 将学习者提升为投票者。
• 将投票者降级为学习者。
• 用一个节点n替换另一个节点m。

例如，提升学习者4并降级现有的投票者3

#
let steps = vec![
raft_proto::new_conf_change_single(4, ConfChangeType::AddNode),
raft_proto::new_conf_change_single(3, ConfChangeType::RemoveNode),
];
let mut cc = ConfChangeV2::default();
cc.set_changes(steps.into());
node.propose_conf_change(vec![], cc).unwrap();
// After the log is committed and applied
// node.apply_conf_change(&cc).unwrap();

这个过程是一个两阶段过程，在这个过程中，对等组的领导者正在管理两个独立、可能重叠的对等集。

注意：为了保持弹性保证（在两个对等集的大部分处于活动状态时取得进展），建议在将旧、已删除的对等机下线之前，等待整个对等组都退出转换阶段。

为使用raft crate的crate编写的前言。

这个前言与标准库的前言类似，因为你几乎总是想导入其全部内容，但与标准库的前言不同，你必须手动这样做。

use jopemachine_raft::prelude::*;

随着更多项的使用变得普遍，前言可能会随着时间的推移而增长。