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中去。