? 优质资源分享 ?
| 学习路线指引（点击解锁） | 知识定位 | 人群定位 |
|---|---|---|
| ? Python实战微信订餐小程序 ? | 进阶级 | 本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。 |
| ?Python量化交易实战? | 入门级 | 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 |
大家好，我是【架构摆渡人】，一只十年的程序猿。这是消息队列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。
今天跟大家聊聊如何用数据库来做消息的存储，这样就可以将消息队列的整体复杂度进行降低，如果后续你们需要自己造更贴近公司业务的轮子，我觉得可以用数据库来存储。
容量设计
假设你们的业务消息量每天是10亿条，数据存储最近7天的量，也就是70亿条。我们以单表2000W条数据作为上限，1个库放10张表，那么总共需要40个库来承载这些数据量。
当然这40个库可以不用40个单独的数据库实例，这样成本有点高，当然主要还是取决于你们消息的读写并发有多高，如果很高的话数据库实例越多，性能肯定越好。不多的话就5个数据库实例，每个实例上建8个库即可。（根据消息读取和写入的量结合数据库规格的性能进行评估）
数据归档
因为我们总共也就能存放80亿条的数据，如果数据量多了必然会影响查询性能或者磁盘空间不够的问题，而且对于已消费的消息，其实后面就没有业务价值了。
所以我们还需要每天进行数据的归档操作，归档你可以将这些数据移到Nosql中，也可以进行删除，看业务场景决定。有了归档，这样就能保持当前的数据库集群能够承载每日的消息容量。
存储设计
接下来聊聊最重要的存储设计，就是我要用数据库来存，我的表该怎么设计？
前面我们也讲到了，我们大概需要400张表来存储这些数据。我们对某个Topic进行消息发送，那么数据必然要落到这400张表中的某一张表里面，所以我们很自然的想以某个字段来分表就行了呗，比如Topic，每个Topic写入的数据必定在同一张表里面。
这样也没啥问题，但是在实际的业务中，必定是有的Topic消息量会很大，有的会很少。对于消息量很大的，可能几个小时就突破2000W的量了，那么这个表必定越来越大。所以我们在设计数据存储的时候一定要考虑到如何将某个Topic下的数据均匀的存储到多张表里面去。
可能有人就会说了，既然不能固定按Topic进行分表，那么就对总的表数量取模好啦，这样数据就会分布在每张表里面。但是这样对于consumer在消费的时候就有影响了，因为consumer压根就不知道自己要消费Topic的数据存在哪，必须得从所有的库表里面进行查询才能拿到数据，性能不太好。
要解决这个问题，我们先回顾下开源的MQ是怎么设计的，以RocketMQ来说，一个Topic下的消息会存储到多个Queue中（也就相当于kafka中的partition），也就是每个Topic下的Queue并不是一定的数量，而是可以在创建Topic时进行指定，所以我们在用表做存储的时候，也可以参考这个设计，本来每个Topic对应的消息量就不同。
所以一张表也就相当于一个Queue，用于存储消息内容。我们可以记录Topic和Queue之间的关系，记录后有如下的作用：
- 往某个Topic写入消息的时候，就知道这个Topic对应哪些Queue（数据表），可以轮询的写入这些表，这样数据就比较平均。
- 创建Topic的时候要预估一下数据量，然后指定分配多少个Queue用于存储。（后续也能在线修改Queue的数量）
- Consumer消费某个Topic消息的时候，同样也知道对应哪些Queue，在Consumer初始化的时候就会分配好哪个Consumer消费哪个Queue，这样每个Consumer只会去固定的一个表中查询数据，性能也非常好。如果后面Consumer增加或者减少，Queue增加或者减少就需要重新分配了，这就是消息队列中经常提到的重平衡的一个概念。
当然这里只是说了整体的设计，还有很多细节需要去完善，比如Topic消息量小的如何处理，就算是只分配一个表，但是我们总的表数量是有限的，所以还会涉及到多Topic共用一个表的情况。
大概的我们可能会有下面的一些表：
- consumer: 消费者，记录当前消费者的信息，比如ip, 进程ID, 应用类型，启动时间等等。
- consumerGroup: 消费组信息。
- topic：主题表。
- queue: 消息表，记录消息内容，对应的Topic等等。
- topicQueue: Topic和queue的关系。
- queueOffset: 队列消费偏移量，记录consumer的消费信息。
总结
不同的场景可以选择不同的技术方案，用数据库作为MQ的存储也是一种不错的思路。但为什么开源的都是自己写磁盘呢？其实这也跟架构有关系，因为一旦依赖外部存储，也就是整个架构会比较复杂。而且MQ这种本来就是用来扛大流量的，所以要对底层进行优化，用三方的也就意味着性能其实依赖了三方。
通过数据库来存储MQ的数据，相对来说技术难点会比写磁盘要简单点，大家也可以按照这个思路，自己去设计实现一款MQ。
原创：架构摆渡人（公众号ID：jiagoubaiduren），欢迎分享，转载请保留出处。
推荐一款开源的mock框架：https://github.com/yinjihuan/fox-mock 基于Java Agent实现的自测，联调Mock利器
转载请注明：xuhss » 如何降低复杂度，用数据库做消息队列的存储？