Kafka里实时消费Oracle变更数据，除了Debezium还有什么选择？
聊到把Oracle的变更数据实时推到Kafka，Debezium几乎已经成了一个默认选项。
数据库 → CDC → Kafka → 下游，这条链路清晰、组件开源、社区活跃，看上去确实很完美。
但如果你真的在生产环境用这套组合跑过Oracle的增量采集，尤其是在业务量上来之后，大概率会遇到一些“有苦说不出”的问题。
这篇文章不聊虚的，就从Oracle到Kafka这个具体场景出发，聊聊Debezium的硬伤，以及除了它之外还有哪些选择。
一、Debezium为什么成了“默认选项”？
先承认一个事实：Debezium + Kafka能流行起来是有道理的。
Kafka已经是很多企业事实上的消息基础设施。Debezium的出现又极大降低了CDC的使用门槛——通过读取数据库日志并生成变更事件，为MySQL、PostgreSQL、Oracle等主流数据库提供了一种相对标准化的变更捕获方式。
开源、免费、架构清晰、社区案例多，这几个标签加在一起，对技术团队来说确实很有吸引力。
在项目早期，这套方案往往也确实能跑起来，完成基本的数据同步任务。
但问题在于：问题并不会在第一天出现。
二、Debezium + Kafka在Oracle场景下的硬伤
先说一个很多人忽略的事实：FlinkCDC的Oracle连接器底层依赖的也是Debezium，而Debezium底层用的又是Oracle LogMiner。
也就是说，LogMiner的所有问题，都会原封不动地传递给上层。
1. 性能天花板非常低
LogMiner是单线程解析，Oracle只给它分配一个CPU核心。解析速度大概就在每秒1万条左右。业务高峰期日志生成速度超过解析速度，延迟就开始滚雪球——从几秒到几分钟再到几小时，实时同步硬生生变成了T+1。
2. 数据类型支持有限
BLOB、CLOB、XMLTYPE这些LogMiner处理不了。如果业务表里有这些类型，基于LogMiner的方案直接抓不到变更。
3. 表名/列名超30字符被忽略
Oracle 12c开始表名已经支持128个字符了，但LogMiner只认30个字符以内的。你的表名稍微长一点，数据就直接丢了，没有任何报错。
4. 大事务直接OOM
这是生产环境最常见的问题。Debezium在事务提交之前会把所有变更先缓存到本地内存里。几百万行的批量更新，内存直接撑爆。有人把堆内存从540MiB加到960MiB，结果也就从25万行撑到35万行。
5. 数据丢失风险
GitHub上有用户反馈，Debezium Oracle连接器在某些情况下会丢失CDC事件——虽然概率很低，“五十万条里丢一条”，但在金融、支付等场景下，一条都不能丢。
6. Exactly-once不支持
有云厂商的文档明确写了，Oracle Debezium连接器的限制包括：不支持Exactly-once delivery。这意味着在网络抖动或重启场景下，数据可能重复或丢失。
三、除了Debezium，还有哪些选择？
1. Oracle GoldenGate（OGG）
OGG是Oracle官方的CDC产品，通过解析redo log获取增量变化，再通过Kafka连接处理程序推送到Kafka集群。
优点：性能好、功能全、Oracle官方支持。
缺点：需要商业授权，价格不菲。而且OGG本身是重量级产品，部署和运维复杂度都比较高。
适合预算充足、对数据一致性要求极高、且已经在用Oracle生态的企业。
2. Confluent Oracle CDC Source Connector
Confluent官方提供的Oracle CDC连接器，底层同样使用Oracle LogMiner。
优点：与Confluent Kafka生态深度集成，配置相对标准化。
缺点：底层还是LogMiner，Debezium遇到的那些性能和数据类型的限制，这个连接器一样会遇到。Confluent官方文档也明确写了，各版本的支持将在2025年6月30日结束。
3. OpenLogReplicator（OLR）
OpenLogReplicator是一个开源的Oracle CDC方案，用C++写的，直接读取redo log的二进制文件，不依赖LogMiner。支持将变更流以JSON或Protobuf格式输出到Kafka。
优点：绕开了LogMiner，理论上不受LogMiner的那些限制。支持Oracle 11.2g到23ai的多个版本，还支持Data Guard备库。
缺点：GPL协议。这意味着如果你把它集成到商业产品里，可能需要开源你的整个项目。另外OLR目前主要是一个数据抽取工具，上层的事务管理、检查点恢复、多表路由等能力需要自己开发或配合Debezium使用。
适合对开源协议不敏感、愿意自行组装整套链路的团队。
4. Flink CDC
Flink CDC本质上是Debezium + Flink的组合——它内置了Debezium的Oracle连接器。
优点：如果你已经在用Flink做流计算，Flink CDC可以跟Flink生态无缝集成。
缺点：底层还是LogMiner。Debezium遇到的所有问题，FlinkCDC一样会遇到。而且FlinkCDC必须跑在Flink集群上，架构比单纯的Debezium+Kafka更重。
适合已经在用Flink生态、且能接受LogMiner限制的团队。
5. TLA
TLA是一个纯国产自研的事务日志解析组件。跟Debezium最大的区别是：不依赖LogMiner，直接解析Oracle redo log的二进制格式。
优点：
- 没有30字符表名限制
- 支持BLOB、CLOB、XMLTYPE等复杂类型
- 流式解析，不缓存事务，大事务不会OOM
- 多线程并行，实测性能远高于LogMiner方案
- 纯国产自研，不依赖任何国外商业软件，没有授权限制
- 组件形态，不是产品——可以嵌入到任何数据平台、ETL工具、消息中间件里
缺点：目前Oracle版本已经跑通，MySQL、PG和国产数据库的支持还在推进中。
适合正在做国产化替代、需要灵活集成、或者被LogMiner各种限制折磨的团队。
四、怎么选？
聊完这些方案，回到最实际的问题：你的场景适合哪个？
| 方案 | 底层技术 | 授权 | 适用场景 |
|---|---|---|---|
| Debezium + Kafka | LogMiner | 开源免费 | 开发测试、数据量小、能接受限制 |
| OGG | 自研解析 | 商业授权 | 预算充足、要求最高可靠性 |
| Confluent Oracle Connector | LogMiner | 商业（Confluent） | 已深度使用Confluent生态 |
| OpenLogReplicator | 自研解析（C++） | GPL开源 | 能接受GPL、愿意自行组装 |
| Flink CDC | LogMiner（Debezium） | 开源免费 | 已在使用Flink生态 |
| TLA | 自研解析 | 国产自研 | 国产化要求、灵活集成、追求性能 |
如果只是开发测试、数据量小、对延迟和数据类型不敏感，Debezium + Kafka确实够用。
但如果你的场景是生产环境、高并发、有BLOB/CLOB字段、表名超30字符、不能丢数据——那Debezium这套组合的坑，你可能一个都躲不掉。
这时候就需要考虑其他方案了。
欢迎交流。
补充：文中提到的性能数据和社区Issue来自公开的GitHub讨论和技术社区，可自行查证。实际效果受硬件配置、数据库版本、网络环境等因素影响。