📚 课程目录第4章内存参数调优

4. 内存参数调优：Block Cache、Write Buffer Manager、MemTable 大小与数量的最佳实践

内存调优，说白了就是跟 RocksDB 抢内存。你想想看，Flink 的 TaskManager 内存就那么大一块，State Backend 要分，网络缓冲要分，用户代码也要分。分不好，要么 OOM，要么性能稀烂。

我个人习惯，调内存参数前先画一张图，把每块内存的流向搞清楚。咱们先看这张整体架构图，再逐个击破。

4.1 Block Cache：读性能的命门

Block Cache 缓存的是 SST 文件中解压后的数据块。读请求先查 Block Cache，命中就直接返回，不用走磁盘。命中率低了，读延迟会飙升。

我记得有一次线上作业，状态访问量特别大，读延迟从 2ms 涨到 50ms。查了半天，发现 Block Cache 只有默认的 8MB。你想想看，8MB 能缓存几条数据？稍微大一点的状态，一次全量遍历就把缓存冲没了。

核心参数：

state.backend.rocksdb.block.cache-size — 设置 Block Cache 大小
state.backend.rocksdb.block.cache-type — LRU 或 Clock 算法

我的建议：

读密集型作业：Block Cache 占总内存预算的 60%~70%。比如总预算 4GB，Block Cache 给 2.5GB~2.8GB。
写密集型作业：Block Cache 可以压缩到 30%~40%，把更多内存留给 Write Buffer。
最小值不要低于 256MB。低于这个值，缓存基本形同虚设。

小技巧： 可以通过 RocksDB 的 rocksdb.block.cache.hit.ratio 监控指标观察命中率。如果命中率低于 80%，说明 Block Cache 太小了。如果高于 95%，可以考虑适当缩小，把内存让给 Write Buffer。

4.2 Write Buffer Manager：内存的守门员

Write Buffer Manager 是 RocksDB 6.x 引入的机制。它的作用很简单：限制所有 MemTable 的总内存上限。超过这个上限，强制触发 flush，把 MemTable 刷成 SST 文件。

没有 Write Buffer Manager 的时候，每个 Column Family 各自为政。我曾经遇到过一个场景，作业有 50 个 Column Family，每个 MemTable 默认 64MB，理论上最多占用 3.2GB。但实际因为写入速度不均衡，某些 Column Family 的 MemTable 还没来得及 flush，新的又写进来了，内存直接飙到 6GB，TaskManager 被 YARN kill 了。

避坑指南： 不要依赖单个 MemTable 的大小限制来控制总内存。多个 Column Family 叠加起来，内存会失控。Write Buffer Manager 是必须开启的。

配置方式：

// 通过 Flink 配置开启
state.backend.rocksdb.write-buffer-manager: true
state.backend.rocksdb.write-buffer-manager.buffer-size: 2GB

// 或者在代码中自定义
RocksDBOptionsFactory factory = new DefaultConfigurableOptionsFactory();
Map<String, String> conf = new HashMap<>();
conf.put("write_buffer_manager", "2GB");
// 设置到 Configuration 中

大小建议：

Write Buffer Manager 的总大小 = MemTable 数量 × 单个 MemTable 大小 × 1.5（给 Immutable MemTable 留余量）。
举个例子：你有 10 个 Column Family，每个 Column Family 有 2 个 MemTable（1 个 active + 1 个 immutable），单个大小 128MB。那么总内存需求 = 10 × 2 × 128MB = 2.5GB。Write Buffer Manager 可以设到 3GB~4GB。

4.3 MemTable 大小与数量：吞吐量的调节阀

MemTable 是 RocksDB 的写入缓冲区。数据先写到 MemTable，满了之后变成 Immutable MemTable，然后后台线程 flush 到磁盘。

关键参数：

参数	默认值	作用	我的推荐
`write_buffer_size`	64 MB	单个 MemTable 的大小	128 MB ~ 256 MB
`max_write_buffer_number`	2	最大 MemTable 数量（含 active 和 immutable）	4 ~ 6
`min_write_buffer_number_to_merge`	1	触发 flush 前最少合并的 MemTable 数量	2

调优逻辑：

写吞吐量高： 增大 write_buffer_size 到 256MB，减少 flush 频率。但注意，单个 MemTable 太大，flush 时 IO 压力会集中。
写延迟敏感： 增大 max_write_buffer_number 到 4~6。这样即使 flush 慢，新的写入还能继续，不会阻塞。
读性能优先： 设置 min_write_buffer_number_to_merge 为 2。合并后再 flush，减少 SST 文件数量，降低读放大。

一个实际案例：

我之前调优过一个双十一大促作业，状态写入量巨大。默认配置下，每秒钟 flush 几十次，IO 打满，写入延迟抖动到 200ms。

我的调整：

write_buffer_size 从 64MB 调到 256MB
max_write_buffer_number 从 2 调到 6
min_write_buffer_number_to_merge 设为 2

结果：flush 频率降到每秒 3~5 次，写入延迟稳定在 5ms 以内。代价是内存多了 1.5GB，但完全值得。

4.4 三者的协同配置

Block Cache、Write Buffer Manager、MemTable 不是孤立的。它们共享 RocksDB 的总内存预算。我一般按这个步骤来配：

确定总预算： 从 TaskManager 内存中划出 30%~40% 给 RocksDB。比如 TaskManager 有 16GB 堆外内存，RocksDB 拿 5GB~6GB。
分配 Write Buffer： 总预算的 30%~50% 给 Write Buffer Manager。5GB 预算的话，Write Buffer 给 1.5GB~2.5GB。
分配 Block Cache： 剩下的都给 Block Cache。如果读多写少，可以多给 Block Cache，反之少给。
微调 MemTable 参数： 根据 Column Family 数量和写入模式，调整 write_buffer_size 和 max_write_buffer_number，确保总内存不超过 Write Buffer Manager 的限制。

一个快速检查公式：

总内存预算 ≥ (num_column_families × max_write_buffer_number × write_buffer_size) × 1.2 + block_cache_size

如果左边大于右边，说明内存够用。如果左边小于右边，要么减少 Column Family 数量，要么缩小 MemTable 大小。

嗯，到这里内存参数的核心逻辑就讲完了。记住一句话：Block Cache 管读，Write Buffer 管控总量，MemTable 管写吞吐。三者平衡好了，RocksDB 状态后端才能跑得又快又稳。