MQ 学习笔记

1. 使用场景

• 异步
• 解耦
• 削峰

异步

提高系统的响应速度、吞吐量。

场景一 异步处理播放记录

空中课堂有很多点播模块，如：名师讲堂、抗议助学、互动课堂、同步课堂、家长课堂、苏e优课等。

通常这些模块需要：

• 记录观看的用户信息
• 自增对应模块表的观看量
• 维护旧数据表的观看量（逻辑未完全迁移）
• 维护大屏统计表的数据量
• ……

以上这一系列操作的业务可能有一定耗时（操作的数据库表较多），但对用户来说响应结果并不重要，使用 MQ 异步处理。

解耦

场景一 VOD 的任务流

VOD 用户上传的视频可能需要转码、截取封面图，这些操作不可能同步，通常会在视频上传之后开启一个任务流分步处理，并将结果回调给特定的地址。

扩展：通常 VOD 提供了两组通知模式，回调+主动拉取，回调并不可靠，可能会因为跨网络的原因导致消息丢失；通常选择可靠回调，定时主动拉取事件集，并在处理之后给出确认响应。

场景二 企微事件回调

在企微的人员架构变动之后，后台会接收到回调事件，接收事件的服务可能只是一个统计入口服务，比如自建代开发应用事件回调服务、第三方应用事件回调服务，并不希望将这些回调事件的处理逻辑混合到这些系统中，可以推送到 MQ 中供其他服务进行使用。

削峰

场景一 校园安全人脸捕捉削峰

门禁机设备推送抓拍信息（回调接口），如果返回错误码，或者网络原因超时（可配置），会一直重试。

一定程度确保了消息不丢失

这样可能会导致门禁机在网络不通的情况下一直调用，所以一般会取消离线发送。

离线发送：设备注册失败 or 心跳不正常，取消推送抓拍信息，直到恢复。

上述场景可能有个问题：学校整体网络都有问题，抓拍的图片堆积太多，如果等待网络恢复，瞬间发送大量的包含 base64 等信息的抓拍信息，会导致服务器压力较大！

引入 MQ，将 Capture 的信息先推送到消息队列，异步地匀速处理。

2. 如何保证消息幂等

RocketMQ 包含了一个 MessageID，但是消息多的情况下未必唯一。

自己带一个有业务标识的 MessageID

3. 消息有序

全局有序、局部有序：MQ 只需要保证局部有序