訊息佇列的使用場景之RabbitMQ

自己原文公眾號： https://mp.weixin.qq.com/s/gjZk3vXvrJIYghDjYDYzuw

安裝Rabbitmq的步驟不詳細說了。

但是主要的要說說。

第一步安裝erlang，沒有這個不行。而且這個erlang和rabbitmq的版本有對應關係。

最重要一點網上很多帖子資料要去rabbitmq官網下載，會發現官網的那些頁面都沒有了。

所以安裝變成了一個問題。想當年誰在linux上安裝一個Oracle就是個高手（因為安裝太複雜了）

在windows上安裝Oracle還是比較舒服的，和安裝QQ差別不太大。

如今就連Oracle都一鍵安裝了，這個需要官方考慮考慮了。不然就erlang和rabbitmq的版本對應關係就不好解決。

說到這個不得不說當初CDH在我沒有整包安裝情況下，hbase、hive等等的安裝是非常痛苦的。

上圖顯示了至少這個版本的兩個軟體是相容的

我們用命令列來寫一條資料看看.

再用程式碼寫一條資料。這裡我特意寫的節點是叢集的另外一臺機器，故意和命令列寫入的不是同一臺機器。目的是驗證說明每個節點都可以寫入。

其實命令列和程式碼都可以讀寫，只是目前命令列的讀取只有查詢沒有消費的功能（網上寫的實測是報錯的）這裡用程式碼從另外一臺機器（非程式碼寫入的機器上）上讀取

看上去其實和資料庫差不多。資料庫就是負責資料的寫入和讀取（簡單的來說），我們發現MQ也差不多。就是不支援SQL。

當然也有支援SQL的訊息中介軟體。日後會介紹將來可能一統天下的PULSAR。

既然說到這裡那什麼時候用這個呢？個人覺得，如果說 系統解耦可以用用。但是一般我覺得解耦的關鍵還是在設計，而不是靠訊息佇列。

如果說用在非同步呼叫也可以用用，但是我覺得能同步的還是同步吧。我見過不少的本來同步處理的，後來由於對資料庫沒有信心走非同步，反而造成了鎖。因為訊息佇列不能絕對的保證順序。但是資料庫可以。

如果說為了流量削峰，那麼你業務量超過了資料庫單機的處理能力，那麼用吧。不過這種企業在中國也不多。