基于 Binlog + Flink 实现多表数据同构/异构方案

基于 Binlog + Flink 实现多表数据同构/异构方案

 

什么是数据异构?简单讲,就是将数据进行异地数据异构存储。

数据异构

服务市场使用 BinLake(京东 MySQL 的 Binlog 日志实时采集、统一分发、消息订阅和监控服务)进行数据异构,即通过订阅 MySQL 的 Binlog 日志,通过接收 JMQ 进行数据异地构建存储。

数据异构主要有两种方式,一种是顺序消费、另一种是并行消费。其中,在进行订单、订购的数据异构时是要求保证严格的顺序性的,因为并行消费是无法保证订单的先后顺序的,所以可能造成数据不一致。

但顺序消息的问题主要是单点消费效率慢的问题,以及消费出了问题就会造成阻塞,之前使用服务器进行消费,通过 ip 限制保证单点,后期切换到流式计算平台(strom/flink)进行处理,流式计算在并行写 es 和 jimdb 有天然的优势,但如果异常情况下出现写操作失败,对于 JMQ 的重试系统要做好幂等操作的处理。

订单数据同构

订单数据为顺序消费,一条订单数据,在插入 MySQL 时通过订阅 Binlog,通过 Flink 异构到 Elasticsearch 中。由于是单条记录,不涉及并发消费,可以订阅 Master MySQL。

基于 Binlog + Flink 实现多表数据同构/异构方案

 

订购数据异构

订购数据的数据异构有些不同,订购数据分为主表和扩展表,在 MySQL 中两张表的数据需要整合异构成一条记录存储到 Es 中。如果采用并行消费,则会出现 Flink 接收消息先后问题,简单说,就是有可能先接收到扩展表的 binlog 后接收到主表的 binlog。

所以改造的方案是,只订阅主表的 binlog,接收到消息后,通过反查 MySQL 的方式,进行数据整合,然后进行数据异构。考虑到对 MySQL 的压力,不能反查 Master MySQL,需要订阅 Slave MySQL。所以,这个方案的缺点是,不仅增加了 IO 的交互,而且数据异构的延迟较大。

基于 Binlog + Flink 实现多表数据同构/异构方案

 

商品数据异构

而商品数据异构是使用并发消费的,因为商品数据不需要保证严格的顺序,所以,商品数据异构的方式采用和订购数据同样的模式,由于商品数据需要缓存,所以,不仅要 Elasticsearch,还要写 redis,这样的架构设计使用 Flink 也很简单。

基于 Binlog + Flink 实现多表数据同构/异构方案

 

总结

Flink 被越来越多业务所使用,作为高性能的分布式流处理平台,不断的改进我们所使用的技术,以及不断突破我们原有的固化思维。其实,最早的设计方案是在系统里接收 Binlog 消息,然后处理,再异构存储写入 Elasticsearch。而采用 Flink,逐步理解流处理模式,我认为更在于思想理念上的改变。

希望本文大家有所帮助。

 


获取以上Java高级架构最新视频,

欢迎加入Java进阶架构交流群:142019080。直接点击链接加群。
https://jq.qq.com/?_wv=1027&k=5lXBNZ7
 

没有更多推荐了,返回首页