背景

这是个在做NFT电商项目时遇到的场景，要求运营可以商家某个系列的NFT商品，可以设置该系列商品个数和开售时间，当未到达开售时间时显示未开售，一旦到达开售时间时显示售卖中，当抢购完显示售崩。只有售卖中才可以进行抢购。

业务流程

在这里插入图片描述

客户端抢购流程中会涉及到商品数据的读取用于商品展示，运营活动数据的读取用于显示价格变化、活动策略校验，以及库存数据的读取用于校验库存是否还有剩余。

业务难点

技术难点

短时间区间内的突发大流量，但是实际需要处理的请求却是有限
库存只有一份，所有人会在集中的时间读和写这些数据。

技术方案

技术方向

尽量将请求拦截在系统上游

传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，最终导致服务体验差，甚至服务瘫痪无法使用。

充分利用使用缓存

这是一个读多写少的场景，非常适合使用缓存来处理读请求。

具体落地

客户端流控

客户端(web、安卓、IOS)请求拦截，当服务端响应慢导致客户端一直处于请求中时，用户习惯性重复点击按钮来获取请求，这样会平白无故的增加了后端系统负载，80%的请求是这么多出来的。

对于这种重复请求，在产品层面可以要求用户点击按钮后，按钮置灰，禁止用户重复提交请求；代码层面，限制用户在x秒之内只能提交一次请求。如此限流，大部分真实用户流量已拦。

网关流控

由于客户端安装包一旦被破解或者被抓包，那么对于客户端与服务端的交互流程就被暴露了，那么此时就可以通过一些手段去对服务端发出大量的请求。所以在客户端之后的网关层做流控就必不可少。网关限流的配置方法有很多种，现在的主流网关一般都支持配置访问限制，可以通过配置实现简单的流控(如nginx的连接数限流和漏桶算法实现的限流)。

容器流控

上述的流控做法只能限制用户异常访问，如果正常访问的用户数量很多，就有后端系统压力过大甚至异常宕机的可能，因此需要后端系统进行流控。网关过后就来到了容器层(tomcat、jetty)，每个实例所能承受的QPS只有容器自己经过压测才知道。常见的如tomcat可以通过配置参数来进行流控。


## tomcat参数
# 队列大小
server.tomcat.accept-count=100
# 最大连接数
server.tomcat.max-connections=1000
# 最大活跃线程数
server.tomcat.threads.max=10
# 最小活跃线程数
server.tomcat.threads.min-spare=10

后端接口流控

容器的限流都针对的是整个实例。如果要实现更为精细的访问限制（具体到某个接口），可以在后端服务器上对不同业务实现访问限制。常见做法是可以通过在内存(针对每个实例接口的QPS)或缓存服务中(针对的是实例集群总的QPS)加入请求访问信息，来实现访问量限制。

由于不同接口依赖的第三方服务数量、第三方服务响应情况、数据库等情况不同，所以不同接口的流控限制也不同。

数据库流控

进过上面几步的流控，到达数据库的请求基本都是有效的请求了，但是对于这种抢购来说可能由于营销得好，此时还是涌入了大量的真实流量，但是真正数据库需要接收的流量又是有限的。这时候可以把请求数据库的操作放入队列内，数据层去获取队列进行消费，这样就控制了数据库的访问QPS，当库存被抢购一空时就可以将剩余的流量直接打回不请求数据库。

流控总结

这样经过了层层流控，从上到下流量呈现一个漏斗形态，越往下的服务接收到的流量越少，而最下层的数据层又是最重要的服务在这里得到很好的保护。

优化

流控主要解决了突发流量的问题，但是针对读多写少的问题我们还可以进行优化，让服务响应更加快，提升用户体验。因为再好的营销手段都需要技术的支持才能发挥出有效的收益。

读取加速

在抢购活动中，数据的操作一般都是读多写少。几百万的人最终能获取到商品的也就是那么有限个人，最后提交的订单最多也就商品个数的数量，但是在抢购过程中，这几百万人会一直产生大量的读取请求，并且读取的还是一些基本不变的信息。因此可以使用缓存服务对用户请求进行缓存优化，把一些高频、几乎不变的内容放到缓存中去。对于更大规模的系统，可以通过静态文件分离、CDN服务等把用户请求分散到外围设施中去，以此来分担系统压力。

异步化流程处理

对于接口内部流程通过消息队列、异步调用、流程拆分的方式可以实现异步处理，快速响应用户请求，让后端有较为充足的时间来处理一些非接口马上需要处理的流程(如支付成功后的发货流程，下单成功后的支付流程)，提高对用户请求的响应速度，从而提升用户体验。通过消息队列还可以隔离前端的压力，实现排队系统，在涌入大量压力的情况下保证系统可以按照正常速率来处理请求，不会被流量压垮。

系统扩容

对一次成功的抢购活动来说，无论如何限流，如何优化系统，最终产生的流量与正常流量对比都是超出N倍的。因此临时性的系统扩容必不可少，系统扩容包括以下3个方面。

增加系统规格：可以预先增加系统容量，比如提高系统带宽、购买更多流量等。
服务扩展：无状态服务+负载均衡可以直接进行水平扩展，有状态的服务则需要进行较为复杂的垂直扩展，增大实例规格。
后端系统扩容：缓存服务和数据库服务都可以进行容量扩展。

压测

再好的理论都需要实践的认证，对于这种关注度特别该的需求，更需要做上线前的压测来验证整个架构是否能承受期望的流量。需要有详细的压测方案文档的输出来帮助压测人员了解压测的流程以及需要压测的接口、流程，通过哪些报表来验证压测的结果，一旦出现性能问题需要APM平台体能哪些能力来帮助定位出出现性能的点在哪。对于压测这里不详细展开介绍。