在此之前，我們瞭解了消息隊列的作用，那麼消息隊列如何進行選擇呢？選擇消息隊列，我們要注意以下幾點。
基礎能力
不同的消息隊列有著不同的特點，但是以下幾點，是無論哪種消息隊列，都需要進行考慮的。首先是可靠性，也就是我們常說的不丟消息，如果一個消息隊列無法保證消息可靠，那麼就會遇到大麻煩，查問題，修數據便是家常便飯。其次是分佈式，一個好的消息隊列，必須是支持集群的，而非單機模式。假如消息隊列無法分佈式部署，網絡的波動，硬件的故障，就有你好受。第三是性能，如果一個消息隊列的性能太差，就意味著消息的消費可能延遲，就可能影響到很多業務，造成業務不可用，得不償失。
開源
對於大部分的公司來說，自己去重複造輪子的意義並不是很大，我們拿來開源的項目來使用的效果更好。為什麼是開源而不是一些廠商提供的二進制呢？是代碼就有bug，無論是多麼成熟的項目，如果你在使用這個消息隊列的時候遇到問題了，開源項目，你至少還有閱讀源碼，改一改搏一搏的可能，無需等待廠商進行發版修復。
流行
除非某個冷門的MQ正好有你需要的某種特性，否則建議大家儘量使用流行的方案。就跟買車一樣，儘量不要買小眾的汽車，平時開起來是沒有什麼問題，但是一旦壞了，需要修的時候，小眾的汽車就麻煩多了。軟件也是如此，如果你使用的是RMQ，kafka這類中間件，你遇到的問題，可能很多人也遇到過，這個時候就可以站在巨人的肩膀上，快速解決問題。
生態
一個好的生態，對中間件的發展是非常重要的。就好比SpringCloud等，擁有豐富的生態，在SpringCloud這個巨人身上，你介入一個新的組建都是非常的方便。消息隊列也是如此，舉個例子，Kafka與Flink，Flink內置了Kafka的DataSource，開發流式應用非常的方便，無需其他開發。
好了，關於消息隊列的選擇我們就講到這裡，接下來我們會講消息隊列的模型以及一些基礎概念，如果你有興趣，歡迎關注我，我們一起學習，一起進步。同名公眾號：沙茶敏碎碎念
