ENode框架單台機器在處理Command時的設計思路

設計目標

1. 盡量快的處理命令和事件，保證吞吐量；
2. 處理完一個命令后不需要等待命令產生的事件持久化完成就能處理下一個命令，從而保證領域內的業務邏輯處理不依賴於持久化IO，實現真正的in-memory；
3. 保證命令、事件處理的順序性，先來的先處理，先產生的先處理；
4. 保證一個聚合根的事件只有一個線程在持久化，並按事件產生的順序持久化；
5. 持久化事件時如果遇到並發沖突時（聚合根ID+事件版本號出現重復）的處理代價要輕；
6. 要能利用多核的優勢；

總體設計思路

1. 先將命令根據聚合根ID路由到CommandMailBox里；
2. 單線程處理CommandMailBox中的命令，由於聚合根在in-memory本地內存，所以處理非常快；
3. 處理成功后更新聚合根的in-memory內存；
4. 內存更新后將聚合根產生的事件同樣原理路由到EventMailBox里；
5. 單線程批量處理EventMailBox中的事件；由於是批量，所以持久化的吞吐量也可以保證；
6. 處理完成一批事件后，把這一批事件對應的命令從CommandMailBox中移除；

詳細設計思路

1. 設計N個存放命令的CommandMailBox，命令首先按聚合根ID的hashcode取摸路由到對應的CommandMailBox；
2. 每個CommandMailBox都有一個maxOffset, consumeOffset，以及一個CommandProcessor(單線程)在不停的處理；maxOffset表示最后一個命令的位置；consumeOffset表示當前正在處理的命令的位置；
3. CommandProcessor的處理邏輯；
   • 創建、修改聚合根；
   • 更新聚合根的in-memory緩存；
   • 將聚合根產生的事件按聚合根ID的hashcode取摸路由到對應的EventMailBox；EventMailBox的個數也是程序啟動時配置；
4. 每個EventMailBox都有一個maxOffset, consumeOffset，以及一個EventProcessor(單線程)在不停的處理;maxOffset表示最后一個事件的位置；consumeOffset表示當前正在處理的事件的位置；
5. EventProcessor的處理邏輯：
   • 按次序批量獲取一批要處理的事件；
   • 批量持久化事件到EventStore，采用SqlBulkCopy；
   • 如果持久化一切順利，則publish這一批事件(publish如果遇到網絡IO異常，則重試，直到成功為止)，然后繼續持久化下一批，並同時將當前這一批事件對應的命令從CommandMailBox中刪除；.
   如果持久化遇到並發沖突(事件的aggregateRootId+Version重復)，則對當前這一批事件一個個按順序持久化。如果當前事件持久化成功，則同樣publish該事件，當然遇到IO異常時也要不斷重試，直到成功為止；成功后通知CommandMailBox移除當前事件對應的命令；如果當前事件持久化出現並發沖突，就做如下處理：
   1. 先通知當前事件對應聚合根暫停處理后續的命令；
   2. 用Event Sourcing技術將in-memory中的聚合根的狀態還原到最新狀態，確保下次執行command時基於的聚合根的狀態是最新的；
   3. 把這一批里該聚合根的所有事件移除，把EventMailBox中的該聚合根的所有事件移除；
   4. 將CommandMailBox的處理位置重置為當前事件對應的命令的offset；從而可以確保產生並發沖突的事件對應的命令以及后續的命令能再重新被處理一遍；
   5. 通知當前事件對應聚合根繼續處理后續的命令（從哪個位置開始處理，在上面第4步已經重置過了）；
   6. 這一批的所有事件都一個個處理完之后，按同樣的邏輯繼續處理下一批事件；

其他說明

1. 上面的設計基於一個前提，就是一個聚合根幾乎不會同時在兩台服務器上同時存在並處理命令，否則就會出現並發沖突，而並發沖突的處理的代價還是比較復雜的，應該盡量避免；這點可以通過EQueue保證；
2. 當聚合根處理了命令，嘗試更新in-memory內存時，可能有一種情況會失敗。就是如果這個命令是創建聚合根的，而有可能並發的時候這個聚合根可能在內存中已經有了，則創建完聚合根添加到內存時，應該能檢測出來並記錄錯誤日志，然后該命令產生的事件也不必放入EventMailBox，然后認為該命令處理成功即可。
3. 上面的設計中沒有談到當遇到命令重復執行時的設計思路，大家可以自己想想:)