0 前言
Kafka 不適合事件溯源，Kafka適合消息流。這兩種事物需要不同存儲機制。
-
事件溯源（Event Sourcing），需DB充當事件日誌，爲事件溯源存儲的事件必須以某種方式編寫，以便將來的讀取能夠快速組裝屬於單個聚合的較小（更小的）事件流最初發射它們的。這需要隨機訪問索引
-
消息流（Message Streaming），需要的存儲本質上是個記錄消息元素的“flat file”。消息元素按序單獨寫，然後按序讀。這需要一個從第一到最後一個的順序索引
1 細分
除了聚合子流，事件源域模型的所有事件通常都按照聚合最初發出的時間順序作爲全序事件流。爲此還需要一個順序索引。因此，事件溯源數據庫須支持兩種類型的索引。
而Kafka不適合事件溯源數據庫記錄。記錄消息的是topic。Kafka 是一個消息日誌，可有很多topic。 Kafka 有一個索引，即全序消息流的序列號。
因此，將消息寫入Kafka topic後，由於隨機訪問索引並不存在，無法隨機讀取消息。Kafka也根本不是爲此而設計的。
使用 Kafka，如需讀取最初由單個聚合實例發出的小（或較小）事件流，你將不得不從第一條消息掃描到最後一條，以確保你沒錯過讀取單個聚合流中的所有事件。這將導致 O(N) 讀取時間——隨每個新消息的寫入，讀取速度變慢。你有 10 億個總事件，需讀取其中任意 5 個作爲單個聚合事件流？"不可能發生"。
對那些認爲自己可以超越物理學的頑固的人，還有如下關鍵點：
2 補充
“我知道，我知道！我將爲每個聚合實例使用不同的topic！”如果 Kafka 的設計目的是在單broker下支持數百萬、數十億到數萬億個topic，那也沒關係。但事實並非如此。
“我知道，我知道！我將使用 K-Table 維護每個聚合實例的快照，以便我快速讀取它們！”重構聚合的狀態必須優先於消耗所有事件的完全有序流。如果你嘗試這樣做，你的 K-Table 快照最終只會與真實的當前聚合狀態一致 - 聚合無法可靠地讀取它自己的狀態。
雖然很常見，但事件溯源解決方案支持從日誌中重新補充各個域對象並不是絕對必要的。如某些實現從單個流重建整個系統狀態。這一切都取決於具體要求。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都國企技術專家兼架構，多家大廠後臺研發和架構經驗，負責複雜度極高業務系統的模塊化、服務化、平臺化研發工作。具有豐富帶團隊經驗，深厚人才識別和培養的積累。
參考：
本文由博客一文多發平臺 OpenWrite 發佈！