首页 文章 精选 留言 我的

精选列表

搜索[云客服]，共10000篇文章
优秀的个人博客,低调大师

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

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进行分析，同时针对积压推荐俩种方案，并从性能合理利用及扩展性分析，简要介绍方案二并行有序消费策略，希望能够帮助大家，如有问题，请随时指出！ 作者：任洪波
2022-11-08
优秀的个人博客,低调大师

京东云开发者｜探寻软件架构的本质，到底什么是架构？

不论是开发人员还是架构师，我们都一直在跟软件系统打交道，架构是在工作中出现最频繁的术语之一。那么，到底什么是架构？你可能有自己的答案，也有可能没有答案。对“架构”的理解需要我们不断在实践中思考、归纳、演绎，形成自己的认知。 1 到底什么是软件架构 ？ 定义 ”架构是什么“ 是件非常困难的事情，不同的组织对于软件架构有不同的定义，每个人心中也有自身对于系统架构定义的认知。就好比我们无法百分之百表述模型而只能产出模型不同维度的视图，对架构进行完备的定义是不可能的。 “道可道，非常道。名可名，非常名”。 行业内不同的组织和个人从不同的视角对 “什么是架构” 进行了定义或阐述。 IEEE 关于架构的定义 the fundamental organizationof a system, embodied in its components, their relationshipsto each other and the environment, and the principlesgoverning its design and evolution --ANSI/IEEE 将系统架构定义为：架构是系统组织结构+组件及联系（组件间以及组件和环境之间）+原则的组合。通过图形化的形式表述该架构定义如下图所示，这是一个非常简洁、概念清晰的定义，其言简意赅的表达了架构的几个核心要素： •系统的组织：表达系统的宏观结构 •组件及联系：组件化的思维，同时突出了环境要素。组件表达了系统的模块化，组件相互之间及组件与环境之间的关联表达元素间的相互作用。 •原则：用于指导设计和系统演进的原则 大师Martin Fowler对于架构的定义有着更加简洁的抽象，Martin Fowler 认为软件架构是：重要并且难以改变的决策。架构设计是关于权衡的艺术，架构设计过程中充满了各种各样的决策，这些决策也终将反应系统架构。 Software Architecture = Importantand hardto change decisions -- Martin Fowler 而Ralph Johnson则对架构有更加 “泛化” 的定义：软件架构就是重要的东西，不论它是什么！ The software architecutre is the important stuff! Whatever it is ! -- Ralph Johnson 以上的定义从高层抽象视角对什么是架构给予了自己的回答，相比之下，Neil Ford 从架构组成元素入手，从更偏向实践的角度对架构进行了阐述。核心思想是软件系统的架构包括以下组合元素： •结构：应用系统所选择的架构风格，比如微服务架构、单体架构还是SOA等 •架构属性：系统的非功能性属性，比如性能、可用性、可维护性等 •架构决策：系统设计过程中重要的架构决策 •设计原则：设计过程中的指导性原则 结构 结构是系统架构的重要组成部分，其从宏观上表述了系统的结构组成。架构设计的核心任务之一是为系统选择合适的架构风格。比如，架构师基于上下文的权衡，可以选择模块化单体架构风格，也可以选择微服务架构风格。 架构属性 架构属性亦称质量属性，或非功能属性，通常表示系统需要具备或满足的某种 “能力”，比如高性能、可扩展性、弹性、伸缩性、容错性、可测试性、可维护性等等。架构设计的目标需要关注系统需要满足的架构属性，架构最终要体现对架构属性支持的相关架构决策。架构属性众多，系统需要关注的是这些架构属性的子集，具体的某次特定的架构设计所需要关注的架构属性需要依据问题域的上下文而具体分析。同时，不同的架构属性间可能存在冲突，这种情况同样需要架构师的权衡和决策。 架构决策 架构决策是系统架构设计过程中对解决方案的选择，其描述了系统必须遵循的规则。架构决策随着权衡分析而自然存在，其是系统架构设计的重要维度之一。并不是所有的决策都是架构决策，架构决策应该关注对系统有重要影响的部分。比如对架构风格的选择对系统存在重要影响，其改变的成本较高，理当属于架构决策的范畴。比较典型架构决策包括但不限于： •直接影响高优先级的架构属性 •修改对外接口：对外提供的接口修改往往需要进行充分影响分析 •引入或者移除依赖：依赖的加入和移除往往标示着组件能力的引进和废弃 •改变系统的通用结构：工程结构是应用架构的重要维度之一 •迫使研发人员改变开发方式 •接受战略性技术债：重构影响较大的技术债往往对现有系统会有较大影响 注：架构决策建议以轻量级的文档化形式进行记录，参考文章 《轻量级的架构决策记录机制》一文 设计原则 设计原则与架构决策不同，其本质区别是：设计原则是一种指导，而非强制的规则。架构决策需要遵守，设计原则提供参考性指引。 比如，设计原则可能是：在可能的情况下，跨系统间的通信尽可能使用异步消息机制以提高性能和降低耦合。 以上对架构的定义各有特点： •IEEE定义更加结构化和规范化 •Martin Fowler的定义侧重架构决策的重要性 •Ralph Johnson 则更加泛化，突出 “重要” 这一核心因子 •Neil Ford则更具象化 我个人更倾向于Ralph Johnson 对于架构的抽象化定义，简单却不失对架构本质的阐述，这也是我在工作中判断架构边界的准则之一。 2 架构设计的边界 如果你是团队的架构师，你是否有以下困惑： •系统的架构应该设计到什么粒度？ •架构设计是否要足够详细以便能直接指导开发人员开展编码工作？ 如果你是团队的核心开发人员，你是否 “抱怨” 过： •"架构设计" 太过详细，涵盖了实现的 “细枝末节”，自己除了CRUD没有发挥的空间 •"架构设计" 太过宏观，基于设计方案根本无法指导开发，自己还得重新设计 很多架构师自身对架构和设计的边界缺乏深入认知，相比于对架构边界的缩小，更多时候会出现架构设计边界放大的情况： 架构师把架构设计当作详细的技术方案设计，牢牢把控系统实现的所有细节，产出大量的设计文档，然后交由核心开发人员做代码实现的执行工作。 这种现象会导致如下问题： •压缩了团队核心开发人员的设计发挥空间，不利于其技术水平及认知的提升 •作为架构师你真的能讲所有的细节都Cover住吗？即使耗费巨大精力完成了 “完备” 的设计，来自一线开发所面临的各种场景是否能够提前预知和捕获？ •如果需求迭代持续如此，作为核心开发人员多半会有所 “怨言” •作为团队的架构师精力有限，持续的细节输出会耗费巨大精力，而无法关注更加宏观的层面 •....... 以上问题的根源是什么？不能明确架构设计的边界！ •架构设计与设计（实现相关）的边界或粒度问题 •团队架构师与开发人员间的职责边界 判断架构边界的前提之一是：明确架构和设计的关系！ 所有的架构都是设计，但设计不一定是架构！ 从架构的定义看架构设计的边界，选取两个视角： •架构是系统中重要的东西！无论它是什么（之所以重要，是因为改变的成本高） •架构设计涵盖系统中重要的架构决策 所以，架构设计应该涵盖系统中重要的东西，这些 “重要的东西” 可能是： •应用架构风格的选择 •子系统间信息通信的方式 •工程采取的分层以及层间约束 •工程应该遵循的开发规范 •工程引入的三方类库，或者三方框架 •高优先级的架构属性：比如某次需求建设非常关注系统的性能，或者扩展性等架构属性 •其它 "重要的东西" 架构设计涵盖了系统所需的重要的架构决策，从宏观层面对系统实现予以指引。而详细的设计则为具体的开发实现提供指导，比如，详细的E-R图设计、具体的代码级别的模式选择、某个组件的具体实现等等。 架构不是一成不变，需要持续演进，而实现相关的设计也可能在项目进行中持续变化，因此，二者不能完全割裂，而是需要在实现过程中进行双向反馈： •架构设计信息要高效的同步至开发人员 •实现过程中的变更同样也要回向反馈至架构，以便对架构设计进行调整 在进行架构边界判定时要注意一个至关重要的因子：上下文！！！以上的判断准则必须要给定的上下文中才有价值。 比如：实现过程中大家经常会适用一些设计模式，例如策略模式。那么，这种设计模式的选择是属于架构设计还是详细的实现设计？答案就是：It depends!!! 具体情况，具体分析。 如果当前上下文，我们非常关注系统的扩展性，该架构属性是我们高优先级的架构属性，那么，核心模块的策略模式的应用可以看作是架构设计的范畴。而如果上下文中扩展性不是我们关注的高优先级的架构属性，相比我们更关注性能，那么，这种代码级的设计模式选择应该属于架构设计的范畴之外了，而需要划分到实现设计层面，交由核心开发自主决定。 3 架构模式（Patterns）与架构风格（Styles） 架构模式和架构风格是极容易混淆的两个概念，很多开发人员将其理解为同一事物，而实际上二者有本质区别。 •架构风格是系统设计的顶层抽象，从宏观视角表述我们的系统组成。更进一步，架构风格聚焦于系统的分层、模块以及交互形式。 •架构模式聚焦于对重复出现问题提供解决方案 二者概念不同，并不存在冲突，其联系如下图所示： •架构模式可以应用于架构风格，在同一架构风格上下文内可以应用一或多种架构模式 •架构风格可以组合以产生新的架构风格 比较典型的例子是CQRS：CQRS本身是一种模式，将命令和查询的职责在不同维度进行分离。该模式我们可以在单体架构风格中使用，也可以在微服务架构风格中使用，当然也可以在SOA架构风格中使用。 4 为什么要做架构设计 ？ 至于 “为什么要做架构设计” 也是一个古老且频繁出现的问题，有太多的文章阐述为社么要架构设计：有的宏观，有的具体，有的“务实”，有的“务虚”。我把这个问题作为一个独立章节阐述，并不是想进行大篇幅的论述，只是想突出它的重要性，这个问题值得耗费一些精力去深入理解其背后的原因。但，在此不做展开过多说明，通过一句话来进行概括： 之所以要进行架构设计，是因为：重要 ！ •做，收益高 •不做，成本高 5 开发人员和架构师的知识模型 作为开发人员，更加关注知识的深度，以便有足够的知识储备满足工作需要。开发人员在职业生涯的早期，应该关注于自身知识储备的增长，并保持技术深度。 作为架构师，之所以技术的广度比深度更重要，是因为架构师的重要职责之一是进行架构决策。系统架构设计是关于权衡的艺术，在特定的问题域上下文下，架构师需要在诸多可行的解决方案间进行权衡和决策，这也对其技术广度提出了要求。开发人员成长为架构师，应该更加关注知识的广度，并在几个特定领域深耕，以便有足够的知识支撑架构决策。 虽然开发人员和架构师在知识域的关注点上存在差异，但在认知层面都可以统一到Bloom认知层次模型。该模型将认知层次划分为逐步递进的六个层次： •识记：识别和回溯事实性知识 •理解：理解事实的内涵 •应用：将事实、规则、概念、思想加以应用 •分析：将信息分解、关联、区分、实验、测试 •评估：将信息或思想的价值进行评价 •创造：整合不同的信息形成新的知识体系 不论是架构师还是开发人员，Bloom认知层次模型都适用。通过不断的学习扩展自身的知识体系，在识记、理解和应用的同时，要持续的培养分析、评估和创造的能力，逐步向高层次的认知水平提升。 但需要注意的是：知识不等于认知，避免陷入知识学习的陷阱。知识是无限的，没有人能够以有限的精力去学习无限的知识。不论是开发人员还是架构师，又或者其他角色，不应该只将精力投入在知识边界的扩充，而应该注重从知识到认知提升的转变。 吾生也有涯，而知也无涯。以有涯随无涯，殆矣！已而为知者，殆而已矣！ ----《庄子》 格物以致知，对表象不断的归纳、演绎直至事物的本象，探寻事物背后的规律，建立更高层的认知。这种认知层次由下及上的跃升有两种方式： •悟：由内向外，通过不断积累、持续思考，由量变到质变，直至 “开悟” •破：自外向内，高层次或不同的思想输入碰撞，加速认知层次的突破 为学日益，为道日损。损之又损，以⾄于⽆为。⽆为⽽⽆不为。 --《道德经》 6 结语 对架构定义的探讨实际上是一种朴素的 “格物” 的过程，每个人都应该寻找自己的答案。跳脱对架构定义探讨的视野，大家的工作和学习何尝不是如此呢 ？！大道至简，殊途同归，格物致知，与君共勉！ 作者：倪新明
2022-10-27

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

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

时间: 2026-09-19 大小: 189MB 下载: 8次
Spring

Spring

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

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册