Apache Kafka不是資料庫：資料庫+Kafka=完整ACID - fivetran

在這種情況下，訊息代理將提供持久的事件儲存，這些事件是客戶傳送的事件，然後Fivetran將事件加、載到資料倉儲。
但是，Kafka偶爾被描述為不僅僅是一個更好的訊息代理。支援該觀點的人將Kafka定位為一種全新的資料管理方式，其中Kafka取代了關聯式資料庫作為已發生事件的確定記錄。無需讀寫傳統資料庫，而是將事件追加到Kafka，然後從代表當前狀態的下游檢視中讀取。這種體系結構已被描述為“將資料庫從內向外轉換”。
原則上，能夠用同時支援讀取和寫入的方式來實現這種類似資料庫的體系結構。但是，在此過程中，您最終將面臨資料庫管理系統數十年來所面臨的每一個難題。您將或多或少必須在應用程式程式碼中編寫完整的DBMS。而且您可能做得不好，因為資料庫需要花費數年的時間才能正確完成。您將不得不處理草率讀取，幻像讀取，寫入歪斜以及倉促實現的資料庫的所有其他症狀。 
 

ACID
使用Kafka作為主要資料儲存的根本問題是它沒有提供隔離（ACID中的I代表隔離）。
隔離意味著，在全域性範圍內，所有事務（讀和寫）都沿著某個一致的歷史記錄發生。Jepsen 提供了隔離級別的指南（隔離意味著該系統將不會遇到某些異常）。
讓我們考慮一個為什麼隔離很重要的簡單示例。假設我們正在執行一個線上商店。使用者結帳時，我們要確保他們所有的物品實際上都在庫存中。這樣做的方法是：

1. 檢查使用者購物車中每個專案的庫存水平。
2. 如果商品不再可用，請中止結帳。
3. 如果所有專案都可用，請從庫存中減去它們並確認結帳。

Web伺服器從Kafka下游的檢視讀取庫存（Inventory Level），但是它只能向上游Kafka的checkouts Topic提交結賬事務。問題是併發控制之一：如果有兩個使用者競相購買庫存最後一件商品，則只能有一個成功。我們需要檢查庫存檢視，並立即在某個時間點確認結賬。但是，在當前這種體系結構中無法做到這一點。
我們現在遇到的問題稱為寫偏斜write skew。在處理結帳事件時，我們從庫存檢視中讀取的資料可能已過期。如果兩個使用者幾乎同時嘗試購買同一商品，那麼他們都會成功，而我們將沒有足夠的庫存來滿足他們的需求。
像這樣的事件溯源架構受到許多的這種隔離異常影響，需要使用者使用者小心不斷提供“時間旅行”的旅行檢查。更糟的是，研究表明，這種異常允許這種架構建立徹底的安全漏洞，允許駭客竊取資料，覆蓋這個優秀的部落格文章對這一研究論文。
 

與資料庫一起使用Kafka
如果將Kafka用作傳統資料庫的補充，則可以避免這些問題：

OLTP資料庫可以實現一項訊息代理不太適合的關鍵任務：事件的准入控制。相比訊息代理作為“傳送並忘記”事件機制，OLTP資料庫將事件模式強制為“意圖模式”，資料庫可以拒絕發生衝突的事件，從而確保僅發出一致的事件流。OLTP資料庫確實擅長於此核心併發控制任務：每秒擴充套件到數百萬個事務。
使用資料庫作為寫入的入口點，從資料庫提取事件的最佳方法是透過流式傳輸change-data-capture。有許多很棒的開放式CDC框架，例如Debezium和Maxwell，以及現代 SQL 資料庫中的本機CDC 。變更資料捕獲還建立了一個優雅的操作案例。在恢復方案中，所有內容都可以在下游清除，並從（非常持久的）OLTP資料庫中重建。
 

請勿誤建資料庫
數十年來，資料庫社群已經學習（並重新學習了）一些重要的經驗教訓。這些課程中的每一個都是以資料損壞、資料丟失和大量面向使用者的異常情況的高昂代價獲得的。您要做的最後一件事是發現自己在重新學習這些課程，因為您不小心誤建了一個資料庫。
實時流訊息代理是管理高速資料的絕佳工具。但是您仍然需要傳統的DBMS來隔離事務。最好的參考架構是使用OLTP資料庫進行事件的准入控制，使用CDC進行事件生成，並將資料的下游副本建模為例項化檢視。