使用C++ 20协程实现Raft共识算法

本文描述了如何在不使用任何额外库的情况下在c++ 20中实现Raft Server共识模块。文章分为三个主要部分:

1. Raft算法的全面概述
2. 关于Raft服务器开发的详细说明
3. 对基于协程的自定义网络库的描述

该实现利用了C++ 20的强大功能，特别是协同程序，为构建分布式系统的关键组件提供了一种有效而现代的方法。本文会不仅展示了C++ 20协程在复杂编程环境中的实际应用和优点，而且还深入探讨了从头开始构建共识模块(如Raft Server)时遇到的挑战和解决方案。可以参考开源项目：miniraft-cpp 和 coroio 进一步探索和实际应用。

简介

在深入研究Raft算法的复杂性之前，让我们考虑一个现实世界的例子。我们的目标是开发一个网络键值存储(K/V)系统。在C++中，这可以通过使用unordered_map<string, string>轻松实现。然而，在实际应用程序中，对容错存储系统的需求增加了复杂性。一种看似简单的方法可能需要部署三台(或更多)机器，每台机器托管该服务的一个副本。用户可能期望管理数据复制和一致性。然而，这种方法可能导致不可预测的行为。例如，可以使用特定的键更新数据，然后稍后检索旧版本。

用户真正想要的是一个分布式系统，可能分布在多台机器上，运行起来像单主机系统一样流畅。为了满足这一需求，共识模块通常被放置在K/V存储(或任何类似的服务，以下称为“状态机”)的前面。此配置确保与状态机的所有用户交互都通过共识模块路由，而不是直接访问。考虑到这个上下文，现在让我们看看如何实现这样一个共识模块，以Raft算法为例。 

Raft概述

在Raft算法中，有奇数个参与者称为peers。每个peers都有自己的记录日志。有一个同侪领袖，其他人都是追随者。用户将所有请求(读和写)直接发送给leader。当接收到更改状态机的写请求时，leader首先将其记录下来，然后再将其转发给follower，后者也将其记录下来。一旦大多数peers成功响应，leader就认为该条目已提交，将其应用于状态机，并通知用户其成功。

Term是Raft中的一个关键概念，它只会不断发展。当系统发生变化时，例如领导层的变化，Term也会发生变化。Raft中的日志具有特定的结构，每个条目由Term和Payload组成。这个词指的是写最初条目的领导者。Payload表示要对状态机进行的更改。Raft保证具有相同索引和Term的两个条目是相同的。Raft日志不只是附加的，可以被截断。例如，在下面的场景中，leader S1在崩溃之前复制了两个条目。S2率先开始复制条目，S1的log与S2和S3的log不同。因此，S1日志中的最后一个条目将被删除并替换为一个新条目。

Raft RPC API

让我们再看一下一下Raft RPC。值得注意的是，Raft API非常简单，只有两个调用。我们将从查看领导人选举API开始。重要的是要注意，Raft确保每学期只能有一个领导者。如果选举失败，也可能出现没有领导人的任期。为了确保只发生一次选举，对peers将其投票保存在名为VotedFor的持久变量中。选举RPC称为RequestVote，它有三个参数:Term、LastLogIndex和LastLogTerm。响应包含Term和votegranting。值得注意的是，每个请求都包含Term，在Raft中，peer只有在它们的Terms兼容的情况下才能有效地通信。

当一个peer发起选举时，它向其他peer发送RequestVote请求并收集他们的投票。如果大多数人的回答都是积极的，这个伙计就晋升为领导者。

现在让我们看一下AppendEntries请求。它接受参数Term、PrevLogIndex、PrevLogTerm和Entries，响应包含Term和Success。如果请求中的Entries字段为空，则充当Heartbeat。

当接收到AppendEntries请求时，follower会检查PrevLogIndex中的Term。如果匹配到PrevLogTerm, follower会在其日志中添加以PrevLogIndex + 1开头的条目(如果存在，则删除在PrevLogIndex之后的条目)：

如果条件不匹配，则follower返回Success=false。在这种情况下，leader会重新发送请求，并将PrevLogIndex降低1。

当peer接收到RequestVote请求时，它将其LastTerm和LastLogIndex对与最近的日志条目进行比较。如果这对小于或等于请求者的，peer返回votegranting =true。

Raft中的状态转换

Raft的状态转换是这样的。每个peer从Follower状态开始。如果Follower在设定的超时时间内没有收到AppendEntries，则扩展其Term并移动到Candidate状态，从而触发选举。如果赢得选举，对等体可以从Candidate状态移动到Leader状态，如果收到AppendEntries请求，则返回到Follower状态。如果在超时时间内没有转换为Follower或Leader, Candidate也可以恢复为Candidate。如果处于任何状态的peer接收到具有大于其当前状态的Term的RPC请求，则它将移动到Follower状态。

安全提交

现在让我们考虑一个示例，该示例演示了Raft并不像看起来那么简单。我从Diego Ongaro的论文中选取了这个例子。S1在第2项中处于领先地位，它在崩溃之前复制了两个条目。在此之后，S5在第三学期领先，增加了一个条目，然后崩溃了。接下来，S2接管了Term 4的领导权，复制了Term 2的条目，为Term 4添加了自己的条目，然后崩溃了。这导致两种可能的结果:S5重新获得领导地位并截断Term 2中的条目，或者S1重新获得领导地位并提交Term 2中的条目。Term 2中的条目只有在被新leader的后续条目覆盖后才会被安全提交。

这个示例演示了Raft算法如何在动态且通常不可预测的情况下运行。事件序列(包括多个leader和崩溃)展示了跨分布式系统维护一致状态的复杂性。这种复杂性不会立即显现出来，但在涉及领导者变更和系统故障的情况下，它变得很重要。这个例子强调了处理这种复杂性的健壮和深思熟虑的方法的重要性，这正是Raft试图解决的问题。 

资料

为了进一步学习和更深入地了解Raft，我推荐以下材料:Raft的原始论文，这是理想的实现。Diego Ongaro的博士论文提供了更深入的见解。

Raft实现

现在让开始Raft服务器实现，在我看来，它从C++ 20协程中获益良多。在我的实现中，持久化状态存储在内存中。但是，在实际场景中，应该将其保存到磁盘。稍后我会详细讨论MessageHolder。它的功能类似于shared_ptr，但专门设计用于处理Raft消息，确保有效地管理和处理这些通信。

struct TState {
    uint64_t CurrentTerm = 1;
    uint32_t VotedFor = 0;
    std::vector<TMessageHolder<TLogEntry>> Log;
};

在易变状态中，我用L代表“领导者”或F代表“追随者”来标记条目，以澄清它们的用途。CommitIndex表示提交的最后一个日志条目。相反，LastApplied是应用到状态机的最新日志条目，它总是小于或等于CommitIndex。NextIndex很重要，因为它标识要发送给对等体的下一个日志条目。类似地，MatchIndex跟踪发现匹配的最后一个日志条目。Votes部分包含投票给我的同行的id。超时是一个需要管理的重要方面:HeartbeatDue和RpcDue管理leader超时，而ElectionDue处理follower超时。

using TTime = std::chrono::time_point<std::chrono::steady_clock>;

struct TVolatileState {
    uint64_t CommitIndex = 0; // L,F
    uint64_t LastApplied = 0; // L,F
    std::unordered_map<uint32_t, uint64_t> NextIndex; // L
    std::unordered_map<uint32_t, uint64_t> MatchIndex; // L
    std::unordered_set<uint32_t> Votes; // C
    std::unordered_map<uint32_t, TTime> HeartbeatDue; // L
    std::unordered_map<uint32_t, TTime> RpcDue; // L
    TTime ElectionDue; // F
};

Raft API

我的Raft算法实现有两个类。第一个是INode，它表示peers。这个类包括两个方法:Send(将传出的消息存储在内部缓冲区中)和Drain(处理实际的消息分派)。Raft是第二类，它管理当前对等体的状态。它还包括两个方法:Process(处理传入的连接)和ProcessTimeout(必须定期调用)，以管理超时，如leader选举超时。这些类的用户应该根据需要使用Process、ProcessTimeout和Drain方法。INode的Send方法在Raft类内部调用，确保消息处理和状态管理在Raft框架内无缝集成。

struct INode {
    virtual ~INode() = default;
    virtual void Send(TMessageHolder<TMessage> message) = 0;
    virtual void Drain() = 0;
};

class TRaft {
public:
    TRaft(uint32_t node,
        const std::unordered_map<uint32_t, std::shared_ptr<INode>>& nodes);
    void Process(TTime now,
        TMessageHolder<TMessage> message,
        const std::shared_ptr<INode>& replyTo = {});
    void ProcessTimeout(TTime now);
};

Raft 消息

现在让我们看看我是如何发送和读取Raft消息的。我没有使用序列化库，而是以TLV格式读取和发送原始结构。这是消息头的样子:

struct TMessage {
    uint32_t Type;
    uint32_t Len;
    char Value[0];
};

为了方便起见，我引入了第二级头文件:

struct TMessageEx: public TMessage {
    uint32_t Src = 0;
    uint32_t Dst = 0;
    uint64_t Term = 0;
};

这包括每条消息中的发送者和接收者的ID。除了LogEntry之外，所有消息都继承自TMessageEx。LogEntry和AppendEntries的实现如下:

struct TLogEntry: public TMessage {
    static constexpr EMessageType MessageType = EMessageType::LOG_ENTRY;
    uint64_t Term = 1;
    char Data[0];
};

struct TAppendEntriesRequest: public TMessageEx {
    static constexpr EMessageType MessageType
        = EMessageType::APPEND_ENTRIES_REQUEST;
    uint64_t PrevLogIndex = 0;
    uint64_t PrevLogTerm = 0;
    uint32_t Nentries = 0;
};

为了方便消息处理，我使用了一个叫做MessageHolder的类，类似于shared_ptr:

template<typename T>
requires std::derived_from<T, TMessage>
struct TMessageHolder {
    T* Mes;
    std::shared_ptr<char[]> RawData;
    uint32_t PayloadSize;
    std::shared_ptr<TMessageHolder<TMessage>[]> Payload;

    template<typename U>
    requires std::derived_from<U, T>
    TMessageHolder<U> Cast() {...}

    template<typename U>
    requires std::derived_from<U, T>
    auto Maybe() { ... }
};

该类包括一个包含消息本身的字符数组。它还可能包括一个Payload(仅用于AppendEntry)，以及用于将基本类型消息安全转换为特定类型消息的方法(Maybe方法)和不安全转换(Cast方法)。下面是一个使用MessageHolder的典型例子:

void SomeFunction(TMessageHolder<TMessage> message) {
    auto maybeAppendEntries = message.Maybe<TAppendEntriesRequest>();
    if (maybeAppendEntries) {
        auto appendEntries = maybeAppendEntries.Cast();
    }
    // if we are sure
    auto appendEntries = message.Cast<TAppendEntriesRequest>();
    // usage with overloaded operator->
    auto term = appendEntries->Term;
    auto nentries = appendEntries->Nentries;
    // ...
}

在Candidate状态处理程序中有一个真实的例子:

void TRaft::Candidate(TTime now, TMessageHolder<TMessage> message) {
    if (auto maybeResponseVote = message.Maybe<TRequestVoteResponse>()) {
        OnRequestVote(std::move(maybeResponseVote.Cast()));
    } else
    if (auto maybeRequestVote = message.Maybe<TRequestVoteRequest>())
    {
        OnRequestVote(now, std::move(maybeRequestVote.Cast()));
    } else
    if (auto maybeAppendEntries = message.Maybe<TAppendEntriesRequest>())
    {
        OnAppendEntries(now, std::move(maybeAppendEntries.Cast()));
    }
}

这种设计方法提高了Raft实现中消息处理的效率和灵活性。

Raft 服务端

让我们讨论一下Raft服务器实现。Raft服务器将为网络交互设置协同程序。首先，我们将查看处理消息读写的协程。本文稍后将讨论用于这些协程的原语，并对网络库进行分析。写协程负责向套接字写入消息，而读协程稍微复杂一些。要读取，它必须首先检索Type和Len变量，然后分配Len字节数组，最后读取消息的其余部分。这种结构促进了Raft服务器内网络通信的高效管理。

template<typename TSocket>
TValueTask<void>
TMessageWriter<TSocket>::Write(TMessageHolder<TMessage> message) {
    co_await TByteWriter(Socket).Write(message.Mes, message->Len);

    auto payload = std::move(message.Payload);
    for (uint32_t i = 0; i < message.PayloadSize; ++i) {
        co_await Write(std::move(payload[i]));
    }

    co_return;
}

template<typename TSocket>
TValueTask<TMessageHolder<TMessage>> TMessageReader<TSocket>::Read() {
    decltype(TMessage::Type) type; decltype(TMessage::Len) len;
    auto s = co_await Socket.ReadSome(&type, sizeof(type));
    if (s != sizeof(type)) { /* throw */ }
    s = co_await Socket.ReadSome(&len, sizeof(len));
    if (s != sizeof(len)) { /* throw */}
    auto mes = NewHoldedMessage<TMessage>(type, len);
    co_await TByteReader(Socket).Read(mes->Value, len - sizeof(TMessage));
    auto maybeAppendEntries = mes.Maybe<TAppendEntriesRequest>();
    if (maybeAppendEntries) {
        auto appendEntries = maybeAppendEntries.Cast();
        auto nentries = appendEntries->Nentries; mes.InitPayload(nentries);
        for (uint32_t i = 0; i < nentries; i++) mes.Payload[i] = co_await Read();
    }
    co_return mes;
}

要启动一个Raft服务器，需要创建一个RaftServer类的实例并调用Serve方法。Serve方法启动两个协程。Idle协程负责定期处理超时，而InboundServe负责管理传入的连接。

class TRaftServer {
public:
    void Serve() {
        Idle();
        InboundServe();
    }

private:
    TVoidTask InboundServe();
    TVoidTask InboundConnection(TSocket socket);
    TVoidTask Idle();
}

通过accept调用接收传入连接。接下来，启动InboundConnection协程，它读取传入消息并将其转发给Raft实例进行处理。此配置确保Raft服务器可以有效地处理内部超时和外部通信。

TVoidTask InboundServe() {
    while (true) {
        auto client = co_await Socket.Accept();
        InboundConnection(std::move(client));
    }
    co_return;
}

TVoidTask InboundConnection(TSocket socket) {
    while (true) {
        auto mes = co_await TMessageReader(client->Sock()).Read();
        Raft->Process(std::chrono::steady_clock::now(), std::move(mes),
            client);
        Raft->ProcessTimeout(std::chrono::steady_clock::now());
        DrainNodes();
    }
    co_return;
}

Idle协程的工作方式如下:它在每个睡眠秒调用ProcessTimeout方法。值得注意的是，这个协程使用异步睡眠。这种设计使Raft服务器能够有效地管理时间敏感的操作，而不会阻塞其他进程，从而提高服务器的整体响应能力和性能。

while (true) {
    Raft->ProcessTimeout(std::chrono::steady_clock::now());
    DrainNodes();
    auto t1 = std::chrono::steady_clock::now();
    if (t1 > t0 + dt) {
        DebugPrint();
        t0 = t1;
    }
    co_await Poller.Sleep(t1 + sleep);
}

协程是为发送外发消息而创建的，设计得很简单。它在循环中将所有累积的消息重复发送到套接字。如果发生错误，它会启动另一个负责连接的协程(通过connect函数)。此结构可确保平稳有效地处理传出消息，同时通过错误处理和连接管理保持健壮性。

try {
    while (!Messages.empty()) {
        auto tosend = std::move(Messages); Messages.clear();
        for (auto&& m : tosend) {
            co_await TMessageWriter(Socket).Write(std::move(m));
        }
    }
} catch (const std::exception& ex) {
    Connect();
}
co_return;

通过实现Raft Server，这些示例展示了协程如何极大地简化了开发。虽然我没有研究过Raft的实现(相信我，它比Raft服务器复杂得多)，但总体算法不仅简单，而且设计紧凑。

接下来，我们将看一些Raft Server示例。接下来，我将描述我从头开始专门为Raft服务器创建的网络库。这个库对于在Raft框架内实现高效的网络通信至关重要。

下面是启动具有三个节点的Raft集群的示例。每个实例接收自己的ID作为参数，以及其他实例的地址和ID。在这种情况下，客户端只与领导者通信。它发送随机字符串，同时保留一定数量的正在发送的消息并等待它们的承诺。该配置描述了在多节点Raft环境中客户端和leader之间的交互，演示了算法对分布式数据和共识的处理。

$ ./server --id 1 --node 127.0.0.1:8001:1 --node 127.0.0.1:8002:2 --node 127.0.0.1:8003:3
...
Candidate, Term: 2, Index: 0, CommitIndex: 0,
...
Leader, Term: 3, Index: 1080175, CommitIndex: 1080175, Delay: 2:0 3:0
        MatchIndex: 2:1080175 3:1080175 NextIndex: 2:1080176 3:1080176
....
$ ./server --id 2 --node 127.0.0.1:8001:1 --node 127.0.0.1:8002:2 --node 127.0.0.1:8003:3
...
$ ./server --id 3 --node 127.0.0.1:8001:1 --node 127.0.0.1:8002:2 --node 127.0.0.1:8003:3
...
Follower, Term: 3, Index: 1080175, CommitIndex: 1080175,
...
$ dd if=/dev/urandom | base64 | pv -l | ./client --node 127.0.0.1:8001:1 >log1
 198k 0:00:03 [159.2k/s] [        <=>

我测量了3节点和5节点集群配置的提交延迟。正如预期的那样，5节点设置的延迟更高:

• 3个节点

        50百分位(中位数):292872 纳秒
        80百分位:407561纳秒
        90百分位:569164 纳秒
        99%百分位数:40279001 纳秒

• 5个节点

        50百分位(中位数):425194 纳秒
        80百分位:672541 纳秒
        90百分位:1027669 纳秒
        99%: 38578749 纳秒

I/O库

现在让我们看一下我从头创建并在Raft服务器实现中使用的I/O库。我从下面的例子开始，摘自cppreference.com，这是一个echo服务器的实现:

task<> tcp_echo_server() {
    char data[1024];
    while (true) {
        std::size_t n = co_await socket.async_read_some(buffer(data));
        co_await async_write(socket, buffer(data, n));
    }
}

事件循环、套接字原语和read_some/write_some(在我的库中称为ReadSome/ writsome)这样的方法是我的库所需要的，以及更高级别的包装器，如async_write/async_read(在我的库中称为TByteReader/TByteWriter)。
为了实现套接字的ReadSome方法，我必须像下面这样创建一个可等待对象:

auto ReadSome(char* buf, size_t size) {
    struct TAwaitable  {
        bool await_ready() { return false; /* always suspend */ }
        void await_suspend(std::coroutine_handle<> h) {
            poller->AddRead(fd, h);
        }
        int await_resume() {
            return read(fd, b, s);
        }
        TSelect* poller; int fd; char* b; size_t s;
    };
    return TAwaitable{Poller_,Fd_,buf,size};
}

当调用co_await时，协程会挂起，因为await_ready返回false。在await_suspend中，我们捕获coroutine_handle并将其与套接字句柄一起传递给轮询器。当套接字准备好时，轮询器调用coroutine_handle来重新启动协程。在恢复时，调用await_resume，它执行读取操作并将读取的字节数返回给协程。WriteSome、Accept和Connect方法以类似的方式实现。

轮询器的设置如下:

struct TEvent {
    int Fd; int Type; // READ = 1, WRITE = 2;
    std::coroutine_handle<> Handle;
};
class TSelect {
    void Poll() {
        for (const auto& ch : Events) { /* FD_SET(ReadFds); FD_SET(WriteFds);*/ }
        pselect(Size, ReadFds, WriteFds, nullptr, ts, nullptr);
        for (int k = 0; k < Size; ++k) {
            if (FD_ISSET(k, WriteFds)) {
                Events[k].Handle.resume();
            }
            // ...
        }
    }
    std::vector<TEvent> Events;
    // ...
};

我保留了一个对数组(套接字描述符、协程句柄)，用于初始化轮询器后端(在本例中为select)的结构。Resume在对应于就绪套接字的协程唤醒时被调用。
这在main函数中应用如下:

TSimpleTask task(TSelect& poller) {
    TSocket socket(0, poller);
    char buffer[1024];
    while (true) {
        auto readSize = co_await socket.ReadSome(buffer, sizeof(buffer));
    }
}
int main() {
    TSelect poller;
    task(poller);
    while (true) { poller.Poll(); }
}

我们启动一个(或多个)在co_await上进入休眠模式的协程，然后将控制传递给调用轮询器机制的无限循环。如果套接字在轮询器中准备就绪，则触发并执行相应的协程，直到下一个co_await。

为了读写Raft消息，我需要在ReadSome/ writsome上创建高级包装器，类似于:

TValueTask<T> Read() {
    T res; size_t size = sizeof(T);
    char* p = reinterpret_cast<char*>(&res);
    while (size != 0) {
        auto readSize = co_await Socket.ReadSome(p, size);
        p += readSize;
        size -= readSize;
    }
    co_return res;
}
// usage
T t = co_await Read<T>();

为了实现这些，我需要创建一个协程，它也具有可等待对象的功能。协程由一对:coroutine_handle和promise组成。coroutine_handle用于从外部管理协程，而promise用于内部管理。coroutine_handle可以包含可等待方法，这些方法允许使用co_await等待协程的结果。promise可用于存储co_return返回的结果并唤醒调用的协程。

在coroutine_handle中，在await_suspend方法中，我们存储了调用协程的coroutine_handle。它的值将保存在promise中:

template<typename T>
struct TValueTask : std::coroutine_handle<> {
    bool await_ready() { return !!this->promise().Value; }
    void await_suspend(std::coroutine_handle<> caller) {
        this->promise().Caller = caller;
    }
    T await_resume() { return *this->promise().Value; }
    using promise_type = TValuePromise<T>;
};

在promise本身中，return_value方法将存储返回值。调用协程用一个可等待对象唤醒，该可等待对象在final_suspend中返回。这是因为编译器在co_return之后调用了final_suspend上的co_await。

template<typename T>
struct TValuePromise {
    void return_value(const T& t) { Value = t; }
    std::suspend_never initial_suspend() { return {}; }
    // resume Caller here
    TFinalSuspendContinuation<T> final_suspend() noexcept;
    std::optional<T> Value;
    std::coroutine_handle<> Caller = std::noop_coroutine();
};

在await_suspend中，可以返回调用的协程，它将被自动唤醒。需要注意的是，被调用的协程现在将处于睡眠状态，必须用destroy销毁它的coroutine_handle以避免内存泄漏。例如，这可以在TValueTask的析构函数中实现。

template<typename T>
struct TFinalSuspendContinuation {
    bool await_ready() noexcept { return false; }
    std::coroutine_handle<> await_suspend(
        std::coroutine_handle<TValuePromise<T>> h) noexcept
    {
        return h.promise().Caller;
    }
    void await_resume() noexcept { }
};

完成库描述后，我将libevent基准测试移植到库中，以确保其性能。这个基准测试生成一个由N个Unix管道组成的链，每个管道都链接到下一个管道。然后，它向链中发起100个写操作，一直持续到总共有1000个写调用。下图将基准测试的运行时描述为我的库(coroio)与libevent的各种后端的N函数。这个测试表明，我的库的性能与libevent相似，证实了它在管理I/O操作方面的效率和有效性。

总结

最后，本文描述了使用c++ 20协程实现Raft服务器，强调了这个现代c++特性提供的便利性和效率。从头编写的自定义I/O库对这个实现至关重要，因为它有效地处理异步I/O操作。通过libevent基准测试验证了库的性能，证明了它的能力。

对于那些有兴趣了解或使用这些工具的人，可以在coroio上找到I/O库，在miniraft库上找到Raft库(在文章开头有链接)。这两个存储库都详细介绍了如何使用C++ 20协程构建健壮的高性能分布式系统。