DTS数据上报优化

掘金原文：https://juejin.cn/post/6966127447527915551

背景

现象

• 业务基于ElasticSearch为产品提供了全文搜索能力，需要及时将DB变更数据异构到ES，供业务查询，即DTS（Database To ES）；
• 由于数据变更入口较多，使用Canal原生客户端去监听数据binlog变更，并将数据顺序投递到MQ，基础搜索服务消费端消费，过滤，数据组装后，上报到ES，即DB->Canal->MQ->Comsumer->ES；
• 目前整体DB->ES数据同步较慢，处理速度QPS为60左右，在遇到洗数据/导入资源等大量数据变更时，往往造成大量Canal-MQ（顺序）消息堆积，业务数据同步时延；
• 一些对数据可见性敏感的场景 （比如个人创建习题后需马上可见），由于多条件查询走DB较慢，目前实现方案走的ES，大延迟对会对此类场景造成较大业务受损，不可接受；
• 当前通过规避高峰期数据量清洗去减少上述影响，对日常洗数据造成不便，同时隐含造成线上业务用户体验差；

现数据量-同步延时对比

数据变更量	DTS数据同步
60 < x < 600	1s~10s
3600<x<10800	1min~3min
10800<x	>3min

问题分析

现实现方案

耗时分析

1.DB→ES上报主要通过MQ削峰解耦，当DB数据大量变更时容易造成MQ消息堆积；无非就以下三种情况:

• 生产者生产消息过快：
• 消费者消费消息过慢；
• 两种现象同时存在；
  2.DB->ES→可被检索到，主要有几个同步耗时点：（参照上图，红色字体为严重耗时点）
• 步骤1：binlog日志发送到