ELK之消息队列选择redis_kafka_rabbitmq

前言描述

生产初级，Service服务较少，访问量较少，随着业务量的不断增加，日志量成倍增长，然后就遇到了消息队列redis被充爆，不能满足应用的情况。针对此情况，我们来分析下可用的消息多列。

官方推荐消息队列

redis、kafka、rabbitmq。我们现在针对这三种进行比较。

从消息订阅模式比较

Redis

redis是基于内存的应用，消息都存放在内存中，写入读取速度快，但是受内存容量的限制，容易造成内存充爆。

Kakfa

kafka是一个分布式的流式处理平台，它的设计初衷就是一个日志系统，消息内容是可以持久化一段时间的，消息的订阅消费位置的确定是通过消费者offset来定位的，也可以定位到之前消息再次消费。

Rabbitmq

rabbitmq的一个特殊之处是，生产者并不是直接将消息发送到队列中，而是通过exchange中继，exchange转发到队列。所以rabbitmq在消息的路由方面比之前两者都好很多。

从work queue来比较

Redis

redis的消息数据就存放在内存中，因为redis数据的原子性，数据只能被消费一次，不能重复。

Kafka

kafka通过consumer group的方式实现了work queue。·同一个组的消费者能够协调完成任务。另外它是一个分布式的文件系统，他的队列可以理解为topic，我们都知道topic是可以划分为多个partition的，多个partiton是可以分布在不同的node节点上的。这样当一个consumer来消费的时候，就可以到不同的节点上去获取消息，也就达到了负载均衡的作用，避免单点压力。于此同时，就会产生另外的一个问题，当有消费者在进行消费的时候，如何保证这个队列同时不背其他的消费者消费，这就需要zookeeper的分布式锁来解决了。

Rabbitmq

rabbitmq也是有自己的一个机制来实现队列的负载均衡，通过轮询机制给worker发布消息，以此来实现。当有大量的消费者去消费同一个队列的时候，这个队列的性能就会成为一个瓶颈

Rabbitmq的一个强大之处

因为它的一个核心exchanger。它可以将消息路由到不同的队列去，比如我既要打印输出，还要持久化，那我就可以直接路由到两个queue中去。