go-zero微服务实战系列（八、如何处理每秒上万次的下单请求）

随着业务的发展，我们就会遇到一些高并发写请求的场景，秒杀抢购就是最典型的高并发写场景。在秒杀抢购开始后用户就会疯狂的刷新页面让自己尽早的看到商品，所以秒杀场景同时也是高并发读场景。那么应对高并发读写场景我们怎么进行优化呢？

处理热点数据

秒杀的数据通常都是热点数据，处理热点数据一般有几种思路：一是优化，二是限制，三是隔离。

优化

优化热点数据最有效的办法就是缓存热点数据，我们可以把热点数据缓存到内存缓存中。

限制

限制更多的是一种保护机制，当秒杀开始后用户就会不断地刷新页面获取数据，这时候我们可以限制单用户的请求次数，比如一秒钟只能请求一次，超过限制直接返回错误，返回的错误尽量对用户友好，比如 "店小二正在忙" 等友好提示。

隔离

秒杀系统设计的第一个原则就是将这种热点数据隔离出来，不要让1%的请求影响到另外的99%，隔离出来后也更方便对这1%的请求做针对性的优化。具体到实现上，我们需要做服务隔离，即秒杀功能独立为一个服务，通知要做数据隔离，秒杀所调用的大部分是热点数据，我们需要使用单独的Redis集群和单独的Mysql，目的也是不想让1%的数据有机会影响99%的数据。

流量削峰

针对秒杀场景，它的特点是在秒杀开始那一刹那瞬间涌入大量的请求，这就会导致一个特别高的流量峰值。但最终能够抢到商品的人数是固定的，也就是不管是100人还是10000000人发起请求的结果都是一样的，并发度越高，无效的请求也就越多。但是从业务角度来说，秒杀活动是希望有更多的人来参与的，也就是秒杀开始的时候希望有更多的人来刷新页面，但是真正开始下单时，请求并不是越多越好。因此我们可以设计一些规则，让并发请求更多的延缓，甚至可以过滤掉一些无效的请求。

削峰本质上是要更多的延缓用户请求的发出，以便减少和过滤掉一些无效的请求，它遵从请求数要尽量少的原则。我们最容易想到的解决方案是用消息队列来缓冲瞬时的流量，把同步的直接调用转换成异步的间接推送，中间通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑的将消息推送出去，如下图所示：

采用消息队列异步处理后，那么秒杀的结果是不太好同步返回的，所以我们的思路是当用户发起秒杀请求后，同步返回响应用户 "秒杀结果正在计算中..." 的提示信息，当计算完之后我们如何返回结果给用户呢？其实也是有多种方案的。

• 一是在页面中采用轮询的方式定时主动去服务端查询结果，例如每秒请求一次服务端看看有没有处理结果，这种方式的缺点是服务端的请求数会增加不少。
• 二是主动push的方式࿰