关于mysql:京东云开发者|mysql基于binlake同步ES积压解决方案

2次阅读

共计 1970 个字符,预计需要花费 5 分钟才能阅读完成。

1 背景与指标

1.1 背景

国内财务泰国每月月初账单工作生成,或者重算账单数据,数据同步计划为 mysql 通过 binlake 同步 ES 数据,在同步过程中发现计费事件表,计费后果表均有提早,ES 数据与 Mysql 数据不统一,导致业务页面查问数据不精确,局部外围计算通过 ES 校验失败

1.2 指标

解决 binlake 到 JMQ 积压同步 ES 提早问题

2 以后业务流程

2.1 流程图

现有业务根本流程如下图,蕴含经营端和内部数据接入,整体操作到数据存储流程

2.2 数据流

3 问题剖析

3.1 问题景象

jmq 积压,报警
国内站截图如下

3.2 筛查剖析

遍及:JMQ 默认生产者发送音讯 QPS 受到主题的 broker 数量影响,(8w/s)/broker

3.2.1 MQ 积压剖析

1)剖析起因一、ES 写入量大,导致 ES 写入 QPS 瓶颈

ES 写入瓶颈须要进行压测,能力确定理论是否达到瓶颈;
通过查问集群负载,写入队列有无积压,cpu 高不高,来定位
以下为调整 MQ 批量生产大小后的 ES 监控
写入队列无积压,CPU 不高,写入 QPS 没有达到瓶颈

2)剖析起因二、ES 写入慢导致生产积压

ES 解析服务解析慢,瓶颈在 ES 解析处
依据以后零碎 CPU、负载信息定位是否服务器性能满负荷,是否扩容
无报警信息,整体运行安稳,根本排除业务资源达到瓶颈问题引起写入慢

MQ 生产端生产慢,瓶颈在生产并发处
以后主题分片数 3,队列数为 15,默认最大并发数为 15*10,报警过后入队数 500~700/s
定位问题,为 MQ 生产慢,其根本原因为受到 ES-Parse 业务零碎处理速度影响

3.3 长期解决计划

开启 mq 并行生产策略,写入 QPS 显著减少

4 如何晋升生产速率,晋升写入 ES 速率

造成问题起因外围点是 MQ 积压,业务零碎生产慢,MQ 入队数大于出队数,导致积压

4.1 原理剖析

4.1.1 存储流程解析

第一步:binlake 订阅 mysql binlog
第二步:发 MQ,JMQ 数据传输
第三步:生产 JMQ 数据,ES Paser 数据解析,
第四步:数据存储

4.1.2 binlake 基本原理

4.1.3 binlake 发送 MQ 过程

4.1.4 JMQ 生产原理

JMQ 生产默认就是批量生产
生产原理如下图

批量生产与并行生产原理如下图

通过剖析,在未开启并行生产前提下,以后主题最大处并发的生产解决能力即是队列数

4.2 晋升生产速率的几种计划

4.2.1MQ 减少生产速度办法

扩容,减少并发生产能力
针对 MQ 默认状况下,所有扩容都能解决问题,增大分片数,减少队列数
须要额定资源,申请扩容新的 broker,同时思考减少生产端实例

减少批量大小
首先保障,业务零碎 (ES-Parse) 生产 MQ 音讯,解决 10 条和解决 100 条速度根本一样
实际:国内财务针对此办法进行代码逻辑革新

开启并行数
实践上减少(并行数 / 批量数)的倍数并发解决能力
要求数据无序,针对乱序,数据存储,不影响业务

4.2.2 并行有序的计划

1)实现数据幂等性,减少缓存,并行生产策略

计划流程

根底实现流程:

1)依据 binlake 发送 mq,在 mq 端开启并行生产,确保并行生产
2)依据业务单号对,单号加锁(如麦哲伦对运单号加锁,即对单号加分布式锁),依据对应的 ID 获取 ES 数据。
3)校验数据是否无效,若查问无数据,则间接新增;若查问的数据状态大于以后数据状态,则间接摈弃,若查问状态小于以后数据状态,则间接更新数据
4)更新缓存并开释锁

长处

  • 指定资源状况下,增大生产端并发
  • 能够开启并行生产,且保障程序生产
  • 能够使得资源充分利用,减少生产性能

毛病

  • 减少毫秒级缓存额定开销

实际:麦哲伦运单核心针对此计划实现 binlake 数据同步 ES

2)binlake 主题散发子主题,显示增大并发策略

长处:

  • 逻辑绝对简略,不须要开发简单逻辑,无需引入额定中间件
  • 预估转发音讯速率即是理论解决速率

晋升速率计算:

  • 原主题单线程解决一条数据存储到 ES 工夫为 es_time,举例为 50ms,每秒吞吐量是 20 条
  • 现单线程转发 MQ 一条数据工夫为 trans_time,举例为 20ms,每秒转发吞吐量 50 条
  • 假如转发 topic 为 N 个子主题,则吞吐量实践为 n *20 理论小于转发吞吐量 50,此处多子主题对 cpu 核数竞争
  • 晋升吞吐量为 =(1000ms/trans_time)转发吞吐量 – (1000ms/es_time)原有吞吐量

毛病

  • 扩展性不好,理论后果有待验证,小于预估值

实际:跨境赤道散发核心实现相似性能实际,音讯转发,其余 MQ 实现

3)俩种计划比照

主题较少一个俩个主题状况下,且业务解决比拟耗时状况下,不想额定开发,可选计划二
长期计划抉择计划一,并行生产策略,可伸缩性,可扩大,反对动静扩容

5. 总结

针对 MQ 积压问题,并行生产能够是解决问题的一大利器,本文从 binlake 同步 ES 进行剖析,同时针对积压举荐俩种计划,并从性能正当利用及扩展性剖析,简要介绍计划二并行有序生产策略,心愿可能帮忙大家,如有问题,请随时指出!


作者:任洪波

正文完
 0