这次天池中间件性能大赛初赛和复赛的成绩都正好是第五名，本次整理了复赛《单机百万消息队列的存储设计》的思路方案分享给大家，实现方案上也是决赛队伍中相对比较特别的。
赛题回顾
实现一个进程内的队列引擎，单机可支持100万队列以上。
实现消息put、get接口。
在规定时间内完成数据发送、索引校检、数据消费三个阶段评测。
评测逻辑
各个阶段线程数在20~30左右。
发送阶段：消息大小在50字节左右，消息条数在20亿条左右，也即发送总数据在100G左右。
索引校验阶段：会对所有队列的索引进行随机校验；平均每个队列会校验1~2次。
顺序消费阶段：挑选20%的队列进行全部读取和校验；
发送阶段最大耗时不能超过1800s；索引校验阶段和顺序消费阶段加在一起，最大耗时也不能超过1800s；超时会被判断为评测失败。
评测环境
测试环境为4c8g的ECS虚拟机。
带一块300G左右大小的SSD磁盘。SSD性能大致如下：iops 1w左右；块读写能力(一次读写4K以上)在200MB/s左右。
赛题分析
对于单机几百的大队列来说业务已有成熟的方案，Kafka和RocketMQ。
方案 几百个大队列
Kafka 每个队列一个文件（独立存储）
RocketMQ 所有队列共用一个文件（混合存储）
若直接采用现有的方案，在百万量级的小队列场景都有极大的弊端。
方案 百万队列场景弊端
Kafka独立存储 单个小队列数据量少，批量化程度完全取决于内存大小，落盘时间长，写数据容易触发IOPS瓶颈
RocketMQ混合存储 随机读严重，一个块中连续数据很低，读速度很慢，消费速度完全受限于IOPS
为了兼顾读写速度，我们最终采用了折中的设计方案：多个队列merge，共享一个块存储。
设计核心思想
设计上要支持边写边读
多个队列需要合并处理
单个队列的数据存储部分连续
索引稀疏，尽可能常驻内存
架构设计
架构图中Bucket Manager和Group Manager分别对百万队列进行分桶以及合并管理，然后左右两边是分别是写模块和读模块，数据写入包括队列merge处理，消息块落盘。读模块包括索引管理和读缓存。（见左图）
bucket、group、queue的关系：对消息队列进行bucket处理，每个bucket包含多个group，group是我们进行队列merge的最小单元，每个group管理固定数量的队列。（见右图）
存储设计
对百万队列进行分桶处理。
每个Bucket中分为多个Group，每个Group为一个读写单位，对队列进行merge，同时更新索引和数据文件。
单个Group里对M个队列进行合并，超过16k或者压缩超过16K（可配置）进行索引更新和落盘。
索引部分针对每个Block块建立一个L2二级索引，然后每16个L2建立一个L1一级索引。
数据文件采用混合存储，对Block块顺序存储。
接下来对整个存储每个阶段的细节进行展开分析，包括队列合并、索引管理和数据落盘。
MQ Merge
-
百万队列数据Bucket Hash分桶
-
Bucket视角
每个Bucket分配多个Group
Group是管理多个队列的最小单位
- Group分配过程
每个bucket持有一把锁，顺序为队列分配group，这里我们假设merge的数量为4个队列。
数据的达到是随机的，根据队列的先后顺序加入当前Group。
当Group达到M个后便形成一个固定分组。相同队列会在Group内进行合并，新的队列数据将继续分配Group接收。
- Group视角的数据写入
每个Group会分配Memtable的Block块用于实时写入。
当Block达到16k（可配置）时以队列为单位进行数据排序，保证单个队列数据连续。
字节对齐，Memtable变为不可变的Immemtable准备落盘。
开辟新的Block接收数据写入。
索引管理
-
L2二级索引
L2二级索引与数据存储的位置息息相关，见下图。为每个排序后的Block块建立一个L2索引，L2索引的结构分为文件偏移(file offset)，数据压缩大小(size)，原始大小(raw size)，因为我们是多个队列merge，然后接下来是每个队列相对于起始位置的delta offset以及消息数量。 -
L1一级索引
为了加快查询速度，在L2基础上建立L1一级索引，每16个L2建立一个L1，L1按照时间先后顺序存放。L1和L2的组织关系如下：
L1索引的结构非常简单，file id对应消息存储的文件id，以及16个Block块中每个队列消息的起始序列号seq num。例如MQ1从序列号1000开始，MQ2从序列号2000开始等等。
- Index Query
如何根据索引定位需要查找的数据？
对L1先进行二分查找，定位到上下界范围，然后对范围内的所有L2进行顺序遍历。
Data Flush
- 同步Flush
当blcok超过指定大小后，根据桶的hashcode再进行一次mask操作将group中的队列数据同步写入到m个文件中。
同步刷盘主要尝试了两种方案：Nio和Dio。Dio大约性能比Nio提升约5%。CPP使用DIO是非常方便的，然而作为Java Coder你也许是第一次听说DIO，在Java中并没有提供直接使用DIO的接口，可以通过JNA的方式调用。
DIO（DIRECT IO，直接IO），出于对系统cache和调度策略的不满，用户自己在应用层定制自己的文件读写。DIO最大的优点就是能够减少OS内核缓冲区和应用程序地址空间的数据拷贝次数，降低文件读写时的CPU开销以及内存的占用。然而DIO的缺陷也很明显，DIO在数据读取时会造成磁盘大量的IO，它并没有缓冲IO从PageCache获取数据的优势。
这里就遇到一个问题，同样配置的阿里云机器测试随机数据同步写入性能是非常高的，但是线上的评测数据都是58字节，数据过于规整导致同一时间落盘的概率很大，出现了大量的锁竞争。所以这里做了一个小的改进：按概率随机4K、8K、16K进行落盘，写性能虽有一定提升，但是效果也是不太理想，于是采用了第二种思路异步刷盘。
- 异步Flush
采用RingBuffer接收block块，使用AIO对多个block块进行Batch刷盘，减少IO Copy的次数。异步刷盘写性能有了显著的提升。
以下是异步Flush的核心代码：
while (gWriterThread) {
if (taskQueue->pop(task)) {
writer->mWriting.store(true);
do {
// 使用异步IO
aiocb *pAiocb = aiocb_list[aio_size++];
memset(pAiocb, 0, sizeof(aiocb));
pAiocb->aio_lio_opcode = LIO_WRITE;
pAiocb->aio_buf = task.mWriteCache.mCache;
pAiocb->aio_nbytes = task.mWriteCache.mSize;
pAiocb->aio_offset = task.mWriteCache.mStartOffset;
pAiocb->aio_fildes = task.mBlockFile->mFd;
pAiocb->aio_sigevent.sigev_value.sival_ptr = task.mBlockFile;
task.mBlockFile->mWriting = true;
if (aio_size >= MAX_AIO_TASK_COUNT) {
break;
}
} while (taskQueue->pop(task));
if (aio_size > 0) {
if (0 != lio_listio(LIO_WAIT, aiocb_list, aio_size, NULL)) {
aos_fatal_log("aio error %d %s.", errno, strerror(errno));
}
for (int i = 0; i < aio_size; ++i) {
((BlockFile *) aiocb_list[i]->aio_sigevent.sigev_value.sival_ptr)->mWriting = false;
free((void *) aiocb_list[i]->aio_buf);
}
aio_size = 0;
}
} else {
++waitCount;
sched_yield();
if (waitCount > 100000) {
usleep(10000);
}
}
}
读缓存设计
数据读取流程
根据队列Hash定位Bucket桶。
二分查找定位L1索引和L2索引。
在一定时机会执行预读取操作。
数据先从缓存中做查找，缓存命中直接返回，失效则回源到SSD。
整个流程主要有两个优化点：预读取和读缓存。
预读取优化
- 记录上一次读取（消费）的offset
主要有两个作用：
加快查询数据的速度。
用于判断预读取时机。
- 预读取时机
顺序消费且已经消费到当前block尾，则进行预读取操作。如何判断顺序消费？判断上次消费的结束位置是否与这次消费的起始位置相等。
if (msgCount >= destCount) {
if (mLastGetSequeneNum == offsetCount &&
beginIndex + 1 < mL2IndexCount &&
beginOffsetCount + blockIndex.mMsgDeltaIndexCount <= offsetCount + msgCount + msgCount) {
MessageBlockIndex &nextIndex = mL2IndexArray[beginIndex + 1];
// 预读取
#ifdef __linux__
readahead(pManager->GetFd(hash), nextIndex.mFileOffset, PER_BLOCK_SIZE);
#endif
}
mLastGetSequeneNum = offsetCount + msgCount;
return msgCount;
}
Read Cache
关于read cache做了一些精巧的小设计，保证足够简单高效。
分桶（部分隔离），一定程度缓解缓存饿死现象。
数组 + 自旋锁 + 原子变量实现了一个循环分配缓存块的方案。
双向指针绑定高效定位缓存节点。
-
Read Cache全貌
Read Cache一共分为N=64（可配）个Bucket，每个Bucket中包含M=3200（可配）个缓存块，大概总计20w左右的缓存块，每个是4k，大约占用800M的内存空间。 -
核心数据结构
关于缓存的核心数据结构，我们并没有从队列的角度出发，而是针对L2索引和缓存块进行了绑定，这里设计了一个双向指针。判断缓存是否有效的核心思路：check双向指针是否相等。
CacheItem cachedItem = (CacheItem *) index->mCache;
cachedItem->mIndexPtr == (void *) index;
3. 算法实现
3.1 Bucket分桶
获取L2 Index。
根据Manager Hash % N，找到对应的缓存Bucket。
L2还没有对应缓存块，需要进行缓存块分配。
3.2 Alloc Cache Block
原子变量进行自加操作，同时对M=3200块取模， count.fetch_add(1) % M = index
分配下标为index的Cache Block。
然后将对应的缓存块和我们的队列的L2索引进行双向指针绑定，同时对缓存块数据进行数据填充。
3.3 Cache Hit
index->mCache == index->mCache->index，双向指针相等，缓存命中，然后做数据读取。
3.4 Cache Page Replace
MQ1绑定的缓存块已经被MQ2替换。
index->mCache != index->mCache->index，双向指针已经不相等，缓存失效。需要为MQ1分配新的缓存块。
原子变量进行自加操作，同时对M=3200块取模， 例如：count.fetch_add(1) % M = M-1，找到新的缓存块进行重新绑定。说明：整个分配的逻辑是一个循环使用的过程，当所有的缓存桶都被使用，那么会从数组首地址开始重新分配、替换。
- Read Cache & LRU & PageCache 对比
开始我们尝试了两种读缓存方案：最简单的LRU缓存和直接使用PageCache读取。PageCache所实现的其实是高级版的LRU缓存。在顺序读的场景下，我们自己实现的读缓存（Cycle Cache Allocate，暂简称为CCA）与LRU、PageCache的优劣分析对比如下：
LRU针对每次操作进行调整，CCA针对缓存块需要分配时进行替换。
LRU从队列角度建立映射表，CCA针对索引和缓存块双向指针绑定。
CCA中自旋锁是针对每个缓存块加锁，锁粒度更小。LRU需要对整个链表加锁。
达到同等命中率的情况下，CCA比Page Cache节省至少1~2倍的内存。
总结
创新点
针对百万小队列，实际硬件资源，兼顾读写性能，提出多队列Merge，保证队列局部连续的存储方式。
针对队列相对无关性及MQ连续读取的场景，设计实现了O(1)的Read Cache，只需要约800M内存即可支持20W队列的高效率的读取，命中率高达85%。
支持多队列Merge的索引存储方案，资源利用率低，约300~400MB索引即可支撑百万队列、100GB数据量高并发读写。