RaftKeeper v2.1.0 版本发布，性能大幅提升!

2024-07-15
北京
本文字数：3879 字
阅读完需：约 13 分钟

RaftKeeper 是一款高新能分布式共识服务，完全兼容 Zookeeper 但性能更出色，更多关于 RaftKeeer 参考Github，我们将 RaftKeeper 大规模应用到 ClickHouse 场景中，用于解决 ZooKeeper 的性能瓶颈问题，同时 RaftKeeper 也可以用于其它大数据组件比如 HBase。

v2.1.0 作为 v2.0.0 后的重要版本，引入了一系列新特性，包括异步创建 snapshot。该版本的最大亮点在于性能优化：写请求性能提升 11%，读写混合场景更是大幅提升了 118% 。本文将从工程细节的角度深入解析新版本的改进与优化。

一、性能优化效果

在性能测试中，我们使用了raftkeeper-bench工具，测试环境为三个节点组成的集群，每个节点配置为 16 核 CPU、32GB 内存和 100GB 存储空间。测试对象包括 RaftKeeper v2.1.0、RaftKeeper v2.0.4 和 ZooKeeper 3.7.1，均采用默认配置。

测试分为两组：

第一组测试纯 create 操作的性能，create 操作的 value 大小为 100 字节。结果显示，RaftKeeper v2.1.0 相较于 v2.0.4 性能提升了 11%，相较于 ZooKeeper 性能提升了 143%。

第二组请求比例为 create-1%、set-8%、get-45%、list-45%、delete-1%。其中，list 请求结果包含 100 个子节点，每个子节点大小为 50 字节；get、set、create 请求的节点 value 大小为 100 字节。结果显示，RaftKeeper v2.1.0 相较于 v2.0.4 性能提升了 118%，相较于 ZooKeeper 性能提升了 198%。

rk2.1.0 版本在测试中 avgRT 和 TP99 指标均优于 rk2.0.4，具体可以参考测试报告。

二、性能优化

接下来从工程细节的角度，介绍一些 v2.1.0 的优化点。

1. 响应并行序列化

RaftKeeper 被我们广泛应用到 ClickHouse 中，下图是一个规模较大的 RaftKeeper 集群的火焰图，通过火焰图发现 ResponseThread 线程消耗不少 CPU 时间片，其中大概三分之一时间片用于序列化响应。

ResponseThread 负责序列化响应并且转发给 IO 线程，它是一个单线程，串行执行序列化会增大延迟。我们可以把响应的序列化交给 IO 线程来做，以并发的方式提高吞吐。

同时可以看到sdallocx_default函数占用了不少时间片，该函数是 jemelloc 释放内存的函数，函数对于时间片的消耗没有问题，但是该操作在基于 mutex 的同步队列中执行会增加锁的时间。

/// responses_queue是一个基于mutex的同步队列，在tryPop方法中释放response_for_session会增加lock的时间responses_queue.tryPop(response_for_session, std::min(max_wait, static_cast<UInt64>(1000)))

复制代码

解决的方式是在 tryPop 方法前先释放 response_for_session 的内存空间。

下面的表格展示了优化前后的性能指标，测试共有四组每组使用不同的并发度，其中响应大小为 50bytes，当并发度为 10 的时候，TPS 增加 31%，AvgRT 降低 32%。

2. 优化 List 请求

依然是同一个 RaftKeeper 集群，通过火焰图发现，List 请求处理几乎消耗了 request-processor 线程所有的 CPU 时间片。在 RaftKeeper 的执行链路中 request-processor 负责处理用户的请求，它是一个单线程，所以比较容易成为瓶颈点。

通过火焰图可以发现两个瓶颈点：1.为字符串分配内存空间；2.插入 vector。

List 请求返回的结果是一个 std::vector<string>动态数组，其内存 layout 如下图所示，每个成员是一个字符串，每个字符串需要分配一块动态内存用于保存数据，所以当字符串多的时候需要大量的动态内存分配。

一个很直观的优化思路，可以设计一个 compact strings，数据采用紧凑的方式存储，在以下的设计中，采用两个连续内存空间，一个用于存储数据，一个用于存储 offset，具体参考：CompactStrings实现。

优化后从火焰图方面看 List 请求处理在 CPU 的占比从 5.46%下降到 3.37%，进行 List 请求的 benchmark 测试，TPS 从 45.8w/s 增长到 61.9w/s，同时 TP99 更低。

优化前：read requests 14826483, write requests 0, Read RPS: 458433, Read MiB/s: 2441.74, TP99 1.515 msec
优化后：read requests 14172371, write requests 0, Read RPS: 619388, Read MiB/s: 3156.67, TP99 0.381 msec.

复制代码

3. 优化无用的系统调用

系统调用会引起用户态和内核态的上下文切换，往往系统调用函数会有比较大的开销，我们通过 bpftrace 对 RaftKeeper 进行了 profile

BPFTRACE_MAX_PROBES=1024 bpftrace -p 4179376 -e ' tracepoint:syscalls:sys_enter_* { @start[tid] = nsecs; }tracepoint:syscalls:sys_exit_* /@start[tid]/ {    @time[probe] = sum(nsecs - @start[tid]);    delete(@start[tid]);    @cc[probe] = sum(1);}
interval:s:10{ exit(); }'

复制代码

发现大量的getsockname和getsockopt系统调用占用了不少开销。

Execution count:@cc[tracepoint:syscalls:sys_exit_getsockname]: 2878146@cc[tracepoint:syscalls:sys_exit_getsockopt]: 2821796
Execution time (ns):@time[tracepoint:syscalls:sys_exit_getsockopt]: 3161677518@time[tracepoint:syscalls:sys_exit_getsockname]: 2647505715

复制代码

这些系统调用本不该存在，经过排查发现是在打印日志的时候错误的进行了调用。

const auto socket_name = sock.isStream() ? sock.address().toString() : sock.peerAddress().toString();LOG_TRACE(log, "Dispatch event {} for {} ", notification.name(), socket_name);

复制代码

4. 线程池优化

下图是一次 benchmark（读写 4:6 的比例）RaftKeeper 的火焰图，进行性能瓶颈分析发现，发现 request-processor 线程的 CPU 时间片大部分时间(超过 60%)消耗在条件变量等待的调用。

在 RaftKeeper 的主执行链路中 request-processor 线程负责处理用户请求，它的主要流程可以简单抽象为：1. 对于写请求，单线程处理；2. 对于读请求，通过线程池并发处理，然后调用 request_thread->wait()阻塞等待所有读取请求完成。

/// 1. process read-request by a thread poolfor (RunnerId runner_id = 0; runner_id < runner_count; runner_id++){    request_thread->trySchedule(    [this, runner_id]    {        moveRequestToPendingQueue(runner_id);        processReadRequests(runner_id);    });}
/// 2. wait read request processingrequest_thread->wait();   
/// 3. process write-request in single threadprocessCommittedRequest(committed_request_size);

复制代码

增加监控指标分别统计读和写请求的执行时间发现，在读请求和写请求数量几乎相同的情况下，读请求的处理延时是写请求的 3 倍。

因为每个请求的处理时间很短，到这里可以推测出，线程池任务调度的时间不可忽视，所以出现了性能下降。解决方式是去掉线程池，单线程处理读请求，以下 benchmark 是优化前后 benchmark 结果，TPS 提升 13%。

优化前：thread_size,tps,avgRT(microsecond),TP90(microsecond),TP99(microsecond),TP999(microsecond),failRate200,84416,2407.0,3800.0,4500.0,8300.0,0.0
优化后：thread_size,tps,avgRT(microsecond),TP90(microsecond),TP99(microsecond),TP999(microsecond),failRate200,108950,1846.0,3100.0,4000.0,5600.0,0.0

复制代码

三、Snapshot 优化

1. 异步 snapshot

在 RaftKeeper 整个请求处理链路中，创建 snapshot 是在主链路中进行处理的，当数据量大的时候会长时间阻塞用户请求，造成请求超时、leader 切换等引起服务不可用的问题，在我们线上场景中对于 6000w 的数据做 snapshot 需要 180s。

为了解决以上问题，新版本中支持了异步 snapshot，当需要创建 snapshot 的时候首先将整个 DataTree 拷贝一份，这一步在主线程中处理，然后在后台将拷贝的 DataTree 序列化到磁盘中。

采用这用方式 6000w 的数据做 snaphot 对用户的阻塞时间从 180s 降低到了 4.5s，但是这种方案也有一些负面效果，需要额外消耗大于 50%的内存。

为了进一步降低对用户的阻塞时间，对 DataTree 拷贝进行了进一步优化。DataTree 拷贝其实是一个计算密集型的任务，所以可以采用向量化的方式，同时会遍历 hashmap 可以适当进行 prefetch。

inline void memcopy(char * __restrict dst, const char * __restrict src, size_t n){    auto aligned_n = n / 16 * 16;    auto left = n - aligned_n;    while (aligned_n > 0)    {        _mm_storeu_si128(reinterpret_cast<__m128i *>(dst), _mm_loadu_si128(reinterpret_cast<const __m128i *>(src)));
        dst += 16;        src += 16;        aligned_n -= 16;        __asm__ __volatile__("" : : : "memory");    }    ::memcpy(dst, src, left);}