資源鎖定和業務邏輯

考慮以下情況：實體A上存在更新請求，以創建子實體A.B. A上可能有很多B，每個B都有唯一的電子郵件地址。實體A是一個共享實體，相同的請求可能發生在多個並行服務器（可擴展的微服務）中。資源鎖定和業務邏輯

爲了創建A.B，我們必須驗證B是否已經作爲A上的子實體存在（根據B的電子郵件地址）。

處理此更新請求的服務應該鎖定A（通過它的唯一ID）以便更新安全。

我的問題是不是技術更概念化：

是否鎖定資源A在這種情況下是這樣的更新任務的業務邏輯的一部分？
你會考慮把資源鎖放在一個單獨的中間件中，而不是處理驗證和更新過程的中間件嗎？（另一個選項是把鎖作爲業務邏輯的一部分，並把它直接負責業務邏輯中間件。）

2016-11-22 user132440

鎖定是不是企業相關的問題（除非你的業務是建立分佈式數據庫），因此不應被視爲業務邏輯的一部分。另外，您不應該自己實現分佈式鎖定，而應該依賴於打包的解決方案，該解決方案最好是您的數據持久性解決方案的組成部分。

這裏是關於how to do this with Redis討論稱爲Redlock的算法的文章。這裏有一篇博客文章，鏈接到關於building concensus in Cassandra的文章。而且，這裏有一個關於concurrency in Mongo的鏈接。正如您從這些文章中看到的那樣，分佈式鎖定是一個大而複雜的問題，您可能不想解決這個問題。

來源

2016-11-22 19:00:45

感謝您的評論。由於我知道並確定它很複雜，我當然不打算自己做 - 但使用redis。我的問題是關於代碼中我們希望獲得資源鎖定的地方：在主代碼流中 - 將代碼中的代碼段指向需要鎖定並在本節中鎖定和解鎖的代碼段，或者將代碼段設置爲預處理動作，即在之前專門用於鎖定的中間件中。 – user132440

順便說一句：它可能是這種情況下，一致性是不可能的redis –

哦，就像我說的，它不是業務邏輯，因此它應該是持久性邏輯的一部分。最好不要編寫獲取和釋放鎖代碼 - 它應該是你正在使用的框架的一部分。 –

所選競爭問題解決方案的技術實現顯然不是業務邏輯，但選擇正確的解決方案需要業務知識。

我的意思是，您必須瞭解業務是如何工作的，才能確定在併發場景中保護數據完整性的正確方法。併發衝突發生的頻率如何？衝突可以自動解決嗎？什麼應該是衝突？不僅如此，業務部門可能會很好地接受最終的一致性而非強大的一致性。

簡而言之，在併發場景中保護數據完整性的機制不應該成爲域的一部分。這些可能會發生在應用程序服務層或基礎架構層，但業務專家必須參與有關如何解決併發衝突以及這些如何影響業務的討論。

來源

2016-11-22 21:56:26 plalx

資源鎖定和業務邏輯

回答

相關問題