小公司，业务量不大，架构很简单，一个SQL数据库，一个web服务。最近老板不知道听了什么讲座，回来就让我们去弄一个消息队列，说是为以后发展作准备。
我百度了一些消息队列的资料，发现好像用数据库来做也可以，新建一个名为 messages 的table，里面有：
生产者的消息就往这个表里 insert 一行，消费者就到这里面去定时查询某个 topic里未被消费的消息。（如果要考虑时效性，发送完了就可以直接 http 或者 tcp 通知一下消费者去取）
我把这个想法和老板说了，老板说我这个没用，有点想不通。
本文参与了SegmentFault 思否面试闯关挑战赛，欢迎正在阅读的你也加入。
当然，公司业务小架构简单，用数据库实现消息队列确实方便。定时任务查询未被消费的任务去消费即可，这样实时性不高，再加一个发送完通知下游去数据库取任务。那么再深入看一下可能的一些问题：
生产者通知下游消费者去数据库读消息，这样做是不是增加了生产者和下游消费者的耦合？例如：用户在支付系统下完单，需要通知仓库系统出库、通知积分系统给用户加积分、通知xxxxxx...
如果使用了一个消息中间件，作为上游完全不需要知道下游的存在，而使用数据库的方案，上游系统要小心翼翼的处理上面每一个问题，除非不去通知消费者，不考虑时效性。
如果不通知消费者，站在消费者端，还有许多问题等待题主解决。
上面的这些问题，使用数据库也是可以解决的，但是要写很多代码，要测试，并且很难保证实现没有问题？那么如果直接使用成熟的消息队列产品，它已经帮你实现好了这些，你只需要专注业务开发即可。
本文参与了SegmentFault 思否面试闯关挑战赛，欢迎正在阅读的你也加入。
l老板说没用可能是指对他想为以后做的准备没用，老板是想做大做强，未来你们的项目有百万千万的用户使用，如果用你这个数据库mq，只能在简单的架构中使用，举个例子，多消费者是常见的情况，你的数据库mq怎么解决重复消费的问题？同样的问题还有很多，除非你都解决了，不然还是“没用”
本文参与了SegmentFault 思否面试闯关挑战赛，欢迎正在阅读的你也加入。
业务量不大场景，推荐RabbitMQ。
MQ其中一个作用就是解耦，使用数据库的实现方式，通知消费者这种本身就是耦合性比较高的操作。
本文参与了SegmentFault 思否面试闯关挑战赛，欢迎正在阅读的你也加入。
虽然在理论上，使用数据库来实现消息队列是可行的，但是这种实现方式存在一些潜在的问题和限制，相较于专业的消息队列服务，使用数据库作为消息队列的实现方式有以下几个问题：
性能问题：数据库是为了存储大量数据而设计的，而消息队列则是为了高效地处理大量的消息而设计的。在高并发的场景下，数据库可能会成为瓶颈，影响性能。
可靠性问题：数据库虽然提供了事务机制来保证数据的一致性，但是在高并发的场景下，如果消息的生产者和消费者同时操作同一条记录，可能会产生死锁等问题，从而影响消息的可靠性。
时效性问题：消息队列通常需要满足实时性的需求，即消费者需要在消息被发送后尽快消费，否则可能会产生重复消费或漏消费的问题。使用数据库作为消息队列的实现方式，消费者需要定时轮询数据库以获取新消息，这样可能会产生延迟，影响时效性。
可扩展性问题：如果业务量增长，需要处理的消息量也会增加，如果使用数据库作为消息队列的实现方式，可能需要进行水平扩展，增加数据库的数量，从而增加了维护和成本的复杂度。
综上所述，虽然使用数据库作为消息队列的实现方式是可行的，但是相比专业的消息队列服务，其性能、可靠性、时效性和可扩展性都存在一定的问题。如果公司未来业务量增长，需要处理更多的消息，建议使用专业的消息队列服务，如RabbitMQ、Kafka等。
6 回答1.3k 阅读✓ 已解决
4 回答1.7k 阅读
2 回答2.2k 阅读
2 回答1.2k 阅读
1 回答916 阅读✓ 已解决
1 回答883 阅读✓ 已解决
2 回答1.5k 阅读
极客观点
研发管理
HarmonyOS
发送完了就可以通知一下消费者去取完全丧失了消息队列的意义，消息队列就是为了解耦消费者和生产者