-
rabbitMQ簡介二
查看全部 -
rabbitMQ簡介
查看全部 -
安裝rabbitMQ
查看全部 -
記錄一下，安裝過程
查看全部 -
AMQP協議模型
查看全部 -
好好學習查看全部
-
保障100%消息投遞成功設計方案步驟：
Step 1： 首先把消息信息(業務數據）存儲到數據庫中，緊接著，我們再把這個消息記錄也存儲到一張消息記錄表里（或者另外一個同源數據庫的消息記錄表）。
Step 2：發送異步消息到MQ Broker節點（采用confirm方式發送，會有異步的返回結果）。
Step 3、4：生產者端接受MQ Broker節點返回的Confirm確認消息結果，然后進行更新消息記錄表里的消息狀態。比如默認Status = 0 當收到消息確認成功后，更新為1即可！
Step 5：但是在消息確認這個過程中可能由于網絡閃斷、MQ Broker端異常等原因導致回送消息失敗或者異常（即step2發送消息成功了，但step3失?。?。這個時候就需要發送方（生產者）對消息進行可靠性投遞了，保障消息不丟失，保障100%的投遞成功！（有一種極限情況是閃斷，Broker返回的成功確認消息，但是生產端由于網絡閃斷沒收到，這個時候重新投遞可能會造成消息重復，需要消費端去做冪等處理）所以我們需要有一個定時任務，（比如每5分鐘拉取一下處于中間狀態的消息，當然這個消息可以設置一個超時時間，比如超過1分鐘 Status = 0 ，也就說明了1分鐘這個時間窗口內，我們的消息沒有被確認，那么會被定時任務拉取出來）。
Step 6：接下來我們把中間狀態的消息進行重新投遞 retry send，繼續發送消息到MQ ，當然也可能有多種原因導致發送失敗。
Step 7：我們可以采用設置最大努力嘗試次數，比如投遞了3次，還是失敗，那么我們可以將最終狀態設置為Status = 2 ，最后 交由人工解決處理此類問題（或者把消息轉儲到失敗表中）。
注意：此方案只保證100%投遞成功，不保證是否出現多投的情況，需要消費者做冪等。
查看全部 -
Direct exchange（直連交換機）
直連型交換機（direct exchange）是根據消息攜帶的路由鍵（routing key）將消息投遞給對應隊列的，步驟如下：
將一個隊列綁定到某個交換機上，同時賦予該綁定一個路由鍵（routing key）
當一個攜帶著路由值為R的消息被發送給直連交換機時，交換機會把它路由給綁定值同樣為R的隊列。
Fanout exchange（扇型交換機）
扇型交換機（funout exchange）將消息路由給綁定到它身上的所有隊列。不同于直連交換機，路由鍵在此類型上不啟任務作用。如果N個隊列綁定到某個扇型交換機上，當有消息發送給此扇型交換機時，交換機會將消息的發送給這所有的N個隊列
Topic exchange（主題交換機）
主題交換機（topic exchanges）中，隊列通過路由鍵綁定到交換機上，然后，交換機根據消息里的路由值，將消息路由給一個或多個綁定隊列。
扇型交換機和主題交換機異同：
對于扇型交換機路由鍵是沒有意義的，只要有消息，它都發送到它綁定的所有隊列上
對于主題交換機，路由規則由路由鍵決定，只有滿足路由鍵的規則，消息才可以路由到對應的隊列上
Headers exchange（頭交換機）
類似主題交換機，但是頭交換機使用多個消息屬性來代替路由鍵建立路由規則。通過判斷消息頭的值能否與指定的綁定相匹配來確立路由規則。?
此交換機有個重要參數：”x-match”
當”x-match”為“any”時，消息頭的任意一個值被匹配就可以滿足條件
當”x-match”設置為“all”的時候，就需要消息頭的所有值都匹配成功
查看全部 -
可靠性投遞方案
查看全部 -
amqp協議模型
查看全部 -
step1. 數據入庫同時消息（msg）入庫
step2.發送消息
step3.請求確認 confirm
step4.讀取數據庫msg消息修改狀態status：1
step5.但發送消息網絡中斷，通過定時任務查詢狀態為status：0的消息
step6.抓取消息，重新投遞
step7.最大嘗試次數 3次 不能成功則狀態修改為2。
查看全部 -
100%消息投遞成功設計
注意：只考慮發送方100%投遞，當多次投遞成功需要接收方做“冪等”處理。查看全部 -
消息流轉數據過程
查看全部 -
AMQP 高級消息隊列協議
查看全部 -
采用模式：鏡像隊列模式，數據不丟失
查看全部
舉報