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