什么，秒杀系统也有这么多种！

前言

本文结构很简单：

5张图送你5种秒杀系统，再加点骚操做，再顺带些点内心话🤷‍♀️。

一个简单的秒杀系统

实现原理： 经过redis原子操做减库存

图一

优势	缺点
简单好用	考验redis服务能力

是否公平
公平
先到先得

咱们称这类秒杀系统为：

简单秒杀系统

若是刚开始QPS并不高，redis彻底抗的下来的状况，彻底能够依赖这个「简单秒杀系统」。

一个够用的秒杀系统

实现原理： 服务内存限流算法 + redis原子操做减库存

图二

优势	缺点
简单好用	-

是否公平
不是很公平
相对的先到先得

咱们称这类秒杀系统为：

够用秒杀系统

性能再好点的秒杀系统

实现原理： 服务本地内存原子操做减库存

服务本地内存的库存怎么来的？

活动开始前分配好每台机器的库存，推送到机器上。

图三

优势	缺点
高性能	不支持动态伸缩容(活动进行期间)，由于库存是活动开始前分配好的
释放redis压力	-

是否公平
不是很公平
不是绝对的先到先得

咱们称这类秒杀系统为：

预备库存秒杀系统

支持动态伸缩容的秒杀系统

实现原理： 服务本地协程Coroutine定时redis原子操做减部分库存到本地内存 + 服务本地内存原子操做减库存

图四

优势	缺点
高性能	支持动态伸缩容(活动进行期间)
释放redis压力	-
具有通用性	-

是否公平
不是很公平，可是好了点
几乎先到先得

咱们称这类秒杀系统为：

实时预备库存秒杀系统

公平的秒杀系统

实现原理： 服务本地Goroutine定时同步是否售罄到本地内存 + 队列 + 排队成功轮训(或主动Push)结果

图五

优势	缺点
高性能	开发成本高(需主动通知或轮训排队结果)
真公平	-
具有通用性	-

是否公平
很公平
绝对的先到先得

咱们称这类秒杀系统为：

公平排队秒杀系统

骚操做

上面的秒杀系统还不够完美吗？

答案：是的。

还有什么优化的空间？

答案：静态化获取秒杀活动信息的接口。

静态化是什么意思?

答案：好比获取秒杀活动信息是经过接口 https://seckill.skrshop.tech/v1/acticity/get 获取的。如今呢，咱们须要经过https://static-api.skrshop.tech/seckill/v1/acticity/get 这个接口获取。有什么区别呢？看下面：

服务名	接口	数据存储位置
秒杀服务	https://seckill.skrshop.tech/...	秒杀服务内存或redis等
接口静态化服务	https://static-api.skrshop.te...	CDN、本地文件

之前是这样

变成了这样

结果：能够经过接口https://static-api.skrshop.tech/seckill/v1/acticity/get就获取到了秒杀活动信息，流量都分摊到了cdn，秒杀服务自身没了这部分的负载。

小声点说：“秒杀结果我也敢推CDN😏😏😏。”

备注：
以后咱们会分享`如何用Golang设计一个好用的「接口静态化服务」`。

总结

上面咱们获得了以下几类秒杀系统

秒杀系统
简单秒杀系统
够用秒杀系统
预备库存秒杀系统
实时预备库存秒杀系统
公平排队秒杀系统

我想说的是里面没有最好的方案，也没有最坏的方案，只有适合你的。

拿先到先得来讲，必定要看大家的产品对外宣传，切勿上来就追逐绝对的先到先得。其实你看全部的方案，相对而言都是“先到先得”，好比，活动开始一个小时了你再来抢，那相对于准时的用户天然抢不过，对吧。

又如预备库存秒杀系统，虽然不支持动态伸缩容。可是若是你的环境知足以下任意条件，就彻底够用了。

• 秒杀场景结束时间之快，一般几秒就结束了，真实活动可能会发生以下状况：

  • 服务压力大还没挂：根本就来不及动态伸缩容
  • 服务压力大已经挂了：能够先暂停活动，服务起来&扩容结束，用剩余库存从新推送
• 运维自身不具有动态伸缩容的能力

因此:

合适好用就行，切勿过分设计。

最后

此次算是把老本都吐露出来了，真是慌得一匹。

---

SkrShop历史分享：https://github.com/skr-shop/m...