掘金原文: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日志发送