开发者社区> 问答> 正文

按照pk hash到对应partition可能引发的顺序性问题

如果有多个parition,对消息进行分区时对于update消息是按照后项的值进行hash的,如果源端短时间对pk值进行update,则有可能导致发往不同分区,从而无法保证顺序性。

假如 1.有源表和目标表:create table test(id int(10) primary key)

2.源表的增量数据通过canal发往kafka,目标表接收kafka消息进行同步。

3.发往的topic下有三个partition:p0、p1、p2

4.源端和目标端都有一条记录id=1

此时对源端进行两次update: update1:update test set id=2 where id=1; update2: update test set id=3 wehre id=2; 假如两条消息都在同一批message中发往kafka,其中update1发送到p1,pudate2发送到p2,这两条消息的顺序性是无法保证的,假如update2先到达,则目标端最终结果为id=2,与源端结果id=3不一致。

可否考虑以下方案: 参考flink的Retract模式,将update拆分为insert和delete,这样便可保证最终一致性。

同样以上述案例为例: 将update1拆为delete 1和insert 2 将update2拆为delete 2和insert 3

delete 1发送到p0,insert 2发送到p1,delete 2发送到p1,insert 3发送到p2

由于update1先于update2产生,因此在p1中insert 2必在delete 2之前,此时无论p0、p1、p2中的消息到达顺序如何,对于目标端来说都能保证结果是id=3,保证了最终一致性。

原提问者GitHub用户516669850

展开
收起
山海行 2023-04-27 19:38:36 108 0
1 条回答
写回答
取消 提交回答
  • pk hash之后,如果有主键变更,是会有乱序的问题

    原回答者GitHub用户agapple

    2023-04-28 14:22:44
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
低代码开发师(初级)实战教程 立即下载
冬季实战营第三期:MySQL数据库进阶实战 立即下载
阿里巴巴DevOps 最佳实践手册 立即下载