海量请求下的接口并发解决方案
设定一个场景,假如一个商品接口在某段时间突然上升,会怎么办?
生活中的例子来说,假设冰墩墩在当天晚上上热搜之后,迅速有十几万人去淘宝下单购买,此时并没有做好对该商品的缓存预热以及准备,如何操作?
对于这个问题,在电商高并发系统中,对接口的保护一般采用:缓存、限流、降级 来操作。
假设该接口已经接受过风控的处理,过滤掉一半的机器人脚本请求,剩下都是人为的下单请求。
服务限流
限流 主要的目的是通过对并发访问/请求进行限速,或者对一个时间窗口内的请求进行限速,一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理。
限流算法
漏斗算法 漏桶算法
是当请求到达时直接放入漏桶,如果当前容量已达到上限(限流值),则进行丢弃或其他策略(触发限流策略)。漏桶以固定的速率(根据服务吞吐量)进行释放访问请求(即请求通过),直到漏桶为空。
漏斗算法的思想就是,不管你来多少请求,我的接口消费速度一定是小于等于流出速率的阈值的。
可以基于消息队列来实现
令牌桶算法 令牌桶算法
是程序以 v(v = 时间周期 / 限流值)的速度向令牌桶中增加令牌,直到令牌桶满,请求到达时向令牌桶请求令牌,如果获取成功则通过请求,如果获取失败触发限流策略。
令牌桶算法和漏斗算法的思想差别在于,前者可以允许突发请求的发生。
滑窗算法 滑窗算法
是将一个时间周期分为 N 个小周期,分别记录每个小周期内访问次数,并且根据时间滑动删除过期的小周期。
如下图所示,假设时间周期为 1 分钟,将 1 分钟再分为 2 个小周期,统计每个小周期的访问数量,则可以看到,第一个时间周期内,访问数量为 75,第二个时间周期内,访问数量为 100,如果一个时间周期内所有的小周期总和超过 100 的话,则会触发限流策略。
Sentinel 的实现 和 TCP 滑窗。
接入层限流
Nginx 限流
Nginx 限流采用的是漏桶算法。
它可以根据客户端特征,限制其访问频率,客户端特征主要指 IP、UserAgent 等。使用 IP 比 UserAgent 更可靠,因为 IP 无法造假,UserAgent 可随意伪造。
limit_req 模块基于 IP:Module ngx_http_limit_req_module (nginx.org)
tgngine:ngx_http_limit_req_module - The Tengine Web Server (taobao.org)
本地接口限流
SemaphoreJava 并发库 的 Semaphore 可以很轻松完成信号量控制,Semaphore 可以控制某个资源可被同时访问的个数,通过 acquire() 获取一个许可,如果没有就等待,而 release() 释放一个许可。
假如我们对外提供一个服务接口,允许最大并发数为 40,我们可以这样:
具体的 Semaphore 实现参考源码。
分布式接口限流
使用消息队列
不管是用 MQ 中间件,或是 Redis 的 List 实现的消息队列,都可以作为一个 缓冲队列 来使用。思想就是基于漏斗算法。
当对于一个接口请求达到一定阈值时,就可以启用消息队列来进行接口数据的缓冲,并根据服务的吞吐量来消费数据。
服务降级
在接口做好风控的前提下,发现了接口请求的并发量迅速上升,我们可以启用兜底方案,进行服务降级。
一般服务降级应该用来对一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。
降级方案
停止边缘业务
比如淘宝双 11 前,就不可以查询三个月前的订单,对边缘业务进行降级,保证核心业务的高可用。
拒绝请求
在接口请求并发量大于阈值,或是接口出现大量失败请求等等突发情况,可以拒绝一些访问请求。
拒绝策略
随机拒绝:随机拒绝超过阈值的请求 。拒绝旧请求:按照请求的时间,优先拒绝更早收到的请求。拒绝非核心请求:根据系统业务设置核心请求清单,将非核心清单内的请求拒绝掉。
恢复方案
在实现服务降级之后,对于突增流量我们可以继续注册多个消费者服务来应对并发量,之后我们再对一些服务器进行慢加载。
降级具体实现参考其他文章。
数据缓存
在接口做好风控的前提下,发现了接口请求的并发量迅速上升,我们可以分以下几个操作执行:
对访问请求使用分布式锁进行阻塞。
在这个短时间中,我们可以将对应操作行的热点数据,缓存在缓存中间件中。
放行请求后,让所有请求优先操作缓存数据。
再将操作的结果通过消息队列发送给消费接口慢慢消费。
缓存问题
假设我们操作的是一个库存接口,此时数据库中只有 100 个库存。
那假如此时我们将一条数据放入缓存中,如果所有的请求都来访问这个缓存,那它还是被打挂,我们该怎么操作?
读写分离
第一种想法,读写分离。
使用 Redis 的哨兵集群模式来进行主从复制的读写分离操作。读的操作肯定大于写操作,等库存被消费到 0 时,读操作直接快速失败。
负载均衡
第二种想法,负载均衡。
在缓存数据后,如果所有请求都来缓存中操作这个库存,不管是加悲观锁还是乐观锁,并发率都很低,此时我们可以对这个库存进行拆分。
我们可以参照 ConcurrentHashMap 中的 counterCells 变量的设计思想,将 100 个库存拆分到 10 个缓存服务中,每个缓存服务有 10 个缓存,然后我们再对请求进行负载均衡到各个缓存服务上。
但是这种方式会有问题,如果大部分用户被 hash 到同一个缓存上,导致其他缓存没有被消费,却返回没有库存,这是不合理的。
page cache
第三种想法,page cache。
大部分软件架构其实都用到了这种方法,比如 linux 内核的硬盘写入、mysql 的刷盘等等,即将短时间内的写操作聚合结果写入,所有的写操作在缓存内完成。
原文:https://mp.weixin.qq.com/s/Yzj8tfjwpSBreYSfYfFy1w
如果感觉本文对你有帮助,点赞关注支持一下,想要了解更多 Java 后端,大数据,算法领域最新资讯可以关注我公众号【架构师老毕】私信 666 还可获取更多 Java 后端,大数据,算法 PDF+大厂最新面试题整理+视频精讲
评论