基于binlog的使用摸索

        因为作业系统，难免会遇到这样一些问题，就是报表，各种纬度查询，而我们项目又不是基于大数据框架来做的，所以在满足多维度方面，以及实时性要求方面就稍显逊色

如果基于现有系统业务，让你去实现一个统计类报表，你的方案？

第一种方案，各种表数据关联，然后满足业务要求。问题来了，我们有些表用了分表，有些表又是跨库了，怎么办？

方案二，我们建一张大表，然后把关联表的数据都往这张大表里塞，然后去查询。这里的问题就是，这张表很快就会被撑爆掉，直到最后查不了。后来我们引入es，但是前提还是基于这张大表，比如我们的库存流水记录

现有实现，我们通过定时任务捞取增量数据然后往es推送，然后查询直接通过es查询，解决了多维度的查询问题。这里我们发现一个问题，那就是报表的实时性。如果现场业务允许你的延迟，那么你可以这么做。

为了低延时，我们引入binlog方案

binlog方案是基于目前数据库的binlog，我们直接读取过来，然后直接推送es。

这里需要考虑以下问题？

如何获取binlog？binlog和作业系统如何打通？binlog的解析？binlog的批量推送es，es能扛多大并发？

如何获取binlog,这里我们是主从备份的方案中获取灵感，再加一个备库，接到主库上。接到之后，我们直接抛到kafka，这里这样做的目地就是binlog的量非常大，也是考虑到kafka出色的并发能力，目前是整库迁移方案，所以有个问题就是如果这个库的表数量很大，那么我们便利我们所需要的表，也很耗时，这就违背了我们的初衷。后期需要迭代表的迁移方案。

发布=订阅，我们首先要知道的就是，binlog本身就是有顺序的，然后通过kafka一批过来，而我们的作业系统又是集群架构，这就会因为并发导致一系列问题。比如，因为最新操作的binlog，却因为作业系统并发最先执行，而早期的binlog却最后执行，这就造成了老数据覆盖新数据。这是一个很严重的问题。所以我们就做了这样这个规定，每张表，我们使用一个主题，任何时刻只允许一台机器消费。

所以建立好这样的规则之后，我们就拿到了这张表的binlog，并且一定是顺序拿到的。接到数据操作之后，开始解析，解析就是把binlog转化为我们的要操作的数据。

binlog结构，每一步数据表的操作，都会有一条binlog，分为两部分，操作头，操作数。操作头里包含了我们的表名，以及关键字，比如insert,update等。操作数分为，操作前和操作后的数据两部分。

一批解析完，然后逐条推送es，有必要这样做？

因为我们每拿到一批，已经是有先后顺序，那我们只要拿到这一批中，操作时间最新的那一条不就可以么，这样前面的全部省略，推送es的并发也就会降下来

目前该方案还在摸索阶段，成熟以后，会再做一次分享