【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】FlinkCDC、oblogproxy、OMS
【 使用版本 】FlinkCDC3.0.0, OMS 4.1.1
【问题描述】求教社区大佬，1.使用FlinkCDC做增量日志拉取依赖oblogproxy，这个如何规避单点风险？2.FlinkCDC ob connector实现的增量拉取是否并发拉取？3.如果需要接入ob的增量变更日志进行业务处理，从稳定性和性能方面考虑，OMS和FlinkCDC哪个工具更好一些？期待回复，感谢~
【复现路径】无
【附件及日志】无
1、oblogproxy目前就是单点，还没有考虑高可用，目前无法规避单点，oblogproxy本身数据来自ob的clog，所以只要clog存在，挂掉之后再启动一个oblogproxy，也可以拉倒数据
2.串行，日志本身需要保序，写入会根据具体事务、主键等并行
3.性能方面OMS和FlinkCDC没有做过比较，理论上应该差不多，实现原理有些区别
OMS是直接调用ob cdc拉去clog，保存store队列，writer消费store写目标库
oblogproxy是调用ob cdc拉去clog，转换成mysql binlog，下游flink cdc从oblogproxy消费数据，写目标库
补充一下楼上， flink cdc 的 ob connector 用的是 oblogproxy 的 cdc 模式，是直接拿到日志消息体去解析的，flink cdc 的 mysql connector 可以对接 binlog service，在 binlog service 内部用的是 oblogproxy 的 binlog 模式，会把日志消息体先转换成 mysql binlog 格式。
另外对于稳定性和性能，因为目前的 flink cdc ob connector 还没有支持 incremental snapshot 框架，所以是不如 oms 的（这个功能大概会在 3.1 支持掉）。如果用 flink cdc mysql connector + binlog service，在性能和稳定性上跟 oms 相比差不多，可以根据功能特点来选择使用哪一个工具。
2.串行，这个点是和OMS算是不一致的地方吗？之前我看是说OMS的拉取是日志流间并行，日志流内串行+异步，所以从这个角度的话，应该也是OMS更好一些？
感谢补充解答~ binlog service看着也依赖oblogproxy，这个单点问题目前应该也是像楼上大佬说的那样无法规避呢？
这里的并行拉取日志流，是指的从clog通过cdc拉取，oms中拉去之后保存在本地store中，writer从store消费数据是串行
是的，目前binlog service也会存在单点问题
了解了，非常感谢