如何应对业务交互网关的洪峰挑战？

本文共计6825个文字，预计阅读时间需要28分钟。

前言：在日常生活中，相信大家都会遇到数据洪峰这样的场景。例如电商平台搞活动时，大量的请求集中涌入，短时间内对系统造成巨大压力，如不事先做好相应的防范措施，后果不堪设想。

前言

在日常工作中相信大家都会遇到数据洪峰这样的场景，例如电商平台搞活动时，大量的请求集中在一小段时间内，此时对系统造成的压力远超平常，如果不事先做好相应的防范措施，系统将极有可能崩溃、不可用。

业务背景

我们的应用系统每天都会产生大量的业务数据（可以简单理解为商品、订单等），有很多与我们合作的 外部平台 需要 订阅 这些数据，此时我们内部存在一个 数据推送平台 负责将我们系统内部数据推送至外部合作伙伴，数据链路如下：

内部业务系统投递 不同类型的业务数据 至 ​​MQ​​ ， 数据推送平台 通过消费 ​​MQ​​ 消息，进行一系列处理后采用 异步 的方式将数据推送至不同的合作伙伴 。

技术背景

方案选择

一般应对高并发场景常见的三板斧就是 ​​缓存​​ 、 ​​熔断（降级）​​ 、 ​​限流​​ ：

​​缓存​​ 常用于高 ​​QPS​​ 的业务场景，显然不太适用这种数据推送的情况。

​​熔断（降级）​​ 一般应用于调用下游服务失败，防止雪崩效应的场景。 数据推送平台 相对独立，不存在内部服务调用的情况；但是 外部的合作伙伴 确实存在服务可用性的问题，经常出现各种情况导致数据推送异常，因此是可以针对出现异常的外部合作伙伴采用 ​​熔断（降级）​​ 的处理。

​​限流​​ 就是当高并发或者瞬时高并发时，为了保证系统的稳定性、可用性，系统以牺牲部分请求为代价或者延迟处理请求为代价，保证系统整体服务可用，该种方案与我们的业务场景极为契合。