前言描述
生產初級，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中去。