应用程序将日志从许多计算机发送到Amazon Cloud并将其存储在某个数据库中。
> Lets assume: one machine log size: 1kB every 10 seconds, num of machines from
1000 to 5000
我的第一种方法是将日志排入rabbitmq，然后rabbitmq consumer将它们存储在sql数据库中。
- 当消费者只做一些基本的存储操作时，我真的需要rabbitmq吗？
第二种方法是将日志排入rabbitmq，但将它们存储在mongodb中
- 在写入mongodb之前对消息进行排队是否有意义？
2 个答案:
答案 0 :(得分：4)
由于您已经有多个生产者系统创建日志，因此您已经拥有了分布式体系结构。
解决实用程序/交叉问题，例如从每个系统进行日志记录，而不是使用队列，有很多好处：
- 通过使用异步方法，您将能够在Rabbit中缓冲大量消息的峰值，而不会影响生产者系统的吞吐量。此外，集中式日志写入系统可能能够批量日志插入 - 批量日志消息写入将需要更少的数据库连接，并且可以优化IO，超过大量服务器直接写入少量日志所能实现的。 / LI>
- 它集中了日志写作的关注。这样，您就不需要维护代码来在每个生产者上写日志，例如如果日志格式或日志存储发生变化（您似乎已经怀疑是否将日志存储在像Mongo或Sql这样的NoSql中）。如果生产者机器使用不同的技术堆栈（例如Java，Node，.Net）或不同版本的JVM等，这将特别有用。（但是你需要从每个系统写入队列）
- 它将生产系统的可用性与日志记录服务分离（例如，如果将日志数据写入MongoDb的服务已关闭，则日志可以在Rabbit中排队，直到系统再次可用）。但请记住在原始服务器上标记消息创建时间。
- 它释放了生产者系统上的IO和CPU资源。
- Rabbit可以构成总线架构的基础。这将允许您扩展日志消息的使用者数量，例如为了冗余，或者例如实现指标，而不会影响现有的实施。
答案 1 :(得分：1)
正如StuartLC所说，你需要缓冲，你需要decouples the availability of the producing system from the logging service。
这是针对RabbitMQ的缺点：
- RabbitMQ将是另一个管理失败的点。如果您的日志很重要和/或具有高吞吐量，则必须创建一个RabbitMQ集群。
- 您必须管理本地缓冲，因为RabbitMQ可能无法使用，或者您的生产者位于flow control下。
- RabbitMQ做缓冲，但健康的RabbitMQ是空的。
您没有定义“log”下的内容。在您说明1kB every 10 seconds时，它似乎是指标。如果我错了，请纠正我。
关于日志处理，我倾向于使用专用于日志处理的堆栈来支持本地缓冲：syslog，flume，logstash ...由具有高吞吐量的数据存储区支持。 MongoDB应该满足需求，我对RDBMS有点怀疑。
您可以使用本地RabbitMQ和federated queues实现本地缓冲。