ActiveMQ 可靠性保障：消息確認與重發機制（二）

ActiveMQ 重發機制

重發機制的原理與觸發條件

ActiveMQ 的重發機制是確保消息可靠傳輸的重要手段。當消息發送到 ActiveMQ 服務器后，如果消費者由于某些原因未能成功處理消息，ActiveMQ 會依據配置的重發策略，將消息重新放入隊列或主題中，等待下一次消費。

在以下幾種情況下，ActiveMQ 服務器會將消息重發給消費者：

消費者未應答：如果消息接收者在處理完一條消息后沒有對消息中間件（MOM）進行應答，該消息將由 MOM 重發。在使用CLIENT_ACKNOWLEDGE模式時，消費者接收到消息后，若沒有調用message.acknowledge()方法進行確認，ActiveMQ 會認為消息未被成功處理，進而重發該消息。

處理消息出錯：當消費者在處理消息過程中拋出異常，表明消息處理失敗，ActiveMQ 會將消息標記為需要重發。比如在一個訂單處理系統中，消費者在處理訂單消息時，若因為數據庫連接問題或業務邏輯錯誤而拋出異常，ActiveMQ 會重發該訂單消息。

會話事務異常：

事務回滾：在使用事務性會話時，如果調用了rollback()方法，事務中的所有消息都將被重發。假設在一個涉及多個數據庫操作和消息處理的事務中，由于部分數據庫操作失敗而調用了rollback()，那么該事務中的消息會被重發。

事務會話關閉：在調用commit()方法前關閉了事務性會話，事務中的消息也會被重發。比如在一個轉賬業務中，消息處理和賬戶余額更新在一個事務中，若在未提交事務時關閉了會話，相關消息會被重發。

非事務會話異常：在非事務性會話中，如果消費者連接超時（可能是代碼執行時間超過配置的超時時間），未確認的消息會被重發。例如，消費者在處理一個復雜的計算任務時，由于耗時過長導致連接超時，此時未確認的消息會被重發。

重發策略的配置參數

ActiveMQ 通過RedeliveryPolicy來配置重發策略，其中包含多個重要的配置參數：

collisionAvoidanceFactor：默認值為0.15，用于設置防止沖突范圍的正負百分比，只有在啟用useCollisionAvoidance參數時才生效。它的作用是在消息重發時，避免多個消息在同一時間點被重發，導致資源競爭和沖突。在一個高并發的消息處理系統中，多個消費者同時處理消息時，如果沒有設置該參數，可能會出現所有消費者在同一時間重發消息的情況，導致服務器負載過高，而設置collisionAvoidanceFactor后，消息重發的時間會在一定范圍內隨機波動，減少沖突的可能性。

maximumRedeliveries：默認值為6，表示最大重傳次數，達到最大重連次數后會拋出異常。當設置為-1時，不限制重發次數；設置為0時，表示不進行重傳。在一個日志收集系統中，如果設置maximumRedeliveries為3，當消息在重發 3 次后仍然處理失敗，就會拋出異常，消息可能會被發送到死信隊列（DLQ）；而如果設置為-1，消息會一直重發，直到成功處理。

maximumRedeliveryDelay：默認值為-1，表示最大傳送延遲，只在useExponentialBackOff為true時有效（V5.5 及以上版本）。假設首次重連間隔為10ms，倍數為2，那么第二次重連時間間隔為20ms，第三次重連時間間隔為40ms，當重連時間間隔達到最大重連時間間隔時，以后每次重連時間間隔都為最大重連時間間隔。在一個對消息實時性要求較高的金融交易系統中，可以設置較小的maximumRedeliveryDelay，以確保消息能盡快被重發和處理；而在一些對實時性要求不高的系統中，可以設置較大的值，減少重發對系統資源的影響。

initialRedeliveryDelay：默認值為1000L，即初始重發延遲時間，單位為毫秒。它表示消息第一次處理失敗后，等待重發的時間。在一個數據同步系統中，設置initialRedeliveryDelay為5000，當消息處理失敗后，會等待 5 秒再進行第一次重發。

redeliveryDelay：默認值為1000L，即重發延遲時間，當initialRedeliveryDelay為0時生效（v5.4 及以上版本）。它用于設置除首次重發外，每次重發之間的時間間隔。如果在一個消息處理任務中，initialRedeliveryDelay設置為0，redeliveryDelay設置為3000，那么每次重發之間的間隔為 3 秒。

useCollisionAvoidance：默認值為false，用于啟用防止沖突功能。由于消息接收時可以使用多線程并發處理，啟用該功能可以使重發的消息在時間上分布得更加均衡，避免所有并發線程都在同一個時間點進行消息接收處理，從而平衡 broker 的處理性能。在一個有大量并發消費者的電商訂單處理系統中，啟用useCollisionAvoidance可以避免因消息重發過于集中而導致 broker 負載過高。

useExponentialBackOff：默認值為false，用于啟用指數倍數遞增的方式增加延遲時間。啟用后，每次重發的延遲時間會按照一定的倍數遞增。在一個處理復雜業務邏輯的消息系統中，啟用useExponentialBackOff，可以讓消息在多次重發時，隨著失敗次數的增加，重發間隔時間逐漸變長，避免短時間內大量重發對系統造成過大壓力。

backOffMultiplier：默認值為5，表示重連時間間隔遞增倍數，只有在值大于1且啟用useExponentialBackOff參數時才生效。例如，首次重發延遲為1000ms，backOffMultiplier為2，那么第二次重發延遲為2000ms，第三次為4000ms 。在一個對消息可靠性要求較高，但又要避免過度占用資源的系統中，可以根據實際情況調整backOffMultiplier的值，以平衡消息重發的頻率和系統資源的消耗。

重發機制的工作流程與案例分析

為了更清晰地理解重發機制的工作流程，我們結合一個實際案例進行分析。假設我們有一個電子商務系統，訂單消息通過 ActiveMQ 進行傳輸和處理。

消息第一次發送：當用戶下單后，訂單信息被封裝成消息發送到 ActiveMQ 服務器的訂單隊列中。生產者將訂單消息發送給 ActiveMQ，ActiveMQ 接收到消息后，將其存儲在隊列中，并等待消費者來獲取。

消費者處理失敗：消費者從訂單隊列中獲取消息并進行處理，處理過程中可能由于數據庫連接問題、業務邏輯錯誤等原因導致處理失敗，消費者拋出異常，消息未被確認。在處理訂單消息時，若數據庫突然出現故障，無法將訂單信息正確寫入數據庫，消費者就會拋出異常，此時消息處理失敗。

消息進入重發隊列：ActiveMQ 檢測到消費者處理消息失敗（通過異常捕獲或未收到確認消息），根據配置的重發策略，將消息放入重發隊列。ActiveMQ 根據消費者返回的錯誤信息，判斷該消息需要重發，將其從原隊列中取出，放入重發隊列。

按照重發策略進行重發：ActiveMQ 按照RedeliveryPolicy中配置的參數進行消息重發。首先，根據initialRedeliveryDelay設置的時間間隔，等待一段時間后進行第一次重發。如果第一次重發仍然失敗，根據useExponentialBackOff和backOffMultiplier的配置，計算下一次重發的延遲時間，然后進行第二次重發，以此類推，直到達到maximumRedeliveries設置的最大重發次數。假設initialRedeliveryDelay為2000（2 秒），useExponentialBackOff為true，backOffMultiplier為2，maximumRedeliveries為3。消息第一次處理失敗后，等待 2 秒進行第一次重發；若第一次重發失敗，等待 4 秒（22）進行第二次重發；若第二次重發仍失敗，等待 8 秒（42）進行第三次重發，第三次重發后，達到最大重發次數，消息可能會被發送到死信隊列。

在這個案例中，重發機制的應用確保了訂單消息不會因為一次處理失敗而丟失，提高了系統的可靠性。但同時，也需要合理配置重發策略，避免因過度重發導致系統資源浪費和性能下降。

消息確認與重發機制的關系

相互協作保障可靠性

消息確認機制和重發機制在 ActiveMQ 中相互協作，共同為消息的可靠傳輸提供保障。確認機制是重發機制的基礎，它為消息的處理狀態提供了明確的標識。當消費者成功處理消息并進行確認時，ActiveMQ 知道該消息已被正確處理，無需重發。如果消費者未能確認消息，無論是因為未應答、處理出錯還是會話異常，ActiveMQ 都會根據重發機制將消息重新發送，以確保消息最終能被成功處理。在一個電商訂單處理系統中，消費者接收到訂單消息后，若使用CLIENT_ACKNOWLEDGE模式，只有在成功處理訂單并調用acknowledge()方法確認后，消息才不會被重發。若處理過程中出現異常，未進行確認，重發機制就會啟動，將消息重新發送給消費者，保證訂單不會因為一次處理失敗而丟失。

重發機制是確認機制的補充，當確認機制未能正常工作，即消息未被正確確認時，重發機制能夠通過重新發送消息來彌補確認機制的不足，增加消息被成功處理的機會。兩者緊密配合，從不同角度確保了消息在分布式系統中的可靠傳輸，提高了系統的穩定性和可靠性。

實際應用中的權衡與選擇

在實際應用中，根據業務需求和系統特點，合理選擇消息確認模式和配置重發策略是至關重要的，這直接影響到系統的性能和可靠性。對于對消息處理實時性要求較高、業務邏輯簡單且對消息重復不太敏感的場景，如實時日志收集系統，可以選擇AUTO_ACKNOWLEDGE模式，配合簡單的重發策略，這樣能提高消息處理的效率，減少系統開銷。但如果業務對消息的準確性和完整性要求極高，不允許出現消息重復處理的情況，如金融交易系統，就需要選擇CLIENT_ACKNOWLEDGE或INDIVIDUAL_ACKNOWLEDGE模式，并精心配置重發策略，確保消息在被正確處理后才被確認，同時避免過度重發導致的性能問題。

系統的性能和資源限制也是選擇確認模式和重發策略時需要考慮的因素。在資源有限的系統中，若選擇過于復雜的確認模式和重發策略，可能會導致系統資源耗盡，影響系統的正常運行。因此，需要在可靠性和性能之間找到一個平衡點，通過合理的配置和優化，使系統既能滿足業務需求，又能高效穩定地運行。

總結與展望

總結要點

ActiveMQ 的消息確認與重發機制是保障消息可靠傳輸的核心組件。消息確認機制通過不同的確認模式，讓生產者和消費者能夠準確知曉消息的處理狀態，為消息的可靠傳輸提供了基礎保障。其中，JMS 規范中的AUTO_ACKNOWLEDGE、CLIENT_ACKNOWLEDGE、DUPS_OK_ACKNOWLEDGE和SESSION_TRANSACTED模式，以及 ActiveMQ 擴展的INDIVIDUAL_ACKNOWLEDGE模式，各自適用于不同的業務場景，開發者需要根據實際需求進行合理選擇。

重發機制則在消息處理出現異常時發揮關鍵作用，通過合理配置RedeliveryPolicy中的參數，如collisionAvoidanceFactor、maximumRedeliveries、maximumRedeliveryDelay等，可以有效地控制消息的重發策略，確保消息在處理失敗時能夠被重新發送，增加消息被成功處理的機會。

這兩種機制相互協作，確認機制為重發機制提供了消息處理狀態的判斷依據，重發機制則是確認機制的有力補充，在確認機制未能正常工作時，通過重新發送消息來保障消息的可靠傳輸。在實際應用中，需要根據業務的需求和系統的特點，在可靠性和性能之間進行權衡，選擇合適的確認模式和重發策略，同時注意資源的合理利用和系統的穩定性。