Canal-JSON协议DDL只发送索引为0的partiton，导致无法保证DML>DDL>DML顺序消费问题

[ShengFeng (Ti D Ber Ri Vhpg Iy)]

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v5.4.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
为什么设计成 Open Protocol协议将DDL广播到每个Partition。而 Canal-JSON协议把DDL发送到索引为0的partition？

如下图所示：

我理解如上图TiCDC保证 DML > DDL > DML 的顺序向下游输出event事件，TiCDC保证输入的顺序没有问题，但是当Sink的Kafka Topic有多个Partition时， Canal-JSON协议把DDL发送到索引为0的partition，消费时没法保证DDL前的DML全部消费完后再消费DDL，产生在消费端没法保证顺序问题。

[Billmay表妹 (表妹)]

根据 TiCDC Canal-JSON Protocol 文档中的描述，Canal-JSON 协议是由阿里巴巴的 Canal 定义的一种数据交换格式协议。在 Canal-JSON 协议中，DDL Event 只会被发送到索引为 0 的 partition，这是因为 Canal-JSON 协议最初是为 MySQL 设计的，而 MySQL 中的 DDL 操作是在整个实例上执行的，因此只需要将 DDL Event 发送到一个 partition 上即可。而在 TiDB 中，DDL 操作是在表级别上执行的，因此 TiCDC 通过 Open Protocol 协议将 DDL Event 广播到每个 partition，以保证 DML > DDL > DML 的顺序向下游输出 event 事件。但是，由于 Canal-JSON 协议的限制，当 Sink 的 Kafka Topic 有多个 partition 时，无法保证 DDL 前的 DML 全部消费完后再消费 DDL，这可能会导致在消费端无法保证顺序的问题。为了解决这个问题，建议您使用 Open Protocol 协议来消费 TiCDC 输出的 event 事件，以保证顺序消费。

[ShengFeng (Ti D Ber Ri Vhpg Iy)]

您好，请教个问题，当分发器配置dispatcher ="table"时，如何根据Scheme名和table名Hash算出Partition的呢？
当分发器配置dispatcher ="table"时，根据Scheme名和table名做Hash计算的算法

[huhaifeng (knull)]

在这个问题下，表妹已经回复过了