小項目不想引入 MQ？試試 Debezium！

作者：是奉壹呀
鏈接：https://juejin.cn/post/7264791359839223823

奧卡姆剃刀原理，“如無必要，勿增實體"。

在一些小型項目當中，沒有引入消息中間件，也不想引入，但有一些業務邏輯想要解耦異步，那怎麼辦呢？

我們的web項目，單獨內網部署，由於大數據背景，公司消息中間件統一使用的kafka，在一些小項目上kafka就顯得很笨重。引入rocketmq或rabittmq也沒必要。事件或多線程也不適合。

具體一點的，之前對接的一個系統，一張記錄表有10+以上的類型狀態，新的需求是，針對每種狀態做出對應的不同的操作。

之前寫入這張記錄表的時候，方式也是五花八門，有的是單條記錄寫入，有的是批量寫入，有的調用了統一的service,有的呢直接調用了DAO層mapper直接寫入。

所以想找到一個統一入口進行切入處理，就不行了。

這個時候就算引入消息隊列，也需要在不同的業務方法裏進行寫入消息的操作。業務方也不太願意配合改。

可以使用觸發器，但它是屬於上個時代的產物，槽點太多。（這裏並不是完全不主張使用觸發器，技術永遠是爲業務服務的，只要評估覺得可行，就可以使用）那麼這個時候，CDC技術就可以粉墨登場了。

CDC(change data capture)數據更改捕獲。

常見的數據更改捕獲都是通過數據庫比如mysql的binlog來達到目的。

我們可以監控mysql binlog日誌，當寫入一條數據的時候，接收到數據變更日誌，做出相應的操作。這樣的好處是，只需導入依賴，不額外引入組件，同時無需改動之前的代碼。兩邊完全解耦，互不干擾。

常見的CDC框架，比如，canal (非Camel)

canal [kə'næl]，譯意爲水道/管道/溝渠，主要用途是基於 MySQL 數據庫增量日誌解析，提供增量數據訂閱和消費早期阿里巴巴因爲杭州和美國雙機房部署，存在跨機房同步的業務需求，實現方式主要是基於業務 trigger 獲取增量變更。從 2010 年開始，業務逐步嘗試數據庫日誌解析獲取增量變更進行同步，由此衍生出了大量的數據庫增量訂閱和消費業務。
它是基於日誌增量訂閱和消費的業務，包括

數據庫鏡像

數據庫實時備份

索引構建和實時維護(拆分異構索引、倒排索引等)

業務 cache 刷新

帶業務邏輯的增量數據處理

它的原理：

canal 模擬 MySQL slave 的交互協議，僞裝自己爲 MySQL slave ，向 MySQL master 發送dump 協議
MySQL master 收到 dump 請求，開始推送 binary log 給 slave (即 canal )
canal 解析 binary log 對象(原始爲 byte 流)

再比如，debezium(音同 dbzm 滴BZ姆)很多人可能不太瞭解. 包括databus,maxwell，flink cdc（大數據領域）等等，它們同屬CDC捕獲數據更改(change data capture)類的技術。

爲什麼是debezium

這麼多技術框架，爲什麼選debezium？

看起來很多。但一一排除下來就debezium和canal。

sqoop,kettle,datax之類的工具，屬於前大數據時代的產物，地位類似於web領域的structs2。而且，它們基於查詢而非binlog日誌，其實不屬於CDC。首先排除。

flink cdc是大數據領域的框架，一般web項目的數據量屬於大材小用了。

同時databus,maxwell相對比較冷門，用得比較少。

最後不用canal的原因有以下幾點。

canal需要安裝，這違背了“如非必要，勿增實體”的原則。
canal只能對MYSQL進行CDC監控。有很大的侷限性。
大數據領域非常流行的flink cdc(阿里團隊主導)底層使用的也是debezium，而非同是阿里出品的canal。
debezium可藉助kafka組件，將變動的數據發到kafka topic，後續的讀取操作只需讀取kafka,可有效減少數據庫的讀取壓力。可保證一次語義，至少一次語義。
同時，也可基於內嵌部署模式，無需我們手動部署kafka集羣，可滿足”如非必要，勿增實體“的原則。

Debezium是一個捕獲數據更改(CDC)平臺，並且利用Kafka和Kafka Connect實現了自己的持久性、可靠性和容錯性。

每一個部署在Kafka Connect分佈式的、可擴展的、容錯性的服務中的connector監控一個上游數據庫服務器，捕獲所有的數據庫更改，然後記錄到一個或者多個Kafka topic(通常一個數據庫表對應一個kafka topic)。

Kafka確保所有這些數據更改事件都能夠多副本並且總體上有序(Kafka只能保證一個topic的單個分區內有序)，這樣，更多的客戶端可以獨立消費同樣的數據更改事件而對上游數據庫系統造成的影響降到很小(如果N個應用都直接去監控數據庫更改，對數據庫的壓力爲N，而用debezium彙報數據庫更改事件到kafka，所有的應用都去消費kafka中的消息，可以把對數據庫的壓力降到1)。

另外，客戶端可以隨時停止消費，然後重啓，從上次停止消費的地方接着消費。每個客戶端可以自行決定他們是否需要exactly-once或者at-least-once消息交付語義保證，並且所有的數據庫或者表的更改事件是按照上游數據庫發生的順序被交付的。

對於不需要或者不想要這種容錯級別、性能、可擴展性、可靠性的應用，他們可以使用內嵌的Debezium connector引擎來直接在應用內部運行connector。

這種應用仍需要消費數據庫更改事件，但更希望connector直接傳遞給它，而不是持久化到Kafka裏。

簡介

Debezium是一個開源項目，爲捕獲數據更改(change data capture,CDC)提供了一個低延遲的流式處理平臺。你可以安裝並且配置Debezium去監控你的數據庫，然後你的應用就可以消費對數據庫的每一個行級別(row-level)的更改。只有已提交的更改纔是可見的，所以你的應用不用擔心事務(transaction)或者更改被回滾(roll back)。Debezium爲所有的數據庫更改事件提供了一個統一的模型，所以你的應用不用擔心每一種數據庫管理系統的錯綜複雜性。另外，由於Debezium用持久化的、有副本備份的日誌來記錄數據庫數據變化的歷史，因此，你的應用可以隨時停止再重啓，而不會錯過它停止運行時發生的事件，保證了所有的事件都能被正確地、完全地處理掉。

監控數據庫，並且在數據變動的時候獲得通知一直是很複雜的事情。關係型數據庫的觸發器可以做到，但是隻對特定的數據庫有效，而且通常只能更新數據庫內的狀態(無法和外部的進程通信)。一些數據庫提供了監控數據變動的API或者框架，但是沒有一個標準，每種數據庫的實現方式都是不同的，並且需要大量特定的知識和理解特定的代碼才能運用。確保以相同的順序查看和處理所有更改，同時最小化影響數據庫仍然非常具有挑戰性。

Debezium提供了模塊爲你做這些複雜的工作。一些模塊是通用的，並且能夠適用多種數據庫管理系統，但在功能和性能方面仍有一些限制。另一些模塊是爲特定的數據庫管理系統定製的，所以他們通常可以更多地利用數據庫系統本身的特性來提供更多功能。

github官網上羅列的一些

典型應用場景：

緩存失效(Cache invalidation)
經典問題 Redis與MySQL雙寫一致性如何保證？Debezium利用kafka單分區的有序性(忽略mysql binlog本身可能的延遲和亂序)，可完全解決此問題。
在緩存中緩存的條目(entry)在源頭被更改或者被刪除的時候立即讓緩存中的條目失效。如果緩存在一個獨立的進程中運行(例如Redis，Memcache，Infinispan或者其他的)，那麼簡單的緩存失效邏輯可以放在獨立的進程或服務中，從而簡化主應用的邏輯。在一些場景中，緩存失效邏輯可以更復雜一點，讓它利用更改事件中的更新數據去更新緩存中受影響的條目。

簡化單體應用(Simplifying monolithic applications) 許多應用更新數據庫，然後在數據庫中的更改被提交後，做一些額外的工作：更新搜索索引，更新緩存，發送通知，運行業務邏輯，等等。這種情況通常稱爲雙寫(dual-writes)，因爲應用沒有在一個事務內寫多個系統。這樣不僅應用邏輯複雜難以維護，而且雙寫容易丟失數據或者在一些系統更新成功而另一些系統沒有更新成功的時候造成不同系統之間的狀態不一致。使用捕獲更改數據技術(change data capture,CDC)，在源數據庫的數據更改提交後，這些額外的工作可以被放在獨立的線程或者進程(服務)中完成。這種實現方式的容錯性更好，不會丟失事件，容易擴展，並且更容易支持升級。

共享數據庫(Sharing databases) 當多個應用共用同一個數據庫的時候，一個應用提交的更改通常要被另一個應用感知到。一種實現方式是使用消息總線，儘管非事務性(non-transactional)的消息總線總會受上面提到的雙寫(dual-writes)影響。但是，另一種實現方式，即Debezium，變得很直接：每個應用可以直接監控數據庫的更改，並且響應更改。

數據集成(Data integration) 數據通常被存儲在多個地方，尤其是當數據被用於不同的目的的時候，會有不同的形式。保持多系統的同步是很有挑戰性的，但是可以通過使用Debezium加上簡單的事件處理邏輯來實現簡單的ETL類型的解決方案。

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

springboot 整合 Debezium

推薦一個開源免費的 Spring Boot 實戰項目：

https://github.com/javastacks/spring-boot-best-practice

依賴

<debezium.version>1.7.0.Final</debezium.version>
 <mysql.connector.version>8.0.26</mysql.connector.version>

 <dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>${mysql.connector.version}</version>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>io.debezium</groupId>
    <artifactId>debezium-api</artifactId>
    <version>${debezium.version}</version>
</dependency>
<dependency>
    <groupId>io.debezium</groupId>
    <artifactId>debezium-embedded</artifactId>
    <version>${debezium.version}</version>
</dependency>
<dependency>
    <groupId>io.debezium</groupId>
    <artifactId>debezium-connector-mysql</artifactId>
    <version>${debezium.version}</version>
    <exclusions>
	<exclusion>
	    <groupId>mysql</groupId>
	    <artifactId>mysql-connector-java</artifactId>
	</exclusion>
    </exclusions>
</dependency>

注意debezium版本爲1.7.0.Final，對應mysql驅動爲8.0.26,低於這個版本會報兼容錯誤。

配置

相應的配置

debezium.datasource.hostname = localhost
debezium.datasource.port = 3306
debezium.datasource.user = root
debezium.datasource.password = 123456
debezium.datasource.tableWhitelist = test.test
debezium.datasource.storageFile = E:/debezium/test/offsets/offset.dat
debezium.datasource.historyFile = E:/debezium/test/history/custom-file-db-history.dat
debezium.datasource.flushInterval = 10000
debezium.datasource.serverId = 1
debezium.datasource.serverName = name-1

然後進行配置初始化。

主要的配置項：

connector.class

監控的數據庫類型，這裏選mysql。

offset.storage

選擇FileOffsetBackingStore時,意思把讀取進度存到本地文件，因爲我們不用kafka，當使用kafka時，選KafkaOffsetBackingStore 。

offset.storage.file.filename

存放讀取進度的本地文件地址。

offset.flush.interval.ms

讀取進度刷新保存頻率，默認1分鐘。如果不依賴kafka的話，應該就沒有exactly once只讀取一次語義，應該是至少讀取一次。意味着可能重複讀取。如果web容器掛了，最新的讀取進度沒有刷新到文件裏，下次重啓時，就會重複讀取binlog。

table.whitelist

監控的表名白名單,建議設置此值，只監控這些表的binlog。

database.whitelist

監控的數據庫白名單,如果選此值，會忽略table.whitelist，然後監控此db下所有表的binlog。

import io.debezium.connector.mysql.MySqlConnector;
import io.debezium.relational.history.FileDatabaseHistory;
import lombok.Data;
import org.apache.kafka.connect.storage.FileOffsetBackingStore;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import java.io.File;
import java.io.IOException;

/**
 * @className: MysqlConfig
 * @author: nyp
 * @description: TODO
 * @date: 2023/8/7 13:53
 * @version: 1.0
 */
@Configuration
@ConfigurationProperties(prefix ="debezium.datasource")
@Data
public class MysqlBinlogConfig {

    private String hostname;
    private String port;
    private String user;
    private String password;
    private String tableWhitelist;
    private String storageFile;
    private String historyFile;
    private Long flushInterval;
    private String serverId;
    private String serverName;

    @Bean
    public io.debezium.config.Configuration MysqlBinlogConfig () throws Exception {
        checkFile();
        io.debezium.config.Configuration configuration = io.debezium.config.Configuration.create()
                .with("name", "mysql_connector")
                .with("connector.class", MySqlConnector.class)
                // .with("offset.storage", KafkaOffsetBackingStore.class)
                .with("offset.storage", FileOffsetBackingStore.class)
                .with("offset.storage.file.filename", storageFile)
                .with("offset.flush.interval.ms", flushInterval)
                .with("database.history", FileDatabaseHistory.class.getName())
                .with("database.history.file.filename", historyFile)
                .with("snapshot.mode", "Schema_only")
                .with("database.server.id", serverId)
                .with("database.server.name", serverName)
                .with("database.hostname", hostname)
//                .with("database.dbname", dbname)
                .with("database.port", port)
                .with("database.user", user)
                .with("database.password", password)
//                .with("database.whitelist", "test")
                .with("table.whitelist", tableWhitelist)
                .build();
        return configuration;

    }

    private void checkFile() throws IOException {
        String dir = storageFile.substring(0, storageFile.lastIndexOf("/"));
        File dirFile = new File(dir);
        if(!dirFile.exists()){
            dirFile.mkdirs();
        }
        File file = new File(storageFile);
        if(!file.exists()){
            file.createNewFile();
        }
    }
}

snapshot.mode 快照模式，指定連接器啓動時運行快照的條件。可能的設置有:

initial 只有在沒有爲邏輯服務器名記錄偏移量時，連接器才運行快照。
When_needed 當連接器認爲有必要時，它會在啓動時運行快照。也就是說，當沒有可用的偏移量時，或者當先前記錄的偏移量指定了服務器中不可用的binlog位置或GTID時。
Never 連接器從不使用快照。在第一次使用邏輯服務器名啓動時，連接器從binlog的開頭讀取。謹慎配置此行爲。只有當binlog保證包含數據庫的整個歷史記錄時，它纔有效。
Schema_only 連接器運行模式而不是數據的快照。當您不需要主題包含數據的一致快照，而只需要主題包含自連接器啓動以來的更改時，此設置非常有用。
Schema_only_recovery 這是已經捕獲更改的連接器的恢復設置。當您重新啓動連接器時，此設置允許恢復損壞或丟失的數據庫歷史主題。您可以定期將其設置爲“清理”意外增長的數據庫歷史主題。數據庫歷史主題需要無限保留。

database.server.id

僞裝成slave的Debezium服務的id，自定義，有多個Debezium服務不能重複，如果重複的話會報以下異常。

io.debezium.DebeziumException: A slave with the same server_uuid/server_id as this slave has connected to the master; the first event 'binlog.000013' at 46647257, the last event read from './binlog.000013' at 125, the last byte read from './binlog.000013' at 46647257. Error code: 1236; SQLSTATE: HY000.
	at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.wrap(MySqlStreamingChangeEventSource.java:1167)
	at io.debezium.connector.mysql.MySqlStreamingChangeEventSource$ReaderThreadLifecycleListener.onCommunicationFailure(MySqlStreamingChangeEventSource.java:1212)
	at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:980)
	at com.github.shyiko.mysql.binlog.BinaryLogClient.connect(BinaryLogClient.java:599)
	at com.github.shyiko.mysql.binlog.BinaryLogClient$7.run(BinaryLogClient.java:857)
	at java.lang.Thread.run(Thread.java:750)
Caused by: com.github.shyiko.mysql.binlog.network.ServerException: A slave with the same server_uuid/server_id as this slave has connected to the master; the first event 'binlog.000013' at 46647257, the last event read from './binlog.000013' at 125, the last byte read from './binlog.000013' at 46647257.
	at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:944)
	... 3 common frames omitted

監聽

配置監聽服務

import com.alibaba.fastjson.JSON;
import io.debezium.config.Configuration;
import io.debezium.data.Envelope;
import io.debezium.engine.ChangeEvent;
import io.debezium.engine.DebeziumEngine;
import io.debezium.engine.format.Json;
import lombok.Builder;
import lombok.Data;
import lombok.extern.slf4j.Slf4j;
import org.apache.commons.lang3.StringUtils;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.stereotype.Component;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.annotation.Resource;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import java.util.Objects;
import java.util.concurrent.Executor;

/**
 * @projectName: test
 * @package: com.test.config
 * @className: MysqlBinlogListener
 * @author: nyp
 * @description: TODO
 * @date: 2023/8/7 13:56
 * @version: 1.0
 */
@Component
@Slf4j
public class MysqlBinlogListener {

    @Resource
    private Executor taskExecutor;

    private final List<DebeziumEngine<ChangeEvent<String, String>>> engineList = new ArrayList<>();

    private MysqlBinlogListener (@Qualifier("mysqlConnector") Configuration configuration) {
            this.engineList.add(DebeziumEngine.create(Json.class)
                    .using(configuration.asProperties())
                    .notifying(record -> receiveChangeEvent(record.value()))
                    .build());
    }

    private void receiveChangeEvent(String value) {
        if (Objects.nonNull(value)) {
            Map<String, Object> payload = getPayload(value);
            String op = JSON.parseObject(JSON.toJSONString(payload.get("op")), String.class);
            if (!(StringUtils.isBlank(op) || Envelope.Operation.READ.equals(op))) {
                ChangeData changeData = getChangeData(payload);
               // 這裏拋出異常會導致後面的日誌監聽失敗
                try {
                    mysqlBinlogService.service(changeData);
                }catch (Exception e){
                    log.error("binlog處理異常，原數據: " + changeData, e);
                }

            }
        }
    }

    @PostConstruct
    private void start() {
        for (DebeziumEngine<ChangeEvent<String, String>> engine : engineList) {
            taskExecutor.execute(engine);
        }
    }

    @PreDestroy
    private void stop() {
        for (DebeziumEngine<ChangeEvent<String, String>> engine : engineList) {
            if (engine != null) {
                try {
                    engine.close();
                } catch (IOException e) {
                    log.error("", e);
                }
            }
        }
    }

    public static Map<String, Object> getPayload(String value) {
        Map<String, Object> map = JSON.parseObject(value, Map.class);
        Map<String, Object> payload = JSON.parseObject(JSON.toJSONString(map.get("payload")), Map.class);
        return payload;
    }

    public static ChangeData getChangeData(Map<String, Object> payload) {
        Map<String, Object> source = JSON.parseObject(JSON.toJSONString(payload.get("source")), Map.class);
        return ChangeData.builder()
                .op(payload.get("op").toString())
                .table(source.get("table").toString())
                .after(JSON.parseObject(JSON.toJSONString(payload.get("after")), Map.class))
                .source(JSON.parseObject(JSON.toJSONString(payload.get("source")), Map.class))
                .before(JSON.parseObject(JSON.toJSONString(payload.get("before")), Map.class))
                .build();
    }

    @Data
    @Builder
    public static class ChangeData {
        /**
         * 更改前數據
         */
        private Map<String, Object> after;
        private Map<String, Object> source;
        /**
         * 更改後數據
         */
        private Map<String, Object> before;
        /**
         * 更改的表名
         */
        private String table;
        /**
         * 操作類型, 枚舉 Envelope.Operation
         */
        private String op;
    }

}

將監聽到的binlog日誌封裝爲ChangeData對象，包括表名，更改前後的數據，

以及操作類型

READ("r"),
CREATE("c"),
UPDATE("u"),
DELETE("d"),
TRUNCATE("t");

測試

update操作輸出

MysqlListener.ChangeData(after = {
	name = Suzuki Mio2,
	id = 1
}, source = {
	file = binlog .000013,
	connector = mysql,
	pos = 42587833,
	name = test - 1,
	row = 0,
	server_id = 1,
	version = 1.7 .0.Final,
	ts_ms = 1691458956000,
	snapshot = false,
	db = test
	table = test
}, before = {
	name = Suzuki Mio,
	id = 1
}, table = test, op = u)
data = {
	name = Suzuki Mio2,
	id = 1
}

新增操作輸出

MysqlListener.ChangeData(after = {
	name = 王五,
	id = 0
}, source = {
	file = binlog .000013,
	connector = mysql,
	pos = 42588175,
	name = test - 1,
	row = 0,
	server_id = 1,
	version = 1.7 .0.Final,
	ts_ms = 1691459066000,
	snapshot = false,
	db = test,
	table = test
}, before = null, table = test, op = c)

刪除操作輸出

MysqlListener.ChangeData(after = null, source = {
	file = binlog .000013,
	connector = mysql,
	pos = 42588959,
	name = test - 1,
	row = 0,
	server_id = 1,
	version = 1.7 .0.Final,
	ts_ms = 1691459104000,
	snapshot = false,
	db = test
	table = test
}, before = {
	name = 王五,
	id = 0
}, table = test, op = d)

我們之前配置的保存讀取進度的文件storageFile，類似於kafka的偏移量，記錄的內容如下：

停止服務，對數據庫進行操作，再次重啓，會根據進度重新讀取。

小結

本文介紹了debezium，更多的時候，我們一談到CDC，第一想到的是大量數據同步的工具。但其實也可以利用其數據變更捕獲的特性，來達到一部份消息隊列的作用。

但其畢竟不能完全替代消息隊列。大家理性看待與選擇。

本文的重點在介紹一種思路，具體的某項技術反而不那麼重要。

更多文章推薦：

1.Spring Boot 3.x 教程，太全了！

2.2,000+ 道 Java面試題及答案整理(2024最新版)

3.免費獲取 IDEA 激活碼的 7 種方式（2024最新版）

覺得不錯，別忘了隨手點贊+轉發哦！

小項目不想引入 MQ？試試 Debezium！

爲什麼是debezium

springboot 整合 Debezium

依賴

配置

監聽

測試

小結

關於遊戲付費的一點想法

我通過CKA和CKS啦！

多人同時導出 Excel 幹崩服務器！新來的阿里大佬給出的解決方案太優雅了！

頂級 Javaer 都在用的 20 個類庫，真香！

35K*14 薪，入職了！這公司只要不裁員，我能一直呆下去！

MyBatis 動態 SQL 最全教程，這樣寫 SQL 太優雅了！

MySQL 分庫分表方案，總結太全了。。

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結