使用 MQ 在 DB 中存储数据是个好主意吗？答案

【问题标题】：Is it a good idea to use MQ to store data in DB?使用 MQ 在 DB 中存储数据是个好主意吗？
【发布时间】：2012-09-28 01:15:03
【问题描述】：

我将使用 rabbitMQ 作为消息代理并将大部分脚本切换为将数据发送到队列而不是执行直接写入/读取。消费者将获取这些消息并执行相应的操作。在我的梦想中，这会给我更多的灵活性来选择数据库引擎、应用程序级别的分片等等。但一般来说这是个好主意吗？还是我错过了什么？当前的写入负载对于 mysql 为 ~15k 插入/删除，对于 redis 实例为 30-50k 集。读取负载是相同的 ~15-20k 选择，50-70k 用于 redis。

【问题讨论】：

标签： scalability rabbitmq message-queue

【解决方案1】：

您将面临的最大问题是您的数据库写入将被异步处理。如果客户端将数据写入数据库然后立即将其读回，则该值可能不是它最初插入的值，因为 Rabbit 队列可能非常繁忙或缓慢，从而延迟了更新操作。或者管理员可能不小心清除了您的队列，然后您会让所有这些客户认为他们的事务已提交，但没有任何内容被存储。

这听起来像是过早优化的经典案例。这是寻找问题的解决方案，您应该避免这样做。

【讨论】：

是的，根据定义，这是一个过早的优化。 Async for DB 是我想要的。我不希望用户等待 DB 完成写入。相反，我想确保所有数据都写入队列，然后依赖于 rabbitMQ 的 HA-clustered-queues。

【解决方案2】：

使用 amqp，您可以使用 RPC 方式运行非异步操作，使用这种架构，您应该找出与异步操作相关的所有问题。

【讨论】：

当前系统的架构已经或多或少是事件驱动的。有些部分是用 python twisted 编写的，有些是用 node.js 编写的，所以这不是革命性的变化。