波斯马BOSSMA Information Technology

限流的非常规用途 – 缓解抢购压力

发布时间:2021年12月3日 / 分类:Architecture, DOTNET / 685 次浏览 / 评论

这两年因为疫情,节假日都不怎么外出了,以前每逢节假日都要提前一个月或者半个月抢火车票,人太多的时候会把12306整崩溃。当时很多技术人员指点江山,激扬想法,粪土当年铁科院。

前几年小米手机还很火爆,特别抢手,每每新机发布,人山人海、万人空巷,却往往都在米兔排队的身影后收获失望的表情。

俱往矣!数风流套路,还看今朝!

几句笑谈,引出抢购这回事儿,下边开始正文。


怎么理解抢购?

抢购,大部分人应该都经历过,没抢过火车票,还没抢过口罩吗?没抢过食盐,还没抢过米面粮油吗?没抢过618,难道没抢过双11?总有一款抢购适合你。

“购”大家都能够理解,就是花钱买东西。“抢”就很有意思了,首先是因为商品数量有限(这里不讲套路了),然后需要的人特别多,所以怎么分配就成了一个问题,也就是人们常说的僧多粥少。

不知道大家是否见过这样的场景,一群人围在商店门口,大门还没完全打开,就咆哮着挤了进去,抢着拿货架上的商品,谁跑得快挤得凶,谁就能拿到,谁拿到谁就可以去付款带走,这就是抢的最真实写照了。如果你不曾体验过,那么挤公交也可以代替,要么挤上去,刷卡走人,要么被挤下来,等待下一辆车。虽然体验不好,但也确实解决了分配问题。

这里的所谓“抢”就是看谁先获得了有利位置,谁先锁定了商品。那么锁定了商品就一定会购买吗?也不见得,说不定你突然发现囊中羞涩,大家应该听过很多弃购的新闻。所以对于抢购来说,抢的是“购”的机会,谁先到了谁就有 “购” 的机会。至于会不会真的买回家,还真不好下定论。

抢购程序的问题

理解了抢购,再来看看程序怎么实现它?

根据前面的理解,我们可以将抢购分为两个阶段,“抢”映射为下单,“购”映射为支付订单。下单的操作就是锁定商品,又可以分为锁定库存、创建订单两个阶段,锁定库存就相当于你在商店中把商品拿到了手里,创建订单就相当于你和商家关于商品的价格达成协议。

操作库存有一个很有名的“超售”问题,说的是扣减库存时出错了,库存数量扣成了负数,那么这个问题是如何发生的呢?

后端服务处理请求时一般都是多线程的,为了高可用,还可能是分布式的,这个问题就是多线程和分布式环境带来的并行处理造成的。扣减库存时,一般有两个步骤,先检查库存是否足够,然后再从库存中减去相应的数量。这两个步骤如果不是原子的,那么在多线程或分布式环境下,就会存在多个线程同时查询库存,单从每个请求处理的上下文看库存是足够,但是库存总量不能满足所有这些扣减加在一起,结果就扣成了负数。

那怎么解决呢?方法很多,比如把查询和更新放到同一个数据库事务中就可以了,或者使用一个锁(分布式部署时为分布式锁)来锁定对某件商品库存的查询+扣减同时只能有一个在处理。

这样是不是就没有问题了呢?还是有的。需要注意这里说的是抢购,意味着会有很多的人来尝试,在现实生活中,如果人特别多,商店中承载不了这么多人,很可能会出现安全事故。在计算机程序中也可能会出现耗尽资源导致崩溃的问题,特别是数据库,IO请求突然爆发,很可能就会被压垮,上文提到的数据库事务无疑会加重这一负担。而锁也会导致吞吐量的下降,请求堆积无法得到及时处理,一样会加重服务器负担,出现频繁超时甚至无法服务的问题。

还有什么办法呢?以前写程序的时候有一个观点,大概是不用太关注代码运行效率,增加硬件就好了,比如增加内存、升级CPU、换固态硬盘等等。不过在抢购这里不太可行,还是因为并发量可能太大了,不得不考虑计算资源的成本,而动态资源调配的速度也是个问题。

现实生活中我们还有一个文明的处理方式:排队,先到先得,售完为止。程序先把请求接下来,保存到队列中,然后再按照先后顺序一个个处理,处理完一个回复一个,这就是队列的处理方式。这样做的优点是不用再去协调那些跨线程跨进程的资源访问冲突,计算资源需求也会大幅降低;缺点是用户要多等一会才能看到结果,体验略差,不过本来就是很紧俏的东西。

限流之于抢购

上边已经分析了抢购可能会遇到的问题,那么限流能干什么呢?

在软件系统中库存就是一个数字,限流呢也有一个数字,我们可以把限流的阈值作为库存的数量,请求过来的时候,先用限流处理,能够通过的就进入下一步,如果被限流了,则说明库存已经耗尽了,返回错误就行了。示意图如下:

这样做的好处是什么呢?减轻后续其它处理的压力。如果库存已经耗尽,也再无必要去查询数据库,白白浪费宝贵的数据库资源,甚至分布式锁、显式的数据库事务都不需要了,因为能够通过限流检查的就是可以扣减库存的,直接使用Update就可以了;不过此时扣减库存和下订单时的压力仍旧存在,比如3W个请求同时进来,限流可以拦截其中的27000,剩下的3000会进入下一环节,影响还是需要仔细考虑的。再看使用队列的方式,加了限流,队列中也只接收能够下单的请求,队列压力小,后续处理队列时的数据库操作同样也减少很多。

这里可能还会出现一些问题,比如限流检查通过了,但是后续的处理因为某种原因失败了,库存不能回收,实际上就浪费了一次机会,不过这不是抢购的主要矛盾,一般会忽略这个问题。

当然对于限购来说还有很多其它问题,限流就很难发挥作用了,比如前端高并发查询库存数,这里就不多讲了。

技术实现

这里以ASP.NET Core Web API为例,限流组件选择 FireflySoft.RateLimit ,算法选择简单的固定窗口也就是计数器方式,进程内计数。这里没有选择Redis,是因为进程内计数比较简单,不需要外部依赖,演示方便;即使在分布式环境下,一般也可以应对,比如总的限流阈值是 1000/小时,部署了5份服务实例,只需要在程序中使用 200/小时 的阈值就可以了;但是如果负载均衡不均匀,某些情况下可能不太合适,此时可以选择Redis全局一致限流。

安装 Nuget 包

使用包管理器控制台:

Install-Package FireflySoft.RateLimit.AspNetCore

或者使用 .NET CLI:

dotnet add package FireflySoft.RateLimit.AspNetCore

或者直接添加到项目文件中:

<ItemGroup>
<PackageReference Include="FireflySoft.RateLimit.AspNetCore" Version="2.*" />
</ItemGroup>

编写限流规则

在Startup.cs中注册限流服务并使用限流中间件。里边添加了一些注释,你可以仔细看看。

public void ConfigureServices(IServiceCollection services)
{
    ...
​
    services.AddRateLimit(new InProcessFixedWindowAlgorithm(
        new[] {
            new FixedWindowRule()
            {
                Id = "1",
                ExtractTarget = context =>
                {
                    // 限流的目标:商品Id,这里假设它是从Url参数中传递过来的
                    // 实际使用可能还需要很多的安全检查,这里为了演示简单处理
                    return  (context as HttpContext).Request.Query["GoodsId"].ToString();;
                },
                CheckRuleMatching = context =>
                {
                    // 在这里判断当前请求是否 “抢购下单”,抢购下单才进行限流处理
                    // 实际使用可能还需要很多的检查,这里为了演示简单处理
                    var path = (context as HttpContext).Request.Path.Value;
                    if(path == "/Order/PanicBuying"){
                        return true;
                    }
                    return false;
                },
                Name = "缓解抢购压力限流",
                LimitNumber = 1000, // 限流阈值,等于库存数量
                StatWindow = TimeSpan.FromSeconds(3600), //限流的时间窗口,这里是3600秒
                StartTimeType = StartTimeType.FromNaturalPeriodBeign
            }
        }),
        new HttpErrorResponse()
        {
            BuildHttpContent = (context, ruleCheckResult) =>
            {
                return "同学!你来晚了,已经售罄!";
            }
        },
    );
​
    ...
}
​
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    ...
​
    app.UseRateLimit();
​
    ...
}

只需要上边这些简单的代码就可以跑起来了,你可以用Postman测试一下。

如果你不想在Web程序中使用,或者需要更多自定义的设置,也可以直接安装 FireflySoft.RateLimit.Core 这个包,它可以用于各种.NET程序。点击查看示例: bosima/FireflySoft.RateLimit(github.com)

如果你想要使用Redis,只需将 InProcessFixedWindowAlgorithm 换成 RedisFixedWindowAlgorithm ,除了多传递一个Redis连接对象,其它的代码都是一样的。


好了,这就是本文的主要内容了。对于使用限流缓解抢购压力,你有什么想说的呢?

FireflySoft.RateLimit 是一个开源的.NET Standard限流类库,其使用灵活轻巧,可以在 GitHub 上访问到最新的代码。其主要特点包括:

  • 多种限流算法:内置固定窗口、滑动窗口、漏桶、令牌桶四种算法,还可自定义扩展。
  • 多种计数存储:目前支持内存、Redis两种存储方式。
  • 分布式友好:通过Redis存储支持分布式程序统一计数。
  • 限流目标灵活:可以从请求中提取各种数据用于设置限流目标。
  • 支持限流惩罚:可以在客户端触发限流后锁定一段时间不允许其访问。
  • 动态更改规则:支持程序运行时动态更改限流规则。
  • 自定义错误:可以自定义触发限流后的错误码和错误消息。
  • 普适性:原则上可以满足任何需要限流的场景。

本博客所有文章如无特别注明均为原创。
复制或转载请以超链接形式注明转自波斯马,原文地址《限流的非常规用途 – 缓解抢购压力

关键字:

建议订阅本站,及时阅读最新文章!
【上一篇】 【下一篇】

发表评论