函数计算配合消息队列做削峰填谷，本质就是把突发流量先塞进队列缓冲，再让函数按固定并发慢慢消费，后端压力从尖峰拉成平缓曲线。
函数计算和消息队列怎么配合才能削峰填谷
函数计算是事件驱动的计算服务,消息队列则是分布式系统里最常见的缓冲层，两者配合时，消息队列负责“接住”瞬时请求，函数计算负责“消化”请求。
- 请求先写入消息队列,而不是直接打到后端服务。
- 消息队列作为事件源触发函数计算。
- 函数实例按并发配置拉取消息并处理。
- 处理成功后消息被确认,失败则进入重试或死信队列。
为什么这样就能削峰？因为函数实例数量不会瞬间无限扩大，它有并发上限，高峰流量超过并发上限时，多余消息安静地排在队列里，低谷时段，函数继续按固定速度消费积压，峰值被削掉，谷值被填充。
行业共识认为,削峰填谷的关键不是消灭流量峰值，而是拉长处理时间轴，队列提供了时间缓冲，函数计算提供了弹性消费能力。
队列选择
不是所有队列都适合函数计算削峰场景,常见选择分三类。
- 普通消息队列：适合大多数异步任务，不保证严格顺序。
- 顺序消息队列：适合订单状态流转这类要求同一业务键内有序的场景。
- Kafka类流式队列：适合日志清洗、数据管道类大批量场景，配合函数计算做流式处理。
云上用 RocketMQ、Kafka、RabbitMQ 都可以，关键看业务是否要求顺序，以及单条消息大小。
触发模式
函数计算从队列拉消息通常有两种模式。
- 事件触发器：队列有消息就自动触发函数实例，适合实时性要求较高的异步链路。
- 定时拉取：函数按固定时间间隔批量拉取队列，适合日志归档、日终对账等非实时任务。
多数削峰填谷场景选择事件触发器,因为流量来的时候马上就能触发消费，队列不会长时间积压。
高并发下如何用队列削峰填谷：电商秒杀场景拆解
以电商秒杀下单为例,用户点击下单的瞬间，可能有几万甚至几十万请求同时到来，如果直接同步调用订单服务，数据库连接池会瞬间打满，后端雪崩。
改成异步架构后,链路变成：
- 用户请求进入 API 网关。
- 网关把下单请求序列化成消息,写入订单消息队列。
- 订单处理函数以固定并发消费消息。
- 函数内部完成校验、扣库存、落库。
- 前端返回“排队中”，用户稍后查询结果。
这样做的好处是,无论前端瞬时并发多高，后端数据库看到的始终是函数并发数以内的处理速率，比如函数并发设置为 30，数据库每秒最多收到约 30 笔订单处理请求，队列积压时，可以调高函数并发或增加函数实例预留。
为什么同步扛不住
同步链路下,每个请求都要占用一个数据库连接，连接池一旦耗尽，后续请求全部失败，即使数据库本身还能扛，应用服务器的线程数也会先被压满。
异步链路怎么搭
搭建异步链路不需要改业务逻辑,只需要在订单服务前面加一层消息队列，前端提交订单接口从“同步下单”改为“投递下单消息”，订单处理函数订阅队列，按固定速率消费，数据库压力稳定后，再逐步调高函数并发，观察队列深度变化。
函数计算异步处理消息队列的实操配置
以简米云函数计算和消息队列 RocketMQ 为例，异步处理配置可以按下面步骤走。
创建消息队列实例和 Topic
登录云控制台,进入消息队列 RocketMQ 产品页，创建实例，选择地域和网络类型，实例创建完成后，创建一个 Topic，Topic 就是消息类别，order-topic，再创建一个 Group ID，函数消费时需要使用。
创建事件函数
在函数计算控制台新建函数,运行环境选 Python 或 Node.js，内存可以先给 512 MB，超时时间设成 10 秒，函数代码里写消息处理逻辑。
添加消息队列触发器
进入函数详情页,找到“触发器”标签，点击创建触发器，事件源选择“消息队列 RocketMQ”，填写实例 ID、Topic、Group ID，触发方式选择“异步触发”，批量推送条数可以设为 10 条，表示一个函数实例一次拉取最多 10 条消息。
重试策略这里要重点配置：
- 最大重试次数：建议 3 次。
- 重试间隔：建议 10 秒到 30 秒。
- 死信队列：开启后，重试次数耗尽的消息会被转到死信 Topic，避免阻塞正常消息。
编写消费逻辑
函数入口接收事件参数,遍历消息列表，逐条处理，处理成功返回 True，处理失败抛出异常，返回失败后，触发器会按重试策略再次投递。
控制台路径可以按这个顺序找：函数计算控制台 → 服务列表 → 函数名称 → 触发器 → 创建触发器，每个云厂商路径略有差异，但配置项基本一致。
函数计算价格贵不贵？和常驻服务器对比成本
“函数计算价格贵不贵”是很多团队在选型时最先问的问题，要分场景看，对于间歇性、突发性的异步任务，函数计算多数情况下比常驻服务器更划算。
- 常驻服务器：无论有没有流量，CPU 和内存都在计费。
- 函数计算：没有请求时不产生计算费用，只按实际调用次数和资源使用时长计费。
- 削峰填谷场景的特点是流量集中爆发、其余时间低位运行，天然适合按需付费。
下面用一张表对比两类方案的差异。
| 对比项 | 函数计算 | 常驻服务器 |
|---|---|---|
| 空闲时成本 | 几乎不计费 | 持续计费 |
| 突发流量处理 | 队列缓冲，实例动态拉起 | 需要提前扩容，容易浪费 |
| 运维投入 | 低，平台托管 | 高，需维护实例 |
| 冷启动 | 有，通常百毫秒到秒级 | 无 |
冷启动是函数计算的一个固有成本,如果业务对延迟极其敏感，可以用预留实例来降低冷启动，但会增加固定成本，异步削峰场景大多可以接受短延迟，因此函数计算的成本优势比较明显。
简米云函数计算配合队列落地要注意什么
在简米云或同类云平台上落地时,有五个配置点需要提前想清楚。
- 幂等设计：消息队列在重试或网络抖动时，同一条消息可能被投递多次，消费函数必须做幂等，比如用订单号做唯一键去重。
- 超时时间匹配：函数超时时间必须小于消息队列的消息不可见时间，否则上一次还没处理完，消息又被其他实例拉走，会重复消费。
- 死信队列配置：处理失败的消息如果一直重试，会拖垮整个消费链路，开启死信队列，让失败消息有归宿。
- 顺序消息：普通队列不保证严格顺序，如果业务要求订单状态按创建顺序处理，需要使用顺序消息，并且同一个消息组的消息只投递给同一个实例。
- 并发上限：函数计算默认并发有上限，大促前要提前申请提额，或者配置预留实例。
把这五个点配置到位,函数计算配合队列的削峰填谷才能真正稳定运行。
把函数计算和消息队列绑在一起，削峰填谷不是停留在架构图上的概念，而是几条触发器和消费代码就能落地的方案，真正需要提前想清楚的只有三件事：队列容量、函数并发、失败兜底。
函数计算配合队列削峰填谷常见问题
函数计算配合队列时消息会丢吗？
正常配置下不会丢,消息队列本身有持久化存储，函数计算处理失败会触发重试，重试次数耗尽后，如果配置了死信队列，消息会转到死信 Topic 保留，没有配置死信队列时，消息可能被丢弃，所以死信队列是必须项。
消息积压时函数计算会自动扩容吗？
会自动扩容,函数计算根据消息堆积情况增加并发实例，但扩容有上限，默认并发上限一般在较小的数量级，具体以云平台控制台显示为准，大流量场景需要提前申请提高并发上限，或者配置预留实例来补充。
函数计算异步处理消息队列适合哪些业务？
适合订单异步落库、日志清洗、图片压缩、消息推送等允许秒级延迟的业务，不适合要求毫秒级同步返回的强一致性场景，比如支付结果确认，这类业务需要同步调用或专用事务链路，队列异步处理只能作为辅助补偿机制。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/636110.html
