1. Debezium是一个开源项目

2.为捕获数据更改(change data capture,CDC)提供了一个低延迟的流式处理平台

3.安装并且配置Debezium去监控你的数据库，应用就可以消费对数据库的每一个行级别(row-level)的更改。只有已提交的更改才是可见的，所以不用担心事务(transaction)或者更改被回滚(roll back)。Debezium为所有的数据库更改事件提供了一个统一的模型，所以不用担心每一种数据库管理系统的错综复杂性。另外，由于Debezium用持久化的、有副本备份的日志来记录数据库数据变化的历史，因此，你的应用可以随时停止再重启，而不会错过它停止运行时发生的事件，保证了所有的事件都能被正确地、完全地处理掉。

也就是说应用可以停止,只要是Debezium不停止,那么就不会出现丢数据的地方,Debezium会把数据库的变化在,应用停止的期间给保存到硬盘上,持久化起来,这样就不会丢数据.

4.Debezium可以适用于多种数据库,需要结合Kafka一起使用,在Kafka之上，并提供与Kafka Connect兼容的连接器

5.Debezium使用场景:

a.数据库数据更改后的一些额外工作:

在数据库中的更改被提交后，做一些额外的工作：更新搜索索引，更新缓存，发送通知，运行业务逻辑，等等。这种情况通常称为双写(dual-writes)，因为应用没有在一个事务内写多个系统。这样不仅应用逻辑复杂难以维护，而且双写容易丢失数据或者在一些系统更新成功而另一些系统没有更新成功的时候造成不同系统之间的状态不一致。使用捕获更改数据技术(change data capture,CDC)，在源数据库的数据更改提交后，这些额外的工作可以被放在独立的线程或者进程(服务)中完成。这种实现方式的容错性更好，不会丢失事件，容易扩展，并且更容易支持升级

b.数据库中多个应用之间贡享:

当多个应用共用同一个数据库的时候，一个应用提交的更改通常要被另一个应用感知到。一种实现方式是使用消息总线，尽管非事务性(non-transactional)的消息总线总会受上面提到的双写(dual-writes)影响。但是，另一种实现方式，即Debezium，变得很直接：每个应用可以直接监控数据库的更改，并且响应更改。

c.保证多个系统的数据同步:

数据通常被存储在多个地方，尤其是当数据被用于不同的目的的时候，会有不同的形式。保持多

系统的同步是很有挑战性的，但是可以通过使用Debezium加上简单的事件处理逻辑来实现简单

的ETL类型的解决方案

6.然后看一下和canal 以及 Maxwell的对比

a.Debezium支持全DDL（create/alter/rename/drop/truncate）和DML（insert/update/delete）的 操作日志同步；

b.Maxwell不支持truncate命令同步

c.支持使用数据的主键或唯一键作为消息体的key（可以根据该唯一键做Topic分区进行负载均 衡）；

d.支持快照模式(snapshot.mode)全量同步；（Canal不支持全量，Maxwell支持bootstrap全量）

e.还支持多种数据源（MySQL，Oracle，Postgre，MongoDB，SqlServer，DB2

Cassandra），

f.比Canal，Maxwell功能更强大；

社区活跃，与kafka connect配合使用如虎添翼。

缺点：

1.需要kafka connect依赖；

2.消息体内容太多，对消息队列压力较大；（可使用transforms 模块进行压缩和定制）

3.每张表对应一个topic，管理起来不够方便（canal，maxwell则可以使用正则来处理）； （可使用transforms 模块进行压缩和定制）