在此之前，我們了解了消息隊(duì)列的作用，那么消息隊(duì)列如何進(jìn)行選擇呢?選擇消息隊(duì)列，我們要注意以下幾點(diǎn)。

基礎(chǔ)能力

不同的消息隊(duì)列有著不同的特點(diǎn)，但是以下幾點(diǎn)，是無論哪種消息隊(duì)列，都需要進(jìn)行考慮的。首先是可靠性，也就是我們常說的不丟消息，如果一個(gè)消息隊(duì)列無法保證消息可靠，那么就會遇到大麻煩，查問題，修數(shù)據(jù)便是家常便飯。其次是分布式，一個(gè)好的消息隊(duì)列，必須是支持集群的，而非單機(jī)模式。假如消息隊(duì)列無法分布式部署，網(wǎng)絡(luò)的波動，硬件的故障，就有你好受。第三是性能，如果一個(gè)消息隊(duì)列的性能太差，就意味著消息的消費(fèi)可能延遲，就可能影響到很多業(yè)務(wù)，造成業(yè)務(wù)不可用，得不償失。

開源

對于大部分的公司來說，自己去重復(fù)造輪子的意義并不是很大，我們拿來開源的項(xiàng)目來使用的效果更好。為什么是開源而不是一些廠商提供的二進(jìn)制呢?是代碼就有bug，無論是多么成熟的項(xiàng)目，如果你在使用這個(gè)消息隊(duì)列的時(shí)候遇到問題了，開源項(xiàng)目，你至少還有閱讀源碼，改一改搏一搏的可能，無需等待廠商進(jìn)行發(fā)版修復(fù)。

流行

除非某個(gè)冷門的MQ正好有你需要的某種特性，否則建議大家盡量使用流行的方案。就跟買車一樣，盡量不要買小眾的汽車，平時(shí)開起來是沒有什么問題，但是一旦壞了，需要修的時(shí)候，小眾的汽車就麻煩多了。軟件也是如此，如果你使用的是RMQ，kafka這類中間件，你遇到的問題，可能很多人也遇到過，這個(gè)時(shí)候就可以站在巨人的肩膀上，快速解決問題。

生態(tài)

一個(gè)好的生態(tài)，對中間件的發(fā)展是非常重要的。就好比SpringCloud等，擁有豐富的生態(tài)，在SpringCloud這個(gè)巨人身上，你介入一個(gè)新的組建都是非常的方便。消息隊(duì)列也是如此，舉個(gè)例子，Kafka與Flink，F(xiàn)link內(nèi)置了Kafka的DataSource，開發(fā)流式應(yīng)用非常的方便，無需其他開發(fā)。