这两天重新理了一下Rocksdb的写入逻辑，其中所涉及的细节和优化相当的多。刚好趁着周末时间，将这块代码进行了场景分类并画了各种场景下的处理逻辑和线程交互时序图，这里简单记录一下，也希望能够帮助正在读这块代码的大家更好的理解其实现原理。
RocksDB的key/value写入存在多种场景，本人根据代码以及自己的理解将其分为：unordered write、pipelined write以及常规写入。其中对于pipelined write和常规写入场景，在写memtable阶段又可以分为parallel memtable write和非parallel memtable write。
下面简单分析各种场景的区别以及各种场景下写入线程的执行和交互时序：
1 首先是常规写入场景：在该写入场景下，线程调用JoinBatchGroup加入到Write Thread，在Write Thread上任一时刻只有一个线程成为leader，该leader线程会构造一个write group，write group内除了了leader自身还有若干follower。leader主要负责执行写入前的一系列预处理工作以及负责将group内所有writer的WAL持久化。然后根据是否允许parallel memtable写入，负责执行group内所有writer的memtable写入工作或者只将自己writer的memtable写入即可。该场景下，只有当group内的WAL持久化以及memtable写入都执行完毕之后才会唤醒Write Thread上的一个新leader来继续执行后面的pending写入。
1.1 常规写入处理逻辑图：
1.2 常规写入-非parallel memtable write场景下，一个write group内的线程执行和交互时序图：
该场景下，由group的leader完成WAL持久化以及将group内所有writer的数据写入到memtable中，最后唤醒follower返回即可。
1.3 常规写入-parallel memtable write场景下，一个write group内的线程执行和交互时序图：
该场景下，group的leader完成WAL持久化之后唤醒所有follower执行各自的memtable写入，leader则负责执行自己的memtable写入。
2 pipelined write场景：通过上面的常规写入处理逻辑，可以发现只有当一个group的WAL持久化以及memtable写入都完成之后，才会唤醒下一个新leader来执行新一轮的写入。那么是否可以实现当一个group内完成WAL持久化之后，立即唤醒下一个新leader来执行新一轮的WAL持久化，而这个group的memtable写入则并行的执行。答案是可以的，就是pipelined write，而pipelined的含义就是WAL持久化和memtable 写入流水线的执行（当然是指旧group的memtable写入和新group的WAL持久化）。
2.1 pipelined write处理逻辑图：
2.2 pipelined write-非parallel memtable write场景下，一个write group内的线程执行和交互时序图：
2.3 pipelined write-parallel memtable write场景下，一个write group内的线程执行和交互时序图：
总结
以上的逻辑图和时序图都相当清晰的缕清了各种写入场景，后面会深入的分析leader线程在写WAL之前预处理工作以及对应的原因分析。