在Axon框架中揭開跟蹤事件處理器的神秘面紗

跟蹤令牌

跟蹤事件處理器使用跟蹤令牌來跟蹤已處理的事件。跟蹤令牌表示事件流中事件的位置。不同的事件儲存實現可以使用跟蹤令牌的不同實現來可靠地表示該位置。為了能夠在程式重新啟動後繼續事件處理（我們稍後會看到這不是唯一的原因），跟蹤令牌儲存在令牌儲存中。Token Store有幾種實現 - JPA，JDBC，Mongo，當然，你可以提供自己的。通常，儲存跟蹤令牌的最佳位置是也儲存投影（或Saga）的位置。 圖1 顯示了這些概念如何一致。

圖1 - 跟蹤事件處理

每個TEP宣告其跟蹤令牌，以避免在不同的執行緒/節點中多次處理相同的事件。宣告跟蹤令牌是在令牌儲存中設定跟蹤令牌的所有者的過程。所有者不是無限期設定，而是可配置的超時。當此超時到期且當前所有者未回收令牌時，其他所有者（TEP）可以宣告它。TEP可以釋出宣告，告知其他TEP繼續處理。有意識地釋出跟蹤令牌為TEP重新平衡奠定了基礎，在TEP之間平均分配了大量事件處理。

並行處理

在Axon中，透過分割事件流來實現並行處理。對於某個TEP，我們將啟動幾個並行處理它們自己的事件流段的執行緒。每個TEP的段數是可配置的。讓我們定義一個段實際上是什麼。

段是事件總流量的一小部分（參見 圖2） ）。換句話說，跟蹤令牌被分段為幾個部分，這意味著令牌儲存包含每個跟蹤令牌和段的條目。段包含段識別符號和掩碼。掩碼用於確定某個事件是否屬於給定的段。段在並行和分散式事件處理中起著重要作用。每個TEP可以分配幾個段。對於它們中的每一個，它啟動一個單獨的執行緒進行事件處理，使我們能夠進行並行處理。可以在多個節點上的TEP之間分配段，使我們能夠以分散式方式處理事件（請注意，不同節點上的TEP仍然必須宣告跟蹤令牌，因此它們不處理相同的事件）。

圖2 - 將事件流拆分為段

重播

在我們想要重建投影（檢視模型）的情況下，重放過去的事件會派上用場。這個想法是從時間的開始（或從某個時間點開始）並重新呼叫所有事件處理程式。這樣做，必須在某個時間點重置TEP（請注意在重置TEP之前應該停止） - 這意味著跟蹤令牌會更新。你可以問問自己，令牌儲存中的跟蹤令牌的手動更新是否足以觸發TEP重新處理過去的事件，而你是對的，事件的重放也會以這種方式發生。您可以從Replay API中提取的好處是TEP保留了新發布的事件和重放的事件之間的差異。這使您可以控制哪些事件被重放，哪些事件不被重放。Sagas（預設情況下）不可重播。出於重播目的，Axon提供重播令牌。

處理迴圈

啟動TEP時，它會在單獨的執行緒中為每個段啟動一個worker。他們每個人都試圖在一定時間內申請跟蹤令牌。如果宣告成功，則啟動處理迴圈。處理迴圈的快樂流程包含 圖3 中 所示 的步驟。

圖3 - 處理迴圈

1. 事件流在Tracking Token指向的位置開啟。如果沒有可用的事件，我們等待一秒鐘，以便在流中提供事件。然後，跟蹤令牌宣告得到擴充套件，我們從頭開始迴圈。否則，我們繼續迴圈。

2. 從流中讀取事件並將其放入批處理中。沒有能夠處理它們的處理程式的事件訂閱此TEP不會進入批處理。如果在此步驟之後批處理保持空白，我們會延長對跟蹤令牌的宣告，更新TEP狀態，並從頭開始迴圈。否則，我們繼續迴圈。

3. 先前建立的一批事件由在UOW（工作單元）中訂閱此TEP的事件處理程式處理。在提交UOW之前，跟蹤令牌儲存在令牌儲存中。

4. TEP狀態包含有關事件處理進度的資訊 - 段，TEP是否跟上事件處理，TEP是否正在重放事件以及實際的跟蹤令牌。

在事件處理停止後（顯式或錯誤），TEP釋放該段，以便另一個處理器可以宣告它並繼續處理。

錯誤處理

在跟蹤事件處理中，事件在不同的執行緒中處理，這使得錯誤處理更加複雜。為解決此問題，Axon提供了可在TEP上配置的錯誤處理程式，並在事件處理元件中發生異常時執行操作。預設情況下，會傳播異常，最終導致TEP釋放其宣告並開始重試。如有必要，可以向TEP提供自定義錯誤處理程式。建議是明確定義錯誤情況並用相應的例外表示。有了這個，錯誤處理程式可以使用不同的策略對它們進行操作，以解決意外行為。

結論

跟蹤事件處理是Axon Framework中一個非常強大的機制，它為我們提供：

• 重放事件的能力 - 事件源系統的一個重要優勢是能夠根據過去構建新投影，或者在需求發生變化時重建現有投影。

• 位置透明度 - 在您想要的任何節點中處理您的事件，只需確保您有權訪問事件流和令牌儲存。

• 效能 - 在同一節點上啟動多個段以並行處理它們並加快處理速度。

在CQRS體系結構中，查詢模型與命令模型分開更新，這使我們可以以不同方式擴充套件查詢模型。在這種情況下（以及許多其他情況），跟蹤處理是事件處理的首選方式。因此，使用事件儲存時，跟蹤處理是預設設定。