apache camel

《駱駝設計模式》一書介紹了20種模式以及用于設計基于Apache Camel的集成解決方案的眾多技巧和最佳實踐。 每種模式都基于真實的用例，并提供了Camel特定的實現細節和最佳實踐。 為了讓您有這本書的感覺，以下是該書的重試模式摘錄，其中介紹了如何在Apache Camel中進行短期和長期退休。

上下文和問題

從本質上講，集成應用程序必須通過網絡與其他系統進行交互。 隨著基于動態云的環境成為規范，并且微服務體系結構將應用程序劃分為更細粒度的服務，成功的服務通信已成為許多分布式應用程序的基本前提。 與其他服務進行通信的服務必須能夠透明地處理下游系統中可能發生的瞬態故障，并繼續運行而不會造成任何中斷。 由于可以將瞬態故障視為基礎結構級別的故障，網絡連接的丟失，繁忙服務所施加的超時和節流等。這些情況很少發生，并且通常會自行糾正，并且通常可以重試操作成功。

力量與解決方案

再現和解釋瞬態故障可能是一項艱巨的任務，因為這些故障可能是由不定期發生的，與外部系統相關的多種因素造成的。 諸如Chaos Monkey之類的工具可用于模擬不可預測的系統中斷，并在需要時讓您測試應用程序的彈性。 處理瞬態故障的一個好的策略是重試該操作，并希望它會成功（如果錯誤確實是瞬態的，它將成功；只要保持冷靜并繼續重試）。

要實現“重試”邏輯，需要考慮以下幾個方面：

重試哪些失敗？

某些服務操作（例如HTTP調用和關系數據庫交互）是重試邏輯的潛在候選者，但是在實現它之前需要進一步分析。 關系數據庫可能會因為限制使用過多資源而拒絕連接嘗試，或者由于并發修改而拒絕SQL插入操作。 在這些情況下重試可能會成功。 但是，如果關系數據庫由于憑據錯誤而拒絕連接，或者由于外鍵約束SQL插入操作失敗，則重試該操作將無濟于事。 與HTTP調用類似，重試連接超時或響應超時可能會有所幫助，但是重試由業務錯誤引起的SOAP Fault毫無意義。 因此，請謹慎選擇重試次數。

多久重試一次？

一旦確定了重試的必要性，就應該調整特定的重試策略以滿足兩個應用程序的性質：具有重試邏輯的服務使用者和具有短暫故障的服務提供者。 例如，如果實時集成服務無法處理請求，則可能只允許它在返回響應之前進行幾次重試，且延遲很短，而基于批處理的異步服務可能能夠承擔更多的重試。更長的延遲和指數退縮。 重試策略還應考慮其他因素，例如服務消耗合同和服務提供商的SLA。 例如，非常激進的重試策略可能會導致服務使用者進一步受到限制，甚至將其列入黑名單，或者它可能會使服務完全過載并降級繁忙的服務，甚至根本無法恢復。 某些API可能會指示您一段時間內的剩余請求計數以及響應中的黑名單信息，但有些可能不會。 因此，重試策略定義了應多久重試一次以及多長時間之后您才能接受這是一個非暫時性故障并放棄。

冪等

重試操作時，請考慮對該操作可能產生的副作用。 重試邏輯將消耗的服務操作應設計為冪等的。 使用相同的數據輸入重試相同的操作應該沒有任何副作用。 想象一個請求已成功處理，但響應尚未返回。 服務使用者可以假定請求已失敗，然后重試相同的操作，這可能會產生一些意外的副作用。

監控方式

跟蹤和報告重試也很重要。 如果某些操作在成功之前不斷被重試，或者在失敗之前被重試了太多次，則必須確定并修復這些操作。 由于在沒有適當監視的情況下，服務中的重試應該對服務使用者透明，因此它們可能未被檢測到，并以負面的方式影響了整個系統的穩定性和性能。

超時和SLA

當下游系統中發生暫時性故障并且重試邏輯生效時，重試服務的總處理時間將大大增加。 與其從重試和延遲次數的角度考慮重試參數，重要的是從服務SLA和服務使用者超時的角度來驅動這些值。 因此，請考慮處理請求所允許的最長時間，并確定可以擠入該時間范圍的最大重試次數和延遲時間（包括處理時間）。

機械學

使用Camel和ActiveMQ有幾種不同的重試方法。

駱駝重新交付政策（重試）

這是在駱駝中重試的最流行和通用的方法。 重新交付策略定義了重試規則（例如重試和延遲的次數，是否使用沖突避免和指數退避乘數以及日志記錄），然后可以將這些規則應用于處理流程的多個errorHandler和onException塊。 每當引發異常時，將應用重新交付策略中的規則。

駱駝重新交付政策示例

重試機制的主要區別在于，Camel錯誤處理邏輯不會重試整個路由，而是僅重試處理流程中的失敗端點。 這要歸功于在駱駝路線中連接端點的通道。 只要處理節點拋出異常，該異常就會傳播回并被通道捕獲，然后可以應用各種錯誤處理策略。 這里的另一個重要區別是基于Camel的錯誤處理和重新傳遞邏輯是內存中的，并且它在重試期間會阻塞線程，這會產生后果。 如果所有線程都被阻塞并等待重試，則可能會用完線程。 線程的所有者可以是使用者，也可以是帶有來自路由的線程池的某種并行處理結構（例如并行拆分器，收件人列表或線程DSL）。 例如，如果我們有一個帶有十個請求處理線程的HTTP使用者，一個繁忙且拒絕連接的數據庫以及一個具有指數退避的RedeliveryPolicy，則在十個請求之后，所有線程將最終等待重試，而沒有線程將可用于處理新請求。 解決此線程阻塞問題的方法是選擇
asyncDelayedRedelivery，其中Camel將使用線程池并異步安排重新交付。 但是線程池將重新交付請求存儲在內部隊列中，因此此選項可以非常快速地消耗所有堆。 還請記住，所有錯誤處理程序都有一個線程池，一個線程池有一個線程池
CamelContext，因此，除非您為持久的重新交付配置了特定的線程池，否則該池可能會在一條路徑中耗盡，而在另一條路徑中阻塞線程。 另一個含義是，由于重試邏輯在內存中的性質，重新啟動應用程序將丟失重試狀態，并且將無法分發或保持該狀態。

總體而言，這種Camel重試機制非常適合短時本地重試，并且可以克服網絡故障或資源短暫鎖定的情況。 對于更長的延遲，最好使用具有群集和非線程阻塞功能的持久重新交付來重新設計應用程序（下面將介紹這種解決方案）。

ActiveMQ經紀人重新交付（長期重試）

該重試機制與前兩個機制具有不同的特征，因為它是由代理本身（而不是消息使用者或Camel路由引擎）管理的。 ActiveMQ借助其調度程序，可以延遲傳遞消息。 此功能是代理重新交付插件的基礎。 重新交付插件可以攔截死信處理并重新安排失敗消息以重新交付。 計劃將失敗的消息傳遞到原始隊列的尾部，然后重新傳遞給消息使用者，而不是傳遞給DLQ。 當總消息順序不重要，并且消費者之間的吞吐量和負載分配很重要時，這很有用。

ActiveMQ重新交付示例

旁注–我知道，無恥的插件，但是我對這本書的研究感到非常興奮。 您可以在這里享受40％的折扣，直到6月底為止！ 希望你喜歡。 與以前的方法的不同之處在于，該消息在代理消息存儲中是持久的，并且在代理或駱駝路由重新啟動后仍會繼續存在而不會影響重新交付的時間。 另一個優點是，對于每個重試的消息，沒有線程被阻塞。 由于消息已返回給代理，因此可以使用競爭消費者模式將消息傳遞給其他消費者。 但是副作用是消息順序丟失了，因為消息將被放置在消息隊列的尾部。 同樣，使用調度程序運行代理也會對性能產生一定的影響。 這種重試機制對于長時間的重試很有用，因為您無法承受每個失敗消息的阻塞線程。 當您希望保留該消息并將其群集以進行重新發送時，它也很有用。

注意，與使用代理重新交付插件相比，手動實現代理重新交付邏輯很容易。 您所要做的就是捕獲異常并發送帶有
AMQ_SCHEDULED_DELAY標頭指向中間隊列。 一旦延遲過去，該消息將被使用，并且將重試相同的操作。 您可以多次重新計劃和處理同一條消息，直到放棄并將消息放入退避或死信隊列中。

翻譯自: https://www.javacodegeeks.com/2017/06/short-retry-vs-long-retry-apache-camel-2.html

apache camel

總結

以上是生活随笔為你收集整理的apache camel_Apache Camel中的短重试与长重试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。