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

基礎(chǔ)能力

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

開源

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

流行

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

生態(tài)

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