【RocksDB 内核机制】生产嵌入对照：Flink · TiKV · Kafka Streams
内容提要
本文讨论了Flink中EmbeddedRocksDBStateBackend的机制，重点在于KeyGroup前缀、增量checkpoint的实现及其与RocksDB的关系。增量checkpoint依赖于不可变SST文件和MANIFEST，以确保数据一致性。文章还比较了Flink、TiKV和Kafka Streams在状态管理和容错机制上的差异，强调了设计与参数调优的重要性。
延伸解读
增量Checkpoint的关键机制
增量Checkpoint依赖于不可变的SST文件和MANIFEST，以确保数据一致性。Flush操作是生成不可变SST的前提，只有在Flush后，Checkpoint才能正确上传增量数据。这一机制对于维护系统的稳定性和性能至关重要，尤其是在高负载情况下。
Flink与其他系统的比较
Flink、TiKV和Kafka Streams在状态管理和容错机制上存在显著差异。Flink采用每个subtask独立的RocksDB实例，而TiKV和Kafka Streams则在DB实例边界和CF划分上有所不同。这种设计差异影响了系统的扩展性和容错能力，开发者在选择时需考虑具体应用场景。
KeyGroup前缀的重要性
KeyGroup前缀在Flink的RocksDB内部排序中起着关键作用。它决定了key的排序区间，并在Rescale过程中确保状态的正确迁移。理解这一机制有助于优化状态管理和提高系统的性能，特别是在处理大规模数据时。
Q&A
Flink中的EmbeddedRocksDBStateBackend是如何工作的？
EmbeddedRocksDBStateBackend为每个subtask打开独立的RocksDB，每种注册状态对应一个Column Family，使用KeyGroup前缀决定key的排序区间。
增量checkpoint在Flink中是如何实现的？
增量checkpoint依赖于不可变的SST文件和MANIFEST，上传自上次完成的checkpoint以来新增的SST，并通过Flush操作确保数据一致性。
Flink、TiKV和Kafka Streams在状态管理上有什么不同？
Flink每个subtask对应一个独立的DB实例，而TiKV和Kafka Streams则在不同的边界和CF划分上存在差异，特别是在容错日志的处理上。
KeyGroup前缀在Flink中有什么重要性？
KeyGroup前缀决定了key的排序区间，在Rescale时必须保留该前缀，以确保状态的正确迁移。
Compaction如何影响Flink的shared state引用链？
Compaction会合并SST文件，影响Flink的shared state引用链，导致checkpoint争抢磁盘I/O。
在Flink中，如何确保增量checkpoint的数据一致性？
通过Flush操作生成不可变的SST文件，并在MANIFEST中记录新文件，确保数据在checkpoint过程中的一致性。
