写入MongoDb之前的RabbitMQ队列消息

Question

应用程序将日志从许多机器发送到Amazon Cloud，并将它们存储在某个数据库中。

> Lets assume: one machine log size: 1kB every 10 seconds, num of machines from
1000 to 5000

我的第一种方法是将日志在Rabbitmq中排队，然后Rabbitmq使用者将其存储在sql数据库中。

1. 当消费者仅执行一些基本存储操作时，我真的需要Rabbitmq吗？

第二种方法是将日志在Rabbitmq中排队，但将其存储在mongodb中

2. 在写入mongodb之前将消息排队是否有意义？

Answer 1

由于您已经有多个生产者系统来创建日志，因此您已经具有分布式体系结构。

将实用程序/交叉问题分离开来有很多好处，例如从每个系统中记录日志，而不是使用队列：

• 通过使用异步方法，您将能够在Rabbit中缓冲大量消息的峰值，而不会影响生产者系统的吞吐量。同样，集中式日志写入系统可能能够批量处理日志插入-批量日志消息写入将需要较少的数据库连接，并且可以优化IO，而这超出了由大量服务器（每个服务器直接直接写入少量日志）可能实现的范围。
• 它集中了对日志编写的关注。这样，您无需维护代码就可以在每个生产者上写日志，例如，如果日志格式或日志存储发生了变化（似乎已经怀疑是否要将日志存储在Mongo或Sql之类的NoSql中）。如果生产者机器使用不同的技术堆栈（例如Java，Node，.Net）或不同版本的JVM等，这将特别有用（但是您确实需要从每个系统写入队列）
• 它使生产系统的可用性与日志服务分离（例如，如果将日志数据写入MongoDb的服务已关闭，则日志可以在Rabbit中排队，直到系统再次变得可用）。但是，请记住在原始服务器上标记消息创建时间。
• 它释放了生产者系统上的IO和CPU资源。
• Rabbit可以构成总线体系结构的基础。这将允许您扩展日志消息的使用者数量，例如用于冗余或实现指标，而完全不影响现有的实现。