完全可以使用 RDBMS 作为消息队列

Lukas Eder 是 JOOQ 母公司的创始人兼 CEO。近日，他针对《将数据库作为消息队列是一种反模式》一文的观点及其在 reddit 上引发的争论表达了看法。他认为，使用数据库作为消息队列不是一种反模式，理由如下：

1. KISS 和 YAGNI 原则——如果使用 RDBMS 可以满足消息传递的需求，那么就不必花费时间和金钱引入一款复杂的消息队列工具；
2. 事务性队列——即使使用成熟的消息队列工具，要实现事务性队列依然很复杂，而使用基于 RDBMS 的队列则可以避免事务处理的复杂性；
3. 无需额外的运维工作——引入新的外部系统会增加运维成本；
4. 如果已经使用了 Oracle 数据库，则可以直接使用其内置的队列 API Oracle AQ ；
5. 以 RDBMS 为中心的应用程序更简单——数据的存在时间大于应用程序，比如， Paypal 从 Java 切换到 JavaScript ，但他们并没有替换掉所有的数据库。因此，如果 RDBMS 是系统的中心，那么在 RDBMS 中运行消息队列是一种选择。

但有位自称见过多个此类案例的读者列举了这种做法面临的几项挑战：

1. 数据库没有有丢弃和限流策略，如果信息产生速度大于消费速度，那么消息表就会变得越来越大。
2. 数据库表可以针对写优化，也可以针对读优化，但无法同时对两者进行优化。
3. 数据库无法对一个数据项进行并发处理。
4. 大批量的数据处理会产生长事务，事务越长锁的持有时间越长。

Lukas 承认，使用 RDBMS 作为消息队列有一些注意事项。但针对第三点，他提到，Oracle AQ 针对 FOR UPDATE 语句进行了扩展，提供了 FOR UPDATE SKIP LOCKED 语句。该语句允许对记录进行非阻塞式悲观锁定，提高了并发性。

另外，还有一位读者提到， Spring Integration 支持使用数据库存储队列消息，有兴趣的读者可以对此进行研究测试。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。