RocksDB 在鲲鹏架构下的性能优化源码解析

2.1.3 PMULL 与硬件预取

对于更大的数据块，引入了基于 PMULL (Polynomial Multiply) 指令的优化，允许一次性处理 64 字节数据。同时，利用 PRFM 指令进行硬件预取：

#define PREF4X64L1(buffer, PREF_OFFSET, ITR) \
 __asm__("PRFM PLDL1KEEP, [%x[v],%[c]]" ::[v] "r"(buffer), \
 [c] "I"((PREF_OFFSET) + ((ITR) + 0) * 64));

这显式地告诉 CPU 提前将数据搬运到 L1 缓存，掩盖了内存访问延迟。

2.2 KAE 硬件压缩集成

鲲鹏处理器配备了 KAE (Kunpeng Acceleration Engine) 硬件加速引擎，可以卸载 Zlib/Gzip 等压缩任务。

2.2.1 集成原理

RocksDB 本身通过 kZlibCompression 接口调用系统的 zlib 库。提供了兼容 zlib 接口的 KAE 加速库 (libwd, libkae)。通过动态库劫持或链接替换的方式，RocksDB 可以透明地使用硬件加速，而无需修改 RocksDB 的压缩逻辑源码。

2.2.2 部署与收益

1. 配置：设置 LD_LIBRARY_PATH 优先加载 KAE 库，并在 RocksDB 中开启 kZlibCompression。
2. 收益：相比软件 Zlib，KAE 硬件加速通常能提供 30% - 50% 的压缩吞吐量提升，同时 CPU 占用率降低 40% 以上。

示例代码：

#include <iostream>
#include <zlib.h>
#include <vector>
#include <chrono>
#include <string>
int main() {
    // 模拟较大数据块（1 MB）
    std::vector<unsigned char> input(1024 * 1024, 'A');
    std::vector<unsigned char> compressed(input.size() * 2);
    std::vector<unsigned char> decompressed(input.size());
    uLongf compressed_size, decompressed_size;
    // 压缩测试
    auto start = std::chrono::high_resolution_clock::now();
    compressed_size = compressed.size();
    int ret = compress(compressed.data(), &compressed_size, input.data(), input.size());
    auto end = std::chrono::high_resolution_clock::now();
    double compress_ms = std::chrono::duration<double, std::milli>(end - start).count();
    if (ret == Z_OK) {
        std::cout << "Compression succeeded, size: " << compressed_size << ", time: " << compress_ms << " ms" << std::endl;
    } else {
        std::cout << "Compression failed, error: " << ret << std::endl;
    }
    // 解压测试
    start = std::chrono::high_resolution_clock::now();
    decompressed_size = decompressed.size();
    ret = uncompress(decompressed.data(), &decompressed_size, compressed.data(), compressed_size);
    end = std::chrono::high_resolution_clock::now();
    double decompress_ms = std::chrono::duration<double, std::milli>(end - start).count();
    if (ret == Z_OK) {
        std::cout << "Decompression succeeded, size: " << decompressed_size << ", time: " << decompress_ms << " ms" << std::endl;
    } else {
        std::cout << "Decompression failed, error: " << ret << std::endl;
    }
    // 验证内容一致
    bool valid = (input == decompressed);
    std::cout << "Data verification: " << (valid ? "PASS" : "FAIL") << std::endl;
    return 0;
}

3. 存储引擎内核：LSM-Tree 与 I/O 极致优化

I/O 效率是存储引擎的生命线。本章分析 RocksDB 在 LSM-Tree 维护和 I/O 路径上的优化。

3.1 block_prefetcher.cc 源码解析

在全表扫描（Scan）或 Compaction 时，顺序读取是主要模式。这里主要对 BoostKit RocksDB 的 block_prefetcher.cc 源码进行解析，实现了自适应指数级预取。

核心源码：

readahead_limit_ = offset + len + readahead_size_; // Keep exponentially increasing readahead size until // max_auto_readahead_size. 
readahead_size_ = std::min(max_auto_readahead_size, readahead_size_ * 2);

优化逻辑：

• 检测到连续读取后，预取窗口大小从 8KB 指数级增长到 2MB。
• 大幅减少系统调用次数，充分利用 SSD 的顺序读带宽。
• 在 Linux 下，底层协同调用 readahead 系统调用，利用 Page Cache 机制。

RocksDB 顺序 Scan 代码：

#include <rocksdb/db.h>
#include <rocksdb/options.h>
#include <rocksdb/slice.h>
#include <iostream>
int main() {
    rocksdb::DB* db;
    rocksdb::Options options;
    options.create_if_missing = true;
    rocksdb::Status s = rocksdb::DB::Open(options, "/tmp/rocksdb_test", &db);
    if (!s.ok()) {
        std::cerr << s.ToString() << std::endl;
        return -1;
    }
    // 写入顺序数据
    for (int i = 0; i < 1000000; ++i) {
        db->Put(rocksdb::WriteOptions(), "key" + std::to_string(i), std::string(1024, 'A'));
    }
    // 顺序 Scan
    rocksdb::ReadOptions ro;
    ro.fill_cache = false; // 强制走 I/O 路径
    auto it = db->NewIterator(ro);
    for (it->SeekToFirst(); it->Valid(); it->Next()) {
        // 只访问，不处理
    }
    delete it;
    delete db;
    return 0;
}

3.2 LSM-Tree 的多线程并发 Compaction

Compaction 是 LSM-Tree 最消耗性能的操作。在鲲鹏 128 核环境下，单线程 Compaction 极易成为瓶颈。

3.2.1 Sub-compaction 并行化

推荐开启 Sub-compaction，将一个大 Compaction 拆分为多个小任务并行执行。

void CompactionJob::GenSubcompactionBoundaries() {
    // 1. 采样：对每个输入文件获取锚点 (Anchor Points)
    // 2. 排序与去重：汇总所有锚点
    // 3. 划分：根据总数据量和目标分片数，计算边界 Key
    // ...
}

RocksDB 通过采样 SST 文件中的 Key 分布，智能地计算出拆分边界，确保多个线程负载均衡。

多线程 Sub-Compaction 实战代码：

rocksdb::Options options;
options.create_if_missing = true;
// 开启并行 Compaction
options.max_background_jobs = 32;
options.max_subcompactions = 16; // 写放大明显的参数
options.level0_file_num_compaction_trigger = 4;
options.write_buffer_size = 64 * 1024 * 1024;

3.3 鲲鹏亲和性调优 (NUMA)

鲲鹏 920 采用多 NUMA 节点设计。跨 NUMA 访问内存会带来显著延迟。

• 策略：通过 numactl 绑定进程，并配置 options.max_background_compactions 充分利用本地 NUMA 节点的 CPU 核心。

4. 并发与缓存：多核架构下的锁竞争消除

在 64 核甚至 128 核的高并发场景下，锁竞争（Lock Contention）是性能杀手。本章介绍 RocksDB 的无锁化设计。

4.1 无锁并发 MemTable

MemTable 的写入通常需要加锁。BoostKit RocksDB 利用 InlineSkipList 实现了无锁并发写入。

4.1.1 CAS 实现 (memtable/inlineskiplist.h)

template <bool UseCAS> bool InlineSkipList<Comparator>::Insert(...) {
    if (UseCAS) {
        while (true) {
            // 核心逻辑：使用 CAS 更新 next 指针
            if (splice->prev_[i]->CASNext(i, splice->next_[i], x)) {
                break; // 插入成功
            }
            // CAS 失败，重试
        }
    }
}

通过 ARM64 的 CAS 或 LDXR/STXR 指令，多个线程可以并发修改 SkipList 的指针，彻底消除了写入互斥锁。

4.1.2 开启配置

options.allow_concurrent_memtable_write = true;
options.enable_pipelined_write = true;

4.2 Block Cache 的分片 (Sharding)

全局唯一的 LRU Cache 锁在大并发下会成为热点。

4.2.1 源码解读 (cache/sharded_cache.cc)

RocksDB 将缓存划分为多个 Shard（分片），每个 Shard 有独立的锁。

// 根据 Key 的 Hash 值定位 Shard
int shard_id = Shard(hash);
return shards_[shard_id]->Insert(key, hash, value, ...);

4.2.2 调优建议

在鲲鹏服务器上，建议将分片数设置为 64 (2^6)：

// num_shard_bits = 6
std::shared_ptr<Cache> cache = NewLRUCache(capacity, -1, false, 0.5, nullptr, 6);

5. 总结

BoostKit for RocksDB 并不是对参数做简单调优，而是深入 ARM64 与鲲鹏处理器特性的系统级优化。

在计算侧，通过 CRC32C 三路并行、PMULL 指令和硬件预取，充分释放鲲鹏 CPU 的指令级并行能力；通过 KAE 硬件压缩，将原本占用大量 CPU 的压缩计算卸载到专用加速引擎，实现更高吞吐与更低 CPU 开销。

在 I/O 与存储引擎层面，借助 自适应预取、并行 Sub-Compaction、NUMA 亲和性绑定，显著提升了 LSM-Tree 在大核数 ARM 服务器上的扩展性。

在并发与缓存设计上，通过 无锁 MemTable 和分片 Block Cache，有效消除了多核场景下的锁竞争问题。

总体来看，BoostKit 通过 指令级优化 + 硬件加速 + 架构感知设计，让 RocksDB 在鲲鹏平台上不仅'能跑'，而且'跑得快、跑得稳'，为 ARM64 服务器承载高性能存储与数据库负载提供了成熟可落地的解决方案。