京东云开发者｜mysql基于binlake同步ES积压解决方案-低调大师

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

2022-11-08 355

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进行分析，同时针对积压推荐俩种方案，并从性能合理利用及扩展性分析，简要介绍方案二并行有序消费策略，希望能够帮助大家，如有问题，请随时指出！

作者：任洪波

微信关注我们

原文链接：https://my.oschina.net/u/4090830/blog/5589278

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

京东云开发者｜代码评审的价值和规范

评审目的代码评审的目的就是为了保证公司整体代码的健康状况随着不断迭代，始终保持一个较高的水平，所有在评审中使用的工具和流程都应是为此目的而设计的。评审原则鼓励质疑保持代码风格，遵守开发规范优先设计原则，尊重个人偏好重视每一行代码尽可能采用面对面的形式评审时机研发流程应该是严密的、有节奏的，而个体的代码质量会影响整体交付进度，所以请第一时间启动代码评审，最晚不要超过早期测试阶段。如果是异步评审的机制，评审过程最好不要超过一个工作日，如果评审时间较长，请在开始评审时进行初步反馈。评审范围 1. 功能这个Change List是否达到了预期目标？并发、数据权限、性能、竞态条件等一系列边缘异常是否合理规避？ 2. 复杂性新增的复杂是否是值得的？复杂设计的实现是否是可读的？抽象定义是否是优雅整洁的？鼓励通过设计提高可扩展性，但不可“面向未来做设计”，二者之间的界限应该是：是否能够看到明确的演进方向（actual shape）和需求 3. 单元测试是否有单元测试？单元测试是否具有良好的可读性？每一个测试是否有断言？是否能覆盖尽可能多的逻辑分支？ 4. 命名...

2022-11-08

347

对于HarmonyOS应用来说，因鸿蒙生态的发展仍在快速成长期、整体开发经验相对较少，自行搭建用户运营能力成本比安卓应用高、风险也比较大；但是为保证用户体验和运营效果，运营策略、工具等还是应用运营阶段不可忽视的内容；并且HarmonyOS应用虽然是“新同学”但也被赋予“重望”，拉新、促活、留存的KPI也和安卓应用一样，是运营同学必须要重视的三大指标。 HUAWEI AppGallery Connect或许能给你提供一些新的思路，让方案的制定有数据支撑，而不是无效的讨论后拍脑袋的选择；可以根据热点、节假日主题、舆情等，快速灵活修改应用外观主题以及功能；让合适的信息提示出现在合适的时间地点，避免应用被用户“禁言”；让您在各个平台投放的链接带来最大的转化，而不是在各种跳转过程中流失大半用户。是不是听起来很心动？不妨看看我们的方案吧！ Step 1：通过A/B测试了解用户喜好，为促进用户活跃打好基础 A/B测试基于数据支撑运营决策，通过一组或多组对照实验的数据对比，测试用户对于应用的界面、文案等偏好。您可以利用A/B测试的实验数据，分析、了解用户喜好，有效提高日活、月活等指标。如果您要...

2022-11-08

466

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。