## 生產端的可靠性投遞 1. 保障消息的成功發出; 2. 保障MQ節點的成功接收; 3. 發送端收到MQ節點(broker)確認應答; 4. 完善的消息進行補償機制; ## 生產端-可靠性投遞 1. 消息入庫,對消息狀態進行打標;對于消息狀態沒有投遞成功的進行輪詢投遞;嘗試一定的次數再去輪詢發送; 2. 消息的延遲投遞,做二次確認,回調檢查; ## 消息落庫 1. 消息入庫; 對于多張表,小規模的并發可以加事務;在高并發的情況下,不要加事務; 2. 發送消息到broker; 3. 等待broker回復消息;更新數據庫的消息,將消息的狀態修改為已發送; 4. 如果生產端沒有接收到broker的確認消息,那么使用另外一個定時任務,對超時幾分鐘還沒收到的消息進行再次發送; **這里往數據庫插入兩條數據,一條是對業務數據的添加或修改,一條是插入消息的實體記錄到數據庫**;  ## 延遲投遞,二次確認,回調檢查 消息落庫的方式要進行兩次的數據庫操作,那么在高并發的場景下,這樣肯定是不適合的; 1. 消息入庫BIZ DB,只入一次庫; 2. 生產端發送兩條消息,第一條立刻發送,第二條延遲5分鐘發送到callback中; 并且這兩個消息是發送到不同的exchange或queue里面的; 3. 當消費端消費消息第一個消息后,再里面除開ack后再發送一條消息到callback服務中,callback將這條記錄入庫.說明這條記錄已經處理完成; 4. 延遲的消息5分鐘后到了callback服務中,此時檢查MSG DB,發現消息已經處理過,則丟棄; 5. 如果發現MSG DB中沒有此條消息,那么說明消息沒有被處理,此時callback服務再調用上游服務,重新發送兩條消息,直到成功為止; **使用回調檢查的目的,不是100%的保證消息的投遞性,而是減少一次消息的入庫,這樣在并發的情況下可以大大提高并發性. 這樣就將回調檢查的流程剝離主流程**