2013-04-18 39 views
1

我有2個處理程序的運行順序刪除和重新排序圖片,並希望獲得最佳解決方案的一些建議。CQRS按特定順序運行處理程序

在用戶界面上的一些照片被刪除,用戶點擊該按鈕刪除。整個流程中,刪除命令直至實際刪除物理文件的事件處理程序開始。

然後立即用戶對剩餘的圖片進行排序。從重新排序命令到文件系統的重新排序事件處理程序的新流程再次觸發。

已經有一個併發問題。沒有完成刪除操作,重新排序無法正確應用。目前這個問題是通過某種鎖來處理的。臨時文件將在刪除流程結束時創建並刪除。當該文件存在時,另一個線程(取決於用戶操作的重新排序或刪除)將等待。

這不是一個理想的解決方案,並想改變它。 潛在的解決方案必須也非常快(當然目前的解決方案並不是一個快速的解決方案),因爲UI在訂購結束時通過JSON調用進行更新。

在以後的實施,我們正在考慮使用事件的隊列但目前我們都還卡住了。

任何想法,將不勝感激! 謝謝,mosu'!

編輯:我們已經被使用在客戶端Javascript腳本數據管理解決 其他最終一致性問題。基本上樂觀和欺騙用戶! :) 我開始相信這也是這裏走的路。但是,我怎麼知道文件系統中的數據何時更改?

+0

您正在使用CQRS和一個事件中心架構,最終保持圖片庫的一致性?我相信你有你的理由,我真的好奇他們是什麼。 CQRS並不適合所有的事情。KISS還是應該的。 –

+0

不是。圖庫只是一個車輛管理網站的一部分。到目前爲止,我們沒有在這種併發環境中使用某些資源的情況。另外,到目前爲止,CQRS對我們來說非常有用。我們仍在學習,並希望向其他用戶學習! – mosu

回答

0

這裏有一個想法。 你正在重新訂購什麼?圖片?基於,比如說,日期。 爲什麼有這個命令?這個命令的結果會被所有人看到,或者只是這個特定的用戶?

我只能猜測,但看起來你已經有了一個展示的問題在這裏。沒有必要按照寫入順序存儲圖片,它只是一個名稱和文件存儲鏈接的列表。你應該做的是在用戶設置或集合設置中的某處存儲一個小字段:日期升序或名稱降序。所以你命令重新排序應該只改變這個小小的領域。然後,當您加載圖庫時,應首先閱讀此字段,並根據此字段加載一個或另一個視圖。由於商店現在便宜,您可以在讀取方面爲您需要的每種參數存儲不同的排序集合。

綜上所述,刪除命令改變在寫入側的集合,但Reoder命令只是用戶或收集設置。因此,這裏沒有併發性。

更新

根據您的意見和澄清。

  1. 當然,您可以並且可能應該僅在當時限制用戶操作。如果刪除和重新排序的時間相當短。這總是一個你被要求實現的用戶體驗類型的問題。以定購系統的常用示例爲例。下訂單後,用戶幾乎可以立即在用戶界面中看到它,狀態將如InProcess。您很可能不會讓用戶以任何方式更改訂單,這意味着您不會顯示任何用戶控件,如「取消」按鈕(當然,這僅僅是一個示例)。因此,你可以在這裏使用這種方法。
  2. 如果2個用戶可以修改相同的物理集合,那麼您在這裏沒有選擇 - 您正在處理共享數據,應該有一種同步。例如,如果您正在使用傳奇,可以有幾個傳奇:收集重新排序的傳奇和刪除傳奇 - 他們可以合作。刪除過程首先開始 - 收集聚合被標記爲正在刪除,然後在這個重新排序saga開始之後,它將嘗試啓動重新排序過程,但由於刪除事件正在處理中,它應該等待DeletedEvent並且繼續後續過程。如果重新排序操作首先啓動,則相同 - 刪除傳奇應等到某個事件發生並在該事件到達後繼續。

更新

好吧,如果我們同意不碰文件系統本身,而是它代表的圖片集的總和。最重要的併發問題可以通過開放式併發方法解決 - 在數據存儲中,通常使用基於聚合ID和聚合版本的唯一約束。

下面是在命令處理程序的典型步驟:

這是一個命令處理程序如下步驟的共同序列:

  1. 驗證其自身的優點的命令。
  2. 加載聚合。
  3. 驗證聚合當前狀態的命令。
  4. 創建一個新事件,將該事件應用於內存中的聚集。
  5. 嘗試持續聚合。如果有在此步驟中併發衝突,要麼放棄,或從第2步

這裏重試的事情是幫了我很多,前一段時間的鏈接:http://www.cqrs.nu/

+0

我想我以一種誤導性的方式呈現了我的問題。以下是造成問題的步驟:用戶刪除3張照片,發送刪除命令,並在某個時間刪除物理照片(在我們的解決方案中刪除意味着重新排序)。一秒鐘後,用戶將拍照。重新排序命令被髮送,但如果刪除沒有在物理上完成,令人討厭的事情發生。我喜歡不重新排序並且只是改變和索引的想法,但這是一個(很大並且由monolit的其他部分使用)傳統系統。我不確定這是否是我們的解決方案。謝謝您的回答! – mosu

+0

好的,我明白Delete命令的作用 - 它刪除文件並最終更改Collection聚合。但是,重新排序是什麼意思?只是物品訂單中的集合彙總或文件系統上的某些物理訂單? – Max

+0

圖片根據文章ID,圖片大小和一些數學算法存儲在文件系統中,以便通過只知道文章ID就可以創建圖片的路徑。這意味着每篇文章都有一個文件夾結構。當用戶重新排序(排序圖片)時,路徑會改變,所以圖片必須四處移動。排序也在聚合中發生變化。謝謝! – mosu

0

最大建議是非常歡迎和通常他們適用。

有時很難解釋實現的所有細節,但有一個應該提及的細節: 我們存儲圖片的方式意味着,當重新排序所有圖片路徑(因此所有鏈接)都會改變。

一個同事的帽子很簡單的刪除這部分的好主意。這意味着即使順序會改變,圖片的路徑也會保持不變。在UI端,顯示順序中的圖片索引與其路徑之間將存在映射,這意味着除了刪除時,不需要更改文件系統。

由於我們希望儘可能寬容我們的用戶,這對我們來說是最好的解決方案。 我認爲,一般來說,當出現併發問題時,這也是一種好方法。併發性可以被刪除嗎?