如何通过数据库简化消息队列存储的复杂度？

本文共计1506个文字，预计阅读时间需要7分钟。

大家好，我是[架构摆渡人]，一名十多年的程序员。这是消息队列系列的 第一篇文章，这个系列将和大家分享很多在实际工作中实用的经验。 如果有收获，请分享给更多朋友。今天，跟随[架构摆渡人]一起探索。

大家好，我是，一只十年的程序猿。这是消息队列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

今天跟大家聊聊如何用数据库来做消息的存储，这样就可以将消息队列的整体复杂度进行降低，如果后续你们需要自己造更贴近公司业务的轮子，我觉得可以用数据库来存储。

容量设计

假设你们的业务消息量每天是10亿条，数据存储最近7天的量，也就是70亿条。我们以单表2000W条数据作为上限，1个库放10张表，那么总共需要40个库来承载这些数据量。

当然这40个库可以不用40个单独的数据库实例，这样成本有点高，当然主要还是取决于你们消息的读写并发有多高，如果很高的话数据库实例越多，性能肯定越好。不多的话就5个数据库实例，每个实例上建8个库即可。（根据消息读取和写入的量结合数据库规格的性能进行评估）

数据归档

因为我们总共也就能存放80亿条的数据，如果数据量多了必然会影响查询性能或者磁盘空间不够的问题，而且对于已消费的消息，其实后面就没有业务价值了。

所以我们还需要每天进行数据的归档操作，归档你可以将这些数据移到Nosql中，也可以进行删除，看业务场景决定。有了归档，这样就能保持当前的数据库集群能够承载每日的消息容量。