一次线上事故，我顿悟了异步的精髓

た入场券 2024-03-02 10:16 69阅读 0赞

## 一次线上事故，我顿悟了异步的精髓 ##

*  在高并发的场景下，**异步**是一个极其重要的优化方向。
 *  前段时间，生产环境发生一次事故，笔者认为事故的场景非常具备**典型性** 。
 *  写这篇文章，笔者想和大家深入探讨该场景的架构优化方案。希望大家读完之后，可以对**异步**有更深刻的理解。

### 业务场景 ###

*  老师登录教研平台，会看到课程列表，点击课程后，课程会以视频的形式展现出来。
 *  ![在这里插入图片描述][550fa9be560b45e7a039b96ca13ae253.png]
 *  访问课程详情页面，包含两个核心动作：
    
    1.  **读取课程视频信息** : 从缓存服务器 Redis 获取课程的视频信息 ，返回给前端，前端通过视频组件渲染。
    2.  **写入课程观看行为记录** : 当教师观看视频的过程中，浏览器每隔3秒发起请求，教研服务将观看行为记录插入到数据库表中。而且随着用户在线人数越多，写操作的频率也会指数级增长。
 *  上线初期，这种设计运行还算良好，但随着在线用户的增多，系统响应越来越慢，大量线程阻塞在写入视频观看进度表上的 Dao 方法。上。
 *  首先我们会想到一个非常直观的方案，**提升写入数据库的能力**。
 *  优化 SQL 语句；
 *  提升 MySQL 数据库硬件配置 ;
 *  分库分表。
 *  这种方案其实也可以满足我们的需求，但是通过扩容硬件并不便宜，另外写操作可以允许适当延迟和丢失少量数据，那这种方案更显得性价比不足。
 *  那么架构优化的方向应该是： **“减少写动作的耗时，提升写动作的并发度”** ， 只有这样才能让系统更顺畅的运行。
 *  于是，我们想到了第二种方案：**写请求异步化**。
    
     *  线程池模式
     *  本地内存 + 定时任务
     *  MQ 模式
     *  Agent 服务 + MQ 模式

### 线程池模式 ###

*  2014年，笔者在艺龙旅行网负责红包系统相关工作。运营系统会调用红包系统给特定用户发送红包，当这些用户登录 app 后，app 端会调用红包系统的激活红包接口 。
 *  激活红包接口是一个写操作，速度也比较快(20毫秒左右)，接口的日请求量在2000万左右。
 *  应用访问高峰期，红包系统会变得不稳定，激活接口经常超时，笔者为了快速解决问题，采取了一个非常粗糙的方案：
 *  “**控制器收到请求后，将写操作放入到独立的线程池中后，立即返回给前端，而线程池会异步执行激活红包方法**”。
 *  坦率的讲，这是一个非常有效的方案，优化后，红包系统非常稳定。
 *  回到教研的场景，见下图，我们也可以设计类似线程池模型的方案：
 *  ![在这里插入图片描述][a623c603f9fa487c8457d7a9af83289d.png]
 *  使用线程池模式，需要注意如下几点：
    
    1.  线程数不宜过高，避免占用过多的数据库连接池 ;
    2.  需要考虑评估线程池队列的大小，以免出现内存溢出的问题。

### 本地内存 + 定时任务 ###

*  开源中国统计浏览数的方案非常经典。
 *  用户访问过一次文章、新闻、代码详情页面，访问次数字段加 1 , 在 oschina 上这个操作是异步的，访问的时候只是将数据在内存中保存，每隔固定时间将这些数据写入数据库。
 *  ![在这里插入图片描述][856843551c764bdda5845bac894979f4.png]
 *  示例代码如下：
 *  ![在这里插入图片描述][2c974b2b257b435b9e6904202dc98b84.png]
 *  我们可以借鉴开源中国的方案 ：
    
    1.  控制器接收请求后，观看进度信息存储到本地内存 LinkedBlockingQueue 对象里；
    2.  异步线程每隔1分钟从队列里获取数据 ，组装成 List 对象，最后调用 Jdbc batchUpdate 方法批量写入数据库；
    3.  批量写入主要是为了提升系统的整体吞吐量，每次批量写入的 List 大小也不宜过大 。
 *  这种方案优点是：不改动原有业务架构，简单易用，性能也高。该方案同样需要考虑内存溢出的风险。

### MQ 模式 ###

*  很多同学们会想到 MQ 模式 ，消息队列最核心的功能是**异步**和**解耦**，MQ 模式架构清晰，易于扩展。
 *  ![在这里插入图片描述][c9c4be709e5342bf8f48b183e6dd68d6.png]
 *  核心流程如下：
    
    1.  控制器接收写请求，将观看视频行为记录转换成消息 ；
    2.  教研服务发送消息到 MQ ，将写操作成功信息返回给前端 ；
    3.  消费者服务从 MQ 中获取消息 ，批量操作数据库 。
 *  这种方案优点是：
    
    1.  MQ 本身支持高可用和异步，发送消息效率高 , 也支持批量消费;
    2.  消息在 MQ 服务端会持久化，可靠性要比保存在本地内存高；
 *  不过 MQ 模式需要引入新的组件，增加额外的复杂度。

### Agent 服务 + MQ 模式 ###

*  互联网大厂还有一种常见的**异步**的方案：Agent 服务 + MQ 模式。
 *  ![在这里插入图片描述][5d52fac1d82641288369d13621dbef4b.png]
 *  教研服务器上部署 Agent 服务（独立的进程） , 教研服务接收写请求后，将请求按照固定的格式（比如 JSON ）写入到本次磁盘中，然后给前端返回成功信息。
 *  Agent 服务会监听文件变动，将文件内容发送到消息队列 , 消费者服务获取观看行为记录，将其存储到 MySQL 数据库中。
 *  还有一种演进，假设我们不想在应用中依赖消息队列，不生成本地文件，可以采用如下的方式：
 *  ![在这里插入图片描述][ff020e7f86354e6d8077e8b961a9b419.png]
 *  这种方案最大的优点是：架构分层清晰，业务服务不需要引入 MQ 组件。
 *  笔者原来接触过的性能监控平台，或者日志分析平台都使用这种模式。

[550fa9be560b45e7a039b96ca13ae253.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/0a8dd2ed3d1f482a829f0e0592052556.png
[a623c603f9fa487c8457d7a9af83289d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/1116e7bbd18c485cab0c74911cb4acfa.png
[856843551c764bdda5845bac894979f4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/980a9936ff21418e9b458428ae04821b.png
[2c974b2b257b435b9e6904202dc98b84.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/56ed16611a904852a518ed14ad1f1292.png
[c9c4be709e5342bf8f48b183e6dd68d6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/b8e7c65cd27a4c9ca4b82cdcedb31498.png
[5d52fac1d82641288369d13621dbef4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/f1935be49e8a44138526c4d8e9d95cb1.png
[ff020e7f86354e6d8077e8b961a9b419.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/9c0af3efdd164481bb313581126754c9.png