CEPH VERSION： Quincy 17.2.6
-
事务生命周期
BlueStore事务状态.png
需要注意，这个状态机是属于一个BlueStore::TransContext的，或者称为BlueStore事务状态机，很多网文将其称为BlueStore状态机，我认为是不妥当的，不够准确易引起误解。
此状态机由上层提交线程、kv_sync_thread、kv_finalize_thread以及BDEV的aio收割线程配合驱动，线程间的切换点，通常存在一个队列，从而形成工作流水线。这种设计，对于IO延迟有一定的损耗，更侧重于整体的吞吐能力。
-
part1： 上层工作线程
第一个线程是PG层的线程，它们可能是OSD的工作线程。对于BlueStore而言，我将他们称为上层工作线程，其工作流程如下：
BlueStore线程协作1_上层工作线程.png
工作线程终结点有三个：
- 当事务中包含对bdev的aio时，工作线程将aio提交给bdev后结束，不做等待。NVMEDevice例外，它的io提交和io_completion都由工作线程完成。
- 当前事务不包含aio（或者是NVMEDevice回调令当前事务处于STATE_IO_DONE），但同pg的前序aio尚未达到STATE_IO_DONE，则事务驻留在osr中，线程不做等待即返回。
- 当前事务不包含aio（或者是NVMEDevice回调令当前事务处于STATE_IO_DONE），同pg的前序aio也都至少达到了STATE_IO_DONE状态，那么会将osr中本事务以及前序所有的STATE_IO_DONE状态事务依先后顺序提交至kv_queue。若打开了bluestore_sync_submit_transaction这个配置项，还会将这些事务向DB提交（非sync提交），未向DB提交的事务，还会被放入kv_queue_unsubmitted
综上，工作线程结束时，当前的事务可能处于bdev的aio队列、Collection的osr队列、kv_queue队列和kv_queue_unsubmitted队列中。
工作线程总是尽可能在不阻塞的情况下完成更多的事情，并不急于切换线程。即使打开了
bluestore_sync_submit_transaction配置，工作线程也只是向DB做非sync的提交，这可以避免rocksdb底层发生fsync操作，也就尽量避免了阻塞的发生。这样的设计，最大化的节约了线程数量，最小化线程切换开销，也让工作线程尽可能快的结束转而为上层新的IO服务。
工作线程可能的阻塞点还是有的，就是入口处的限流，当限流被触发时，工作线程会陷入条件等待直至有足够的限流配额，这里多个线程是排队等，配额是先到先得。那么当限流触发时，可能阻塞住多个上层工作线程，阻塞就会反馈至OSD层，让上层以更慢的速度下发事务。所以这里的阻塞是合适的，否则上下层速率不匹配，可能导致下层队列严重堆积，增加内存开销同时让系统性能表现不能平滑。
part2：aio收割线程
第二个线程是bdev的aio收割线程，KernelDevice(libaio)和NVMEDevice(spdk)的收割会不太一样，NVMEDevice没有专门的收割线程，它将提交线程和收割线程合二为一，提交线程会循环polling直至Ioc中的io全部完成并执行其io_completion回调。从执行回调开始，各种bdev工作流程类似，都是从各自完成的op获得aio_t结构，通过aio_t->priv指针获得IOContext ioc，再从ioc->priv 获得txc(前文有描述aio_t相关结构)，然后执行bdev对象创建时注册的回调函数aio_cb，来继续驱动事务状态流转
同样的，aio收割线程也是不阻塞的执行。事务最后的归宿剩下两个地方：osr队列或者kv_queue 和kv_queue_unsubmitted。osr队列中的事务终将被上层工作线程或者aio收割线程给冲刷到kv_queue和kv_queue_unsubmitted中。那么，接下来的接盘侠就是kv_sync_thread了，它又做了些什么事情呢？
-
part3：kv_sync_thread
第三个线程，BlueStore的kv_sync_thread
BlueStore线程协作3_kv_sync线程.png
经过kv_sync_thread处理以后，kv事务被提交，txc状态被置为STATE_KV_SUBMITTED，这些txc被集中到kv_committing_to_finalize队列，等待kv_finalize线程处理；deferred_done的事务在经过bdev->flush()或者db->submit_transaction_sync(synct)操作后，变成deferred_stable，它们被集中到deferred_stable_to_finalize，等待kv_finalize线程处理。
-
part4：kv_finalize_thread
第四个线程，BlueStore的kv_finalize_thread
BlueStore线程协作4_kv_finalize线程.png
简单总结，kv_finalize_thread处理kv_committing_to_finalize队列，对于其中没有deferred_txn的事务，执行清理流程，对于有deferred_txn的事务，将其排队到对应osr的deferred_pending（这是一个DeferredBatch）,并在有足够的积压且无deferred_running的时机，做一次deferred_pending的合并提交(aio_submit)。两种情况下，都会将txc的oncommits回调交给Finisher线程的队列，Finisher可以执行回调来通知客户端了。
对于deferred_stable队列的处理就比较简单，走Finish流程做对象析构即可。
需要注意的是，DeferredBatch是另一种AioContext，它的aio_finish流程不同于TransContext(txc)，DeferredBatch的aio_finish也是被bdev的aio收割线程来执行的，其过程较为简单，将对应的txc投入到deferred_done_queue，而后被kv_sync_thread接收处理，进入deferred_stable队列，而后被kv_finalize_thread接着处理完成。
-
part5：Finisher线程
Finisher不断执行queue中Context的complete函数，具体过程由事务附带的oncommit回调实现来决定。
下一篇继续深入一个重要的细节，设备空间分配和空闲空间管理。
