基于 Kafka 与 Debezium 构建实时数据同步

举报
格图洛书 发表于 2021/11/19 00:14:18 2021/11/19
【摘要】 起源 在进行架构转型与分库分表之前,我们一直采用非常典型的单体应用架构:主服务是一个 Java WebApp,使用 Nginx 并选择 Session Sticky 分发策略做负载均衡和会话保持;背后是一个 MySQL 主实例,接了若干 Slave 做读写分离。在整个转型开始之前,我们就知道这会是一块难啃的硬骨头:我们要在全线业务飞速...

起源

在进行架构转型与分库分表之前,我们一直采用非常典型的单体应用架构:主服务是一个 Java WebApp,使用 Nginx 并选择 Session Sticky 分发策略做负载均衡和会话保持;背后是一个 MySQL 主实例,接了若干 Slave 做读写分离。在整个转型开始之前,我们就知道这会是一块难啃的硬骨头:我们要在全线业务飞速地扩张迭代的同时完成架构转型,因为这是实实在在的”给高速行驶的汽车换轮胎”。

为了最大限度地减少服务拆分与分库分表给业务带来的影响(不影响业务开发也是架构转型的前提),我们采用了一种温和的渐进式拆分方案:

  • 对于每块需要拆分的领域,首先拆分出子服务,并将所有该领域的数据库操作封装为 RPC 接口;

  • 将其它所有服务中对该领域数据表的操作替换为 RPC 调用;

  • 拆分该领域的数据表,使用数据同步保证旧库中的表与新表数据一致;

  • 将该子服务中的数据库操作逐步迁移到新表,分批上线;

  • 全部迁移完成后,切断同步,该服务拆分结束。

这种方案能够做到平滑迁移,但其中却有几个棘手的问题:

  • 旧表新表的数据一致性如何保证?

  • 如何支持异构迁移?(由于旧表的设计往往非常范式化,因此拆分后的新表会增加很多来自其它表的冗余列)

  • 如何保证数据同步的实时性?(往往会先迁移读操作到新表,这时就要求旧表的写操作必须准实时地同步到新表)

典型的解决方

文章来源: wenyusuran.blog.csdn.net,作者:文宇肃然,版权归原作者所有,如需转载,请联系作者。

原文链接:wenyusuran.blog.csdn.net/article/details/107833069

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。