我有一些代码会产生大量应该存储在数据库中的数据。问题是数据库无法保存它生成的数据。所以我想知道某种排队机制是否会在这种情况下有所帮助 - 我特别在 RabiitMQ 考虑将数据存储在其队列中是否可行，直到某些消费者从中获取数据并将其推送到数据库. 另外，我对这些数据是否进入数据库并不特别感兴趣，因为很快，相同的数据将被更新。
问问题
537 次
2 回答
1
数据库应该非常快速地处理数据插入，没有锁定机制，因为插入是关于存储中尚不存在的数据。如果您正在处理数据插入并且您对数据库的序列化是一个瓶颈，那么RabbitMQ仍然存在您遇到的任何问题，因为数据库插入应该比到 RabbitMQ 的出站消息传递执行得更快。在这种情况下，RabbitMQ 将无法解决您的问题。另一方面，数据更新将锁定更新行（通常），您可能会遇到锁定和等待的并发问题。所以总的来说，试着理解为什么你的数据库持久性是一个瓶颈。
最终，如果您的数据存储是 NOSQL，那么它可能不是执行写入，在这种情况下，您可以分析更快接收数据的内容（NoSQL 与 RabbitMQ）。
如果您在多个线程上有数据生产者，那么您会遇到写入持久性存储的并发问题。在这种情况下，RAbbitMQ 应该比持久存储更好地处理并发，因为它是为高并发设计的。这取决于您使用的数据存储。
于 2013-07-21T13:19:28.013 回答
1
@hyperboreean 听起来可能有点花言巧语，但也许您真正需要的是Redis或MemcacheD之类的缓存？
从技术上讲，您可以将 RabbitMQ 与更新数据库的消费者一起使用，但您需要实现“队列清理”机制，否则只要您的输入速率仍然超过数据库可以处理的速度，您的队列就会变得越来越大。随着队列的增长，其中的数据变得陈旧 - 这意味着刚刚提交的更新仍在队列中。把它想象成一家只有一个检查器的商店。当然，您可以形成单独的行，但这仅意味着您有多个长行并且仍然有一个检查器。您仍然受到检查员可以处理您的客户的速度的约束。
从太简短的描述来看，您的数据实际上是瞬态数据，缓存系统（或其他类似 NoSQL 的安排）可能更适合。如果您最终确实需要持久化数据，您可以有一个单独的进程从缓存机制中提取当前数据并将其加载到您的数据库中。然后，您将受到提取数据所花费的时间与实际将数据加载到数据库中的频率的限制。
于 2010-05-27T19:14:04.900 回答