一、延迟消费案例

1、批量洗数据

问题1（重要）：
运营要求恢复线上一批论坛帖，数量涉及100w+，当时发邮件给DBA进行了update操作，
执行后一切正常，但是过一段时间运营反馈Admin运营后台数据有问题，没有新帖子进入了，
造成了线上事故。
原因：
在执行update操作后，由于Canal同步Binlog是顺序同步的，Canal一直忙于同步update
的100w+的数据，出现了阻塞。导致新创建或更新的帖子没有及时同步到运营后台。
解决方案：
在引入Canal之后，就要禁止大批量的进行insert、update、delete操作，需要使用执行条数+
中途休眠的方式进行少量多次的修改数据。

2、批量修改昵称

用户业务批量修改用户昵称，MQ通知社区业务，社区业务修改主贴发布人昵称、最后回复昵称、回帖发布人昵称等数据，造成延迟

二、使用架构分析

1、后台复杂查询影响主库使用，在后台做最复杂查询使用
2、
3、主贴、回帖相关扩展字段，也通过也写入ES中，做多条件查询使用

三、延迟优化调整

1、instace拆分

缺点: 一个instance相当于一个slave实例子。多个instance 同时运行，会增加MySQL Master库的压力

2、数据异构使用(优化场景)

(1)、Canal binlog的变化，只用来捕捉发生变化的主贴id、回帖id(exchange id)
(2)、主键id，回源查从库，获取当前最新数据

3、Canal client 处理后使用MQ加快数据消费

(1)、Canal client 消费binlog，rowChange解析后进行写的处理
(2)、id %取余发送消息队列，使用消息队列进行存储

4、打印出RowChange的sql信息

5、优化ES的save存储

canal获取数据后，需要单条判断改变，存储ES时修改为saveAll()批量存储

6、延迟监控及修复

(1)、ES-TASK定时任务，查询ES中Id最大值喝数据库中最大值进行比较,判断延迟情况
(2)、报警。判定延迟后，发送邮件、企业微信报警
(3)、接口刷新。刷新id范围: minId(ES当前最大值)~maxId(数据库最大值)之间新增的数据到ES中，保证审核