Debezium 是一個為捕獲數(shù)據(jù)更改 (Change Data Capture, CDC) 提供低延遲的流式處理平臺，利用 Kafka 和 Kafka Connect 實(shí)現(xiàn)了持久性、可靠性和容錯性。

Debezium 有很多非常有價值的使用場景，我們在這兒僅僅列出幾個更常見的使用場景。

緩存失效 (Cache invalidation)

在緩存中緩存的條目(entry)在源頭被更改或者被刪除的時候立即讓緩存中的條目失效。如果緩存在一個獨(dú)立的進(jìn)程中運(yùn)行(例如Redis，Memcache，Infinispan或者其他的)，那么簡單的緩存失效邏輯可以放在獨(dú)立的進(jìn)程或服務(wù)中，從而簡化主應(yīng)用的邏輯。在一些場景中，緩存失效邏輯可以更復(fù)雜一點(diǎn)，讓它利用更改事件中的更新數(shù)據(jù)去更新緩存中受影響的條目。

簡化單體應(yīng)用(Simplifying monolithic applications)

許多應(yīng)用更新數(shù)據(jù)庫，然后在數(shù)據(jù)庫中的更改被提交后，做一些額外的工作：更新搜索索引，更新緩存，發(fā)送通知，運(yùn)行業(yè)務(wù)邏輯，等等。這種情況通常稱為雙寫(dual-writes)，因?yàn)閼?yīng)用沒有在一個事務(wù)內(nèi)寫多個系統(tǒng)。這樣不僅應(yīng)用邏輯復(fù)雜難以維護(hù)，而且雙寫容易丟失數(shù)據(jù)或者在一些系統(tǒng)更新成功而另一些系統(tǒng)沒有更新成功的時候造成不同系統(tǒng)之間的狀態(tài)不一致。使用捕獲更改數(shù)據(jù)技術(shù)(change data capture,CDC)，在源數(shù)據(jù)庫的數(shù)據(jù)更改提交后，這些額外的工作可以被放在獨(dú)立的線程或者進(jìn)程(服務(wù))中完成。這種實(shí)現(xiàn)方式的容錯性更好，不會丟失事件，容易擴(kuò)展，并且更容易支持升級。

共享數(shù)據(jù)庫(Sharing databases)

當(dāng)多個應(yīng)用共用同一個數(shù)據(jù)庫的時候，一個應(yīng)用提交的更改通常要被另一個應(yīng)用感知到。一種實(shí)現(xiàn)方式是使用消息總線，盡管非事務(wù)性(non-transactional)的消息總線總會受上面提到的雙寫(dual-writes)影響。但是，另一種實(shí)現(xiàn)方式，即Debezium，變得很直接：每個應(yīng)用可以直接監(jiān)控?cái)?shù)據(jù)庫的更改，并且響應(yīng)更改。

數(shù)據(jù)集成(Data integration)

數(shù)據(jù)通常被存儲在多個地方，尤其是當(dāng)數(shù)據(jù)被用于不同的目的的時候，會有不同的形式。保持多系統(tǒng)的同步是很有挑戰(zhàn)性的，但是可以通過使用Debezium加上簡單的事件處理邏輯來實(shí)現(xiàn)簡單的ETL類型的解決方案。

命令查詢職責(zé)分離(CQRS)

在命令查詢職責(zé)分離?Command Query Responsibility Separation (CQRS)?架構(gòu)模式中，更新數(shù)據(jù)使用了一種數(shù)據(jù)模型，讀數(shù)據(jù)使用了一種或者多種數(shù)據(jù)模型。由于數(shù)據(jù)更改被記錄在更新側(cè)(update-side)，這些更改將被處理以更新各種讀展示。所以CQRS應(yīng)用通常更復(fù)雜，尤其是他們需要保證可靠性和全序(totally-ordered)處理。Debezium和CDC可以使這種方式更可行：寫操作被正常記錄，但是Debezium捕獲數(shù)據(jù)更改，并且持久化到全序流里，然后供那些需要異步更新只讀視圖的服務(wù)消費(fèi)。寫側(cè)(write-side)表可以表示面向領(lǐng)域的實(shí)體(domain-oriented entities)，或者當(dāng)CQRS和?Event Sourcing?結(jié)合的時候，寫側(cè)表僅僅用做追加操作命令事件的日志。