java开发线上事故理解RocketMQ异步精髓

目录
  • 引言
  • 1 业务场景
  • 2 线程池模式
  • 3 本地内存 + 定时任务
  • 4 MQ 模式
  • 5 Agent 服务 + MQ 模式
  • 6 总结
    • 第一层:什么场景下需要异步
    • 第二层:异步的外功心法
    • 第三层:异步的本质

引言

在高并发的场景下,异步是一个极其重要的优化方向。

前段时间,生产环境发生一次事故,笔者认为事故的场景非常具备典型性

写这篇文章,笔者想和大家深入探讨该场景的架构优化方案。希望大家读完之后,可以对异步有更深刻的理解。

1 业务场景

老师登录教研平台,会看到课程列表,点击课程后,课程会以视频的形式展现出来。

访问课程详情页面,包含两个核心动作:

  • 读取课程视频信息 :

从缓存服务器 Redis 获取课程的视频信息 ,返回给前端,前端通过视频组件渲染。

  • 写入课程观看行为记录 :

当教师观看视频的过程中,浏览器每隔3秒发起请求,教研服务将观看行为记录插入到数据库表中。而且随着用户在线人数越多,写操作的频率也会指数级增长。

上线初期,这种设计运行还算良好,但随着在线用户的增多,系统响应越来越慢,大量线程阻塞在写入视频观看进度表上的 Dao 方法。上。

首先我们会想到一个非常直观的方案,提升写入数据库的能力

  • 优化 SQL 语句;
  • 提升 MySQL 数据库硬件配置 ;
  • 分库分表。

这种方案其实也可以满足我们的需求,但是通过扩容硬件并不便宜,另外写操作可以允许适当延迟和丢失少量数据,那这种方案更显得性价比不足。

那么架构优化的方向应该是: “减少写动作的耗时,提升写动作的并发度” , 只有这样才能让系统更顺畅的运行。

于是,我们想到了第二种方案:写请求异步化

  • 线程池模式
  • 本地内存 + 定时任务
  • MQ 模式
  • Agent 服务 + MQ 模式

2 线程池模式

2014年,笔者在艺龙旅行网负责红包系统相关工作。运营系统会调用红包系统给特定用户发送红包,当这些用户登录 app 后,app 端会调用红包系统的激活红包接口 。

激活红包接口是一个写操作,速度也比较快(20毫秒左右),接口的日请求量在2000万左右。

应用访问高峰期,红包系统会变得不稳定,激活接口经常超时,笔者为了快速解决问题,采取了一个非常粗糙的方案:

"控制器收到请求后,将写操作放入到独立的线程池中后,立即返回给前端,而线程池会异步执行激活红包方法"。

坦率的讲,这是一个非常有效的方案,优化后,红包系统非常稳定。

回到教研的场景,见下图,我们也可以设计类似线程池模型的方案:

使用线程池模式,需要注意如下几点:

  • 线程数不宜过高,避免占用过多的数据库连接池 ;
  • 需要考虑评估线程池队列的大小,以免出现内存溢出的问题。

3 本地内存 + 定时任务

开源中国统计浏览数的方案非常经典。

用户访问过一次文章、新闻、代码详情页面,访问次数字段加 1 , 在 oschina 上这个操作是异步的,访问的时候只是将数据在内存中保存,每隔固定时间将这些数据写入数据库。

示例代码如下:

我们可以借鉴开源中国的方案 :

  • 控制器接收请求后,观看进度信息存储到本地内存 LinkedBlockingQueue 对象里;
  • 异步线程每隔1分钟从队列里获取数据 ,组装成 List 对象,最后调用 Jdbc batchUpdate 方法批量写入数据库;
  • 批量写入主要是为了提升系统的整体吞吐量,每次批量写入的 List 大小也不宜过大 。

这种方案优点是:不改动原有业务架构,简单易用,性能也高。该方案同样需要考虑内存溢出的风险。

4 MQ 模式

很多同学们会想到 MQ 模式 ,消息队列最核心的功能是异步解耦,MQ 模式架构清晰,易于扩展。

核心流程如下:

  • 控制器接收写请求,将观看视频行为记录转换成消息 ;
  • 教研服务发送消息到 MQ ,将写操作成功信息返回给前端 ;
  • 消费者服务从 MQ 中获取消息 ,批量操作数据库 。

这种方案优点是:

  • MQ 本身支持高可用和异步,发送消息效率高 , 也支持批量消费;
  • 消息在 MQ 服务端会持久化,可靠性要比保存在本地内存高;

不过 MQ 模式需要引入新的组件,增加额外的复杂度。

5 Agent 服务 + MQ 模式

互联网大厂还有一种常见的异步的方案:Agent 服务 + MQ 模式。

教研服务器上部署 Agent 服务(独立的进程) , 教研服务接收写请求后,将请求按照固定的格式(比如 JSON )写入到本次磁盘中,然后给前端返回成功信息。

Agent 服务会监听文件变动,将文件内容发送到消息队列 , 消费者服务获取观看行为记录,将其存储到 MySQL 数据库中。

还有一种演进,假设我们不想在应用中依赖消息队列,不生成本地文件,可以采用如下的方式:

这种方案最大的优点是:架构分层清晰,业务服务不需要引入 MQ 组件。

笔者原来接触过的性能监控平台,或者日志分析平台都使用这种模式。

6 总结

学习需要一层一层递进的思考。

第一层:什么场景下需要异步

  • 大量写操作占用了过多的资源,影响了系统的正常运行;
  • 写操作异步后,不影响主流程,允许适当延迟;

第二层:异步的外功心法

本文提到了四种异步方式:

  • 线程池模式
  • 本地内存 + 定时任务
  • MQ 模式
  • Agent 服务 + MQ 模式

它们的共同特点是:将写操作命令存储在一个池子后,立刻响应给前端,减少写动作的耗时。任务服务异步从池子里获取任务后执行。

第三层:异步的本质

在笔者看来,异步是更细粒度的使用系统资源的一种方式

在教研课程详情场景里,数据库的资源是固定的,但写操作占据大量数据库资源,导致整个系统的阻塞,但写操作并不是最核心的业务流程,它不应该占用那么多的系统资源。

我们使用异步的解决方案时,无论是使用线程池,还是本地内存 + 定时任务 ,亦或是 MQ ,对数据库资源的使用都需要在合理的范围内,只有这样系统才能顺畅的运行。

以上就是java开发线上事故理解RocketMQ异步精髓的详细内容,更多关于java开发RocketMQ异步的资料请关注我们其它相关文章!

(0)

相关推荐

  • Springboot详细讲解RocketMQ实现顺序消息的发送与消费流程

    目录 一.创建Springboot项目添加rockermq依赖 二.配置rocketmq 三.新建一个controller来做消息发送 四.创建消费端监听消息消费消息 五.启动服务测试顺序消息发送与消费 如何实现顺序消息? 需要程序保证发送和消费的是同一个 Queue rocketmq默认发送的消息是进入多个消息队列,然后消费端多线程并发消费,所以默认情况,不是順序消费消息的:有時候,我们需要顺序消费一批消息,比如电商系统 订单创建.支付.完成操作,需要順序执行: RocketMQTemplat

  • RocketMQ消息发送流程源码剖析

    目录 正文 读源码 1 调用defaultMQProducerImpl.send() 2 设置过期时间 3 执行defaultMQProducerImpl.sendDefaultImpl()方法 sendDefaultImpl是发送消息的核心方法. 1 两个校验 2 获取topic路由信息 3 计算重试次数 4 执行队列选择方法 5 发送消息 正文 就是说,我们打了个比方,把RocketMQ比作码头上的一个小房子,来送孩子登船的家长比作生产者,拉走孩子们的船夫比作消费者,所以,RocketMQ的

  • java开发RocketMQ生产者高可用示例详解

    目录 引言 1 消息 1.1 topic 1.2 Body 1.3 tag 1.4 key 1.5 延迟级别 2 生产者高可用 2.1 客户端保证生产者高可用 2.1.1 重试机制 2.1.2 客户端容错 2.2 Broker端保证生产者高可用 引言 前边两章说了点基础的,从这章开始,我们挖挖源码.看看RocketMQ是怎么工作的. 首先呢,这个生产者就是送孩子去码头的家长,孩子们呢,就是消息了. 我们看看消息孩子们都长啥样. 1 消息 public class Message implemen

  • SpringBoot集成RocketMQ发送事务消息的原理解析

    目录 简介 原理 具体实现 消费者 消费者 生产者消息监听器 消息事务测试 正常测试 异常测试 代码调整 执行结果 总结 简介 RocketMQ 事务消息(Transactional Message)是指应用本地事务和发送消息操作可以被定义到全局事务中,要么同时成功,要么同时失败.RocketMQ 的事务消息提供类似 X/Open XA 的分布事务功能,通过事务消息能达到分布式事务的最终一致. 原理 RocketMQ事务消息通过异步确保方式,保证事务的最终一致性.设计的思想可以借鉴两个阶段提交事

  • Springboot详解RocketMQ实现消息发送与接收流程

    springboot+rockermq 实现简单的消息发送与接收 普通消息的发送方式有3种:单向发送.同步发送和异步发送. 下面来介绍下 springboot+rockermq 整合实现 普通消息的发送与接收 创建Springboot项目,添加rockermq 依赖 <!--rocketMq依赖--> <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-

  • Springboot详解RocketMQ实现广播消息流程

    RocketMQ消息模式主要有两种:广播模式.集群模式(负载均衡模式) 广播模式是每个消费者,都会消费消息: 负载均衡模式是每一个消费只会被某一个消费者消费一次: 我们业务上一般用的是负载均衡模式,当然一些特殊场景需要用到广播模式,比如发送一个信息到邮箱,手机,站内提示: 我们可以通过@RocketMQMessageListener的messageModel属性值来设置,MessageModel.BROADCASTING是广播模式,MessageModel.CLUSTERING是默认集群负载均衡

  • java开发线上事故理解RocketMQ异步精髓

    目录 引言 1 业务场景 2 线程池模式 3 本地内存 + 定时任务 4 MQ 模式 5 Agent 服务 + MQ 模式 6 总结 第一层:什么场景下需要异步 第二层:异步的外功心法 第三层:异步的本质 引言 在高并发的场景下,异步是一个极其重要的优化方向. 前段时间,生产环境发生一次事故,笔者认为事故的场景非常具备典型性 . 写这篇文章,笔者想和大家深入探讨该场景的架构优化方案.希望大家读完之后,可以对异步有更深刻的理解. 1 业务场景 老师登录教研平台,会看到课程列表,点击课程后,课程会以

  • java开发 线上问题排查命令详解

    前言 作为一个合格的开发人员,不仅要能写得一手还代码,还有一项很重要的技能就是排查问题.这里提到的排查问题不仅仅是在coding的过程中debug等,还包括的就是线上问题的排查.由于在生产环境中,一般没办法debug(其实有些问题,debug也白扯...),所以我们需要借助一些常用命令来查看运行时的具体情况,这些运行时信息包括但不限于运行日志.异常堆栈.堆使用情况.GC情况.JVM参数情况.线程情况等. 给一个系统定位问题的时候,知识.经验是关键,数据是依据,工具是运用知识处理数据的手段.为了便

  • JAVA线上常见问题排查手段(小结)

    在平时开发过程中,对于线上问题的排查以及系统的优化,免不了和Linux进行打交道.每逢大促和双十一,对系统的各种压测性能测试,优化都是非常大的一次考验.抽空整理了一下自己在线上问题排查以及系统优化的一些经验. 一.系统性能瓶颈在哪 我们常常提到项目的运行环境,那么运行环境包括哪些呢?一般包括你的操作系统.CPU.内存.硬盘.网络带宽.JRE环境.你的代码依赖的各种组件等等.所以系统性能的瓶颈往往是IO瓶颈.CPU瓶颈.内存瓶颈或者程序导致的性能瓶颈 登录到服务器上,我们使用TOP命令可以很全面的

  • JAVA线上常见问题排查手段汇总

    在平时开发过程中,对于线上问题的排查以及系统的优化,免不了和Linux进行打交道.每逢大促和双十一,对系统的各种压测性能测试,优化都是非常大的一次考验.抽空整理了一下自己在线上问题排查以及系统优化的一些经验. 一.系统性能瓶颈在哪 我们常常提到项目的运行环境,那么运行环境包括哪些呢?一般包括你的操作系统.CPU.内存.硬盘.网络带宽.JRE环境.你的代码依赖的各种组件等等.所以系统性能的瓶颈往往是IO瓶颈.CPU瓶颈.内存瓶颈或者程序导致的性能瓶颈 登录到服务器上,我们使用TOP命令可以很全面的

  • java开发RocketMQ消息中间件原理基础详解

    RocketMQ 是什么 Github 上关于 RocketMQ 的介绍: RcoketMQ 是一款低延迟.高可靠.可伸缩.易于使用的消息中间件.具有以下特性: 支持发布/订阅(Pub/Sub)和点对点(P2P)消息模型 在一个队列中可靠的先进先出(FIFO)和严格的顺序传递 支持拉(pull)和推(push)两种消息模式 单一队列百万消息的堆积能力 支持多种消息协议,如 JMS.MQTT 等 分布式高可用的部署架构,满足至少一次消息传递语义 提供 docker 镜像用于隔离测试和云集群部署 提

  • java开发RocketMQ之NameServer路由管理源码分析

    目录 1.前言 2.路由元信息 3.路由注册 3.1Broker路由注册 3.2NameServer处理路由注册 3.3路由删除 3.3.1Broker异常关闭 3.3.2Broker正常关闭 3.4路由发现 3.5总结 1.前言 NameServer主要作用是为消息消费者和消息生产者提供关于主题Topic的路由信息,那么NameServer需要存储路由的基本信息,还要管理Broker节点,包括路由注册.路由删除等. 2.路由元信息 路由元信息主要由RouteInfoManager来进行管理,这

  • Java线上问题排查神器Arthas实战原理解析

    概述 背景 是不是在实际开发工作当中经常碰到自己写的代码在开发.测试环境行云流水稳得一笔,可一到线上就经常不是缺这个就是少那个反正就是一顿报错抽风似的,线上调试代码又很麻烦,让人头疼得抓狂:而且debug不一定是最高效的方法,遇到线上问题不能debug了怎么办.原先我们Java中我们常用分析问题一般是使用JDK自带或第三方的分析工具如jstat.jmap.jstack. jconsole.visualvm.Java Mission Control.MAT等.但此刻的你没有看错,还有一款神器Art

  • Java集合去重导致的线上问题

    目录 前言: HashSet源码 性能对比 前言: 在工作中一次排查慢接口时,查到了一个函数耗时较长,最终定位到是通过 List 去重导致的. 由于测试环境还有线上早期数据较少,这个接口的性能问题没有引起较大关注,后面频繁超时,才引起重视. 之前看<阿里巴巴Java开发手册>里面有这样一段描述: 如果需要这本书资源的网上下载也行,私聊我发你也行 今天我就结合源码聊聊Set是怎样保证数据的唯一性的,为什么两种去重方式性能差距这么大 HashSet源码 先看看类注释: 看类注释上,我们可以得到的信

  • webuploader在springMVC+jquery+Java开发环境下的大文件分片上传的实例代码

    注意: 1,webuploader上传组件会和jQuery自带的上传组件冲突,所以不要使用<form>标签中添加上传文件的属性; enctype="multipart/form-data" 2.并且屏蔽ApplicationContext-mvc.xml里面的拦截配置! <!-- 上传拦截,如最大上传值及最小上传值 --> <!--新增加的webuploader上传组件,必须要屏蔽这里的拦截机制 <bean id="multipartRes

随机推荐