天池中间件大赛——单机百万消息队列存储分享

时间 2019-12-16

标签天池中间件大赛单机百万消息队列存储分享繁體版

原文原文链接

此次天池中间件性能大赛初赛和复赛的成绩都正好是第五名，本次整理了复赛《单机百万消息队列的存储设计》的思路方案分享给你们，实现方案上也是决赛队伍中相对比较特别的。linux

赛题回顾

实现一个进程内的队列引擎，单机可支持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处理，消息块落盘。读模块包括索引管理和读缓存。（见左图）bash

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

1. 百万队列数据Bucket Hash分桶

2. Bucket视角

每一个Bucket分配多个Group
Group是管理多个队列的最小单位

3. Group分配过程

每一个bucket持有一把锁，顺序为队列分配group，这里咱们假设merge的数量为4个队列。
数据的达到是随机的，根据队列的前后顺序加入当前Group。
当Group达到M个后便造成一个固定分组。相同队列会在Group内进行合并，新的队列数据将继续分配Group接收。

4. Group视角的数据写入

每一个Group会分配Memtable的Block块用于实时写入。
当Block达到16k（可配置）时以队列为单位进行数据排序，保证单个队列数据连续。
字节对齐，Memtable变为不可变的Immemtable准备落盘。
开辟新的Block接收数据写入。

索引管理

1. L2二级索引

L2二级索引与数据存储的位置息息相关，见下图。为每一个排序后的Block块创建一个L2索引，L2索引的结构分为文件偏移(file offset)，数据压缩大小(size)，原始大小(raw size)，由于咱们是多个队列merge，而后接下来是每一个队列相对于起始位置的delta offset以及消息数量。并发

2. L1一级索引

为了加快查询速度，在L2基础上创建L1一级索引，每16个L2创建一个L1，L1按照时间前后顺序存放。L1和L2的组织关系以下：异步

L1索引的结构很是简单，file id对应消息存储的文件id，以及16个Block块中每一个队列消息的起始序列号seq num。例如MQ1从序列号1000开始，MQ2从序列号2000开始等等。高并发

3. Index Query

如何根据索引定位须要查找的数据？

对L1先进行二分查找，定位到上下界范围，而后对范围内的全部L2进行顺序遍历。

Data Flush

1. 同步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进行落盘，写性能虽有必定提高，可是效果也是不太理想，因而采用了第二种思路异步刷盘。

2. 异步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。

整个流程主要有两个优化点：预读取和读缓存。

预读取优化

1. 记录上一次读取（消费）的offset

主要有两个做用：

加快查询数据的速度。
用于判断预读取时机。

2. 预读取时机

顺序消费且已经消费到当前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作了一些精巧的小设计，保证足够简单高效。

分桶（部分隔离），必定程度缓解缓存饿死现象。
数组 + 自旋锁 + 原子变量实现了一个循环分配缓存块的方案。
双向指针绑定高效定位缓存节点。

1. Read Cache全貌

Read Cache一共分为N=64（可配）个Bucket，每一个Bucket中包含M=3200（可配）个缓存块，大概总计20w左右的缓存块，每一个是4k，大约占用800M的内存空间。

2. 核心数据结构

关于缓存的核心数据结构，咱们并无从队列的角度出发，而是针对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，找到新的缓存块进行从新绑定。说明：整个分配的逻辑是一个循环使用的过程，当全部的缓存桶都被使用，那么会从数组首地址开始从新分配、替换。

4. 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数据量高并发读写。

工程价值：

通用性、随机性、健壮性较好，支持对任意队列进行merge。
较少出现单队列消息太少而致使block块未刷盘的状况，块的填充会比较均匀。
没必要等待单个队列满而进行批量刷盘，减小内存占用，更多的内存可支持更多的队列。
能够读写同步进行，常驻内存的索引结构也适合落盘，应对机器重启、持久化等场景。

思考

为何没有使用mmap？为何mmap写入会出现卡顿？

转载请注明出处，欢迎关注个人公众号：亚普的技术轮子