天池中间件大赛——单机百万消息队列存储分享（作者：我的 96 年表弟）

最新推荐文章于 2019-10-29 17:26:41 发布

芋道源码

最新推荐文章于 2019-10-29 17:26:41 发布

阅读量325

点赞数

点击上方“芋道源码”，选择“置顶公众号”

技术文章第一时间送达！

源码精品专栏

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

赛题回顾

实现一个进程内的队列引擎，单机可支持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

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写入会出现卡顿？

如果你对 Dubbo 感兴趣，欢迎加入我的知识星球一起交流。

640?

知识星球

目前在知识星球（https://t.zsxq.com/2VbiaEu）更新了如下 Dubbo 源码解析如下：

01. 调试环境搭建
02. 项目结构一览
03. 配置 Configuration
04. 核心流程一览

05. 拓展机制 SPI

06. 线程池

07. 服务暴露 Export

08. 服务引用 Refer

09. 注册中心 Registry

10. 动态编译 Compile

11. 动态代理 Proxy

12. 服务调用 Invoke

13. 调用特性

14. 过滤器 Filter

15. NIO 服务器

16. P2P 服务器

17. HTTP 服务器

18. 序列化 Serialization

19. 集群容错 Cluster

20. 优雅停机

21. 日志适配

22. 状态检查

23. 监控中心 Monitor

24. 管理中心 Admin

25. 运维命令 QOS

26. 链路追踪 Tracing

...
一共 60 篇++

芋道源码

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫