Pika flushdb 改进

[AlexStocks]

记录针对Issue #2708 的修复讨论

[cheniujh]

问题简述：因为Slave端消费Binlog线程模型的缘故，原有代码中主从执行flushdb后可能出现主从不一致的现象

背景：Pika Slave在消费一条Binlog时，按事件顺序分为两步，一是Apply Binlog, 也就是将收到的Binlog也追加到自己的BinlogFile中，二是Apply DB, 也即将Binlog中抽取出来的命令写DB。具体地，Slave收到的所有Binlog都会顺序提交到一个固定的Binlog-Worker线程去消费，
在Binlog-Worker线程上，会原地完成Apply Binlog的动作（同步地追加Binlog），之后会向另外一个WriteDBWorker线程池提交一个异步的WriteDB任务（按key来分配使用池子里的哪一个DBworker）。长话短说就是：写Binlog的动作是单线程同步完成的，而写完Binlog之后，从Binlog中提取的WriteDB任务是提交到另一个线程池异步并发做的。

Case举例：

Pika的Slave在apply完binlog后，将binlog所对应的WriteDB任务分发给多个线程处理，分配时采用按key hash的方式取线程。
flushdb是一个会写binlog，却没有key的命令，每次都会固定取某个线程来执行ApplyDB/写DB的操作。
考虑这样一个case：
主节点实际落盘的顺序（同时也是Binlog的顺序）是：

1. set key1 a1
2. set key1 a2
3. flushdb
4. set key1 a3
   主节点执行完上述操作，主实际写DB的顺序是1， 2， 3， 4。 最后DB的状态是：有一个pair为：{key1, a3}

但从节点在Apply完Binlog之后，会将这4条命令提交到WriteDBWorker线程池中的不同线程（按key做hash来分配，flushdb没有key，所以直接用的”flushdb“这个string来做hash），以下就是一种很有可能的分配结果:

WriteDBWorkerThread1执行：set key a1; set key1 a2; set key1 a3;
WriteDBWorkerThread2执行：flushdb

假如因为线程调度原因，thread1先执行完了这3个set，thread2才去执行flushdb, 那从节点实际落盘的顺序就是1, 2, 4, 3, 和主节点的落盘顺序不一致，进而导致主从不一致：flushdb是最后执行的（但实际上flushdb应该发生于set key1 a3命令之前），会导致整个从库DB是空的。但是按照正确预期, 主从应该一致，从库也应当有key1，值为a3。

这个case中flushdb被延后执行了，还有另一种正好相反的case：flushdb被提前执行了，就会出现主节点为空，从节点上却有数据的情况，性质和上述case几乎一样，就不具体阐述了。

解决方案：

• 必须确保flushdb命令之后的Binlog一定在flushdb执行完之后才被消费。具体变动为：消费flushdb的Binlog时，将写Binlog以及WriteDB两个操作都放在WriteBinlogWorker上同步执行（原本是只有写Binlog任务在这里同步执行，WriteDB任务被分发到DBWorker线程池），说白了就是flushdb特殊化一下，WriteDB的动作从异步改为同步。修改之后：能确保位于flushdb命令之后的Binlog不可能在flushdb执行完毕之前被提交到异步的DBWorker池子里，也就不可能会比flushdb更早执行。

• 必须确保flushdb命令在真正执行之前，位于flushdb之前的所有WriteDB任务都已经完成了（操作已经写入RocksDB, 而不是还在某个WriteDBWorker的任务队列中排队）。具体变动为：在BinlogWorker上新增一个提交计数/正在异步执行的WriteDB任务的计数。每次BinlogWorker向WriteDBWorker池子中提交WriteDB任务时，都对这个计数加1，每当有相应的WriteDB任务完成，都对这个计数减1（加一个回调函数即可）。在消费到flushdb的binlog，需要在BinlogWorker上将flushdb进行同步地WriteDB前，需要先检查这个任务计数是否为0，如果不为0，就sleep一会（等待前面的异步WriteDB任务被执行完），再次检查该计数，一直等到该任务计数归0，才去原地将flushdb的操作apply到DB。（为什么这个任务计数一定能等到归0：这个任务计数只有在BinlogWorker向WriteDBWorker池子异步提交任务时才会做自增，而这里的sleep等待实际上就是BinlogWorker在等待，换而言之，在这条同步消费的flushdb完全完成之前，下一条Binlog都不会被消费，也不会有任何的WriteDB任务被提交到WriteDBWoker的池子）。修改之后: 能确保flushdb之前的Binlog所对应的WriteDB任务一定都执行完了，才会执行flushdb，能避免出现：执行完flushdb之后（即写了binlog，也已经清空了DB），滞留在WriteDBWorker队列中的WriteDB任务才执行（即先于flushdb的命令在flushdb之后才执行)。

[AlexStocks]

相关 PR #2808