Redis Vs RabbitMQ 作为 Logstash 和 elasticsearch 之间的数据代理/消息传递系统

Posted 2023-02-15

【中文标题】Redis Vs RabbitMQ 作为 Logstash 和 elasticsearch 之间的数据代理/消息传递系统

【英文标题】：Redis Vs RabbitMQ as a data broker/messaging system in between Logstash and elasticsearch

【发布时间】：2015-06-14 20:59:27

【问题描述】：

我们正在定义一种架构，以通过安装在各种机器上的 Logstash 运送者收集日志信息，并在一个弹性搜索服务器中集中索引数据，并使用 Kibana 作为图形层。我们需要在 Logstash 托运人和 elasticsearch 之间建立一个可靠的消息传递系统来授予交付。在选择 Redis 而不是 RabbitMQ 作为 Logstash shippers 和 elasticsearch 之间的数据代理/消息传递系统时应考虑哪些因素，反之亦然？

【参考方案1】：

快速提问：

为什么需要经纪人？如果您使用 logstash 或 logstash-forwarder 从这些服务器读取文件，如果管道拥塞，它们都会变慢。 你有管理rabbit或redis的经验吗？在所有条件相同的情况下，您知道如何使用的工具才是更好的工具。

在意见领域，我以经纪人的身份运行 redis，并且讨厌它。当然，这可能是我对 redis 的缺乏经验（不是产品本身的问题），但它是管道中最薄弱的环节，并且在我们最需要的时候总是失败。

【参考方案2】：

我一直在想同样的事情。 Logstash 人员较早的建议推荐 Redis 而不是 RabbitMQ (http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized)，但是当前文档中不再存在该注释部分，尽管此处有关于使用代理处理峰值的通用注释https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html。

虽然我也很高兴地使用 RabbitMQ，但我目前正在探索 Redis 代理，因为 AMQP 协议对于我的日志记录用例来说可能是多余的。

【参考方案3】：

在评估了 Redis 和 RabbitMQ 之后，我选择 RabbitMQ 作为我们的代理，原因如下：

RabbitMQ 允许您使用内置的安全层，通过使用 SSL 证书来加密您发送给代理的数据，这意味着没有人会嗅探您的数据并访问您的重要组织数据。李> RabbitMQ 是一款非常稳定的产品，每秒可以处理大量事件和许多连接，而不会成为瓶颈。 在我们的组织中，我们已经使用了 RabbitMQ，并且对使用它有很好的内部知识，并且已经准备好与厨师的集成。

关于扩展，RabbitMQ 有一个内置的集群实现，除了负载均衡器之外，您还可以使用它来实现冗余代理环境。

Is my RabbitMQ cluster Active Active or Active Passive?

现在是使用 RabbitMQ 的弱点：

大多数 Logstash 发件人不支持 RabbitMQ，但另一方面，最好的一个名为 Beaver 的实现可以毫无问题地向 RabbitMQ 发送数据。 Beaver 在当前版本中使用 RabbitMQ 的实现在性能上有点慢（出于我的目的），并且无法处理来自一台服务器的 3000 个事件/秒的速率，并且服务有时会崩溃。 现在我正在努力解决 RabbitMQ 的性能问题并使 Beaver shipper 更加稳定。第一个解决方案是添加更多可以同时运行的进程，这将赋予托运人更多的权力。第二种解决方案是更改 Beaver 以异步向 RabbitMQ 发送数据，理论上应该更快。我希望我能在本周末之前完成这两种解决方案的实施。

您可以在此处关注问题： https://github.com/josegonzalez/python-beaver/issues/323

并在此处检查拉取请求： https://github.com/josegonzalez/python-beaver/pull/324

如果您有更多问题，请随时发表评论。

【讨论】：

Redis 比 RabbitMQ 有什么强项吗？ Redis 似乎更容易配置。如果您不需要巨大的吞吐量并且正在通过其他方式处理安全性，则可能不需要 RabbitMQ。如果我错了，请纠正我。

您是正确的，但为了确保您需要比较两种产品的性能

“RabbitMQ 是一款非常稳定的产品，每秒可以处理大量事件和许多连接，而不会成为瓶颈。” - 我很确定reddis也是如此。所以这不是 rabbitmq 相对于 Reddit 的优势

“RabbitMQ 允许您通过 SSL 使用内置的安全层” - reddis 也不允许传输层加密吗？

2019年依然redis没有内置TLS

【参考方案4】：

尽管 Redis 具有一些基本的消息代理功能，但它被创建为键值数据存储。

RabbitMQ 被创建为消息代理。它自然有很多消息代理功能。

【讨论】：

随着 Redis 5 中 Stream 的引入，您对 Redis 的表述不再准确。对于大规模场景，RabbitMQ 绝对是更好的选择。对于中小型场景（世界上大多数项目都是如此），Redis 是一种可靠、快速且易于配置的替代方案。

感谢您的承诺，如果有人在这里写下他对Redis新功能的经验，那就太好了。

【参考方案5】：

我一直在对这个主题进行一些研究。如果性能很重要而持久性不重要，那么 RabbitMQ 是一个完美的选择。 Redis 是一种以不同意图开发的技术。

以下是在 Redis 上使用 RabbitMQ 的优点列表：

RabbitMQ 使用高级消息队列协议 (AMQP)，可以将其配置为使用 SSL，这是额外的安全层。 RabbitMQ 大约占 Redis 接受消息时间的 75%。 RabbitMQ 支持消息的优先级，worker 可以使用优先级优先消费高优先级的消息。 如果任何工作人员在使用消息后崩溃，则不会丢失消息，而 Redis 则不会。 RabbitMQ 有一个很好的路由系统，可以将消息引导到不同的队列。

使用 RabbitMQ 的一些缺点：

RabbitMQ 可能有点难以维护，难以调试崩溃。 node-name 或 node-ip 波动会导致数据丢失，但如果管理得当，持久消息可以解决问题。

【讨论】：

Redis 有Sorted Sets，它允许优先级队列式交互。 Redis 也可以集群/分片以将不同的消息发送到不同服务器上的不同队列。不确定是否直接用于 Redis 的 SSL，但我正在研究 AWS Elasticache 和他们的 Redis 3.2.6 允许静态和传输中加密。注意：并不是说 Redis 更适合这种情况；只是指出这些可能不是选择 RabbitMQ 而不是 Redis 的理由。

另外不要忘记 Redis 是单线程的，所以如果你有很多发布者/消费者，这可能是个问题。