同步CQRS中的查詢端數據 - 是否仍然存在爭用？

Question

我對CQRS範式有一般性的質疑。

我知道一個CommandBus和EventBus將從我們的查詢端數據存儲中解耦域模型，最終一致性的優點，並且能夠非規範化Query端的存儲以優化讀取等等。這聽起來很棒。

但我不知道，因爲我開始拓展負責更新查詢數據存儲，如果他們不會開始彼此抗衡執行其更新的查詢上的元件的數量？換句話說，如果我們試圖爲EventBus使用發佈/訂閱模型，並且針對特定事件類型有很多不同的訂閱者，他們是不是可以開始通過更新各種不同的位來相互競爭非規範化數據？這難道不會像CQRS之前那樣把我們放在同一條船上嗎？

正如我已經聽過解釋，這聽起來像CQRS應該廢除這一論點都在一起，但是這只是一種理想，在現實中我們只真的減少了嗎？我覺得我可能會在這裏錯過一些東西，但不能把它放在手指上。

Answer 1

這一切都取決於你如何設計基礎設施。嚴格地說，CQRS本身並沒有說如何更新查詢模型。使用事件只是您擁有的選項之一。 CQRS也沒有說任何關於處理爭用的事情。這只是一個架構模式，讓您有更多的選擇和選擇來處理併發問題。在「常規」體系結構中，比如分層體系結構，你通常沒有這些選項。

如果你已經擴大您的命令處理組件出在多臺機器，你可以認爲他們可以製造出比單個事件處理組件可以處理更多的事件。這不一定是件壞事。這可能意味着查詢模型將在高峯時段稍微延遲一些時間進行更新。如果它是是你的問題，那麼你應該考慮擴大查詢模型。

事件處理程序組件本身不會相互競爭。他們可以安全地並行處理事件。但是，如果您設計系統使其全部更新相同的數據存儲，則數據存儲可能成爲瓶頸。建立一個集羣或將查詢模型完全分散在不同的數據源上可以解決您的問題。

要小心，不要過早地優化，雖然。除非你有數據證明它會對你的具體情況有所幫助，否則不要擴展。基於CQRS的體系結構允許您做出很多選擇。你所需要做的就是在正確的時間做出正確的選擇。

到目前爲止，在我參與的應用程序中，我還沒有遇到過查詢模型是瓶頸的情況。其中一些應用程序每天產生超過100ml的事件。