写入MongoDb之前RabbitMQ队列消息

应用程序正在从许多机器向Amazon云发送日志，并将它们存储在一些数据库中

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

我的第一种方法是在rabbitmq中对日志进行排队，然后rabbitmq使用者将它们存储在sql数据库中

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

当消费者只做一些基本的存储操作时，我真的需要rabbitmq吗

第二种方法是在rabbitmq中对日志进行排队，但将它们存储在mongodb中

在写入mongodb之前对消息进行排队有意义吗

---

因为已经有多个生产者系统创建日志，所以已经有了分布式体系结构

将实用程序/横切关注点（如日志记录）与每个系统分离，并使用队列，有许多好处：

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

---

如StuartLC所述，您需要缓冲，并且需要

将生产系统的可用性与日志记录服务分离

以下是反对RabbitMQ的缺点：


RabbitMQ将是管理的另一个失败点。如果您的日志非常重要和/或具有高吞吐量，则必须创建RabbitMQ集群
您必须管理本地缓冲，因为RabbitMQ可能不可用，或者因为您的生产者正在使用
RabbitMQ进行缓冲，但正常的RabbitMQ是空的

您没有定义“日志”下的内容。当您每10秒声明
1kB时，它似乎是度量标准。如果我错了，请纠正我

关于日志处理，我倾向于使用专用于日志处理的堆栈进行本地缓冲：syslog。。。由具有高吞吐量的数据存储支持。MongoDB应该符合需要，我对RDBMS有点怀疑

无论您能够使用本地RabbitMQ和。
实现什么样的本地缓冲，许多记录器都允许在生产者系统中使用多个
接收器。除此之外，或在此之前，将日志发送到集中式数据库是一个好主意，以防在通过网络发送日志数据时出现问题—例如，像航空业中的黑匣子一样，如果文件系统在创伤性硬件故障或诸如此类的情况下幸存下来，您仍有一些数据可用于事后处理。