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

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

在评估Redis和RabbitMQ之后，出于以下原因，我选择RabbitMQ作为我们的经纪人：

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

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

我的RabbitMQ集群是“主动”还是“主动”？

现在到使用RabbitMQ的弱点：

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

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

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

如果您还有其他问题，请随时发表评论。

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

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

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

以下是在Redis上使用RabbitMQ的专家列表：

• RabbitMQ使用高级消息队列协议（AMQP），可以将其配置为使用SSL（附加安全层）。
• RabbitMQ大约花费Redis接受消息的时间的75％。
• RabbitMQ支持消息优先级，工作人员可以使用它们优先使用高优先级消息。
• 如果有任何工作人员在使用该消息后崩溃，则不会丢失该消息，Redis则不会。
• RabbitMQ有一个很好的路由系统，可以将消息定向到不同的队列。

使用RabbitMQ的一些缺点：

• RabbitMQ可能难以维护，难以调试崩溃。
• 节点名称或节点IP波动会导致数据丢失，但是如果管理得当，持久消息可以解决问题。

我一直在想同样的事情。Logstash的早期建议是在RabbitMQ上推荐Redis（http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized），但是，尽管有https://www.elastic.co/guide/zh-cn/logstash/current/deploying-and-scaling.html上有关使用经纪人处理峰值的一般说明。

虽然我也很开心地使用RabbitMQ，但我目前正在探索Redis代理，因为AMQP协议可能对我的日志记录用例有些过分。

快速提问：

1. 为什么需要经纪人？如果您正在使用logstash或logstash转发器从这些服务器读取文件，则如果管道阻塞，它们都会减慢速度。
2. 您有使用兔子或Redis的经验吗？在所有条件都相同的情况下，您知道如何使用的工具就是更好的工具。

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