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

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

数据异构

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

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

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

订单数据同构

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

订购数据异构

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

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

商品数据异构

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

总结

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

希望本文大家有所帮助。