阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 勇哥java实战分享 「勇哥」欢迎转载，保留摘要，谢谢！

• 前言
• 1 业务场景
• 2 线程池模式
• 3 本地内存 + 定时任务
• 4 MQ 模式
• 5 Agent 服务 + MQ 模式
• 6 总结

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

前言

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

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

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

1 业务场景

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

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

1. 读取课程视频信息 :

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

2. 写入课程观看行为记录 :

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

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

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

1. 优化 SQL 语句；
2. 提升 MySQL 数据库硬件配置 ;
3. 分库分表。

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

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

于是，我们想到了第二种方案：写请求异步化。

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

2 线程池模式

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

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

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

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

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

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

使用线程池模式，需要注意如下几点：

1、线程数不宜过高，避免占用过多的数据库连接 ;

2、需要考虑评估线程池队列的大小，以免出现内存溢出的问题。

3 本地内存 + 定时任务

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

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

示例代码如下：

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

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

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

4 MQ 模式

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

核心流程如下：

1. 控制器接收写请求，将观看视频行为记录转换成消息 ；

2. 教研服务发送消息到 MQ ，将写操作成功信息返回给前端 ；

3. 消费者服务从 MQ 中获取消息 ，批量操作数据库 。

这种方案优点是：

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

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

5 Agent 服务 + MQ 模式

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

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

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

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

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

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

6 总结

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

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

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

第二层：异步的外功心法

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

• 线程池模式

• 本地内存 + 定时任务

• MQ 模式

• Agent 服务 + MQ 模式

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

第三层：异步的本质

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

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

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