设计一个秒杀系统
主要做到以下两点:
针对于浏览器端，可以使用 JS 进行请求过滤，比如五秒钟之类只能点一次抢购按钮，五秒钟只能允许请求一次后端服务。(APP 同理)
这样其实就可以过滤掉大部分普通用户。
但是防不住直接抓包循环调用。这种情况可以最简单的处理:在
- 尽量将请求过滤在上游。
- 尽可能的利用缓存(大多数场景下都是查多于写)。
针对于浏览器端，可以使用 JS 进行请求过滤，比如五秒钟之类只能点一次抢购按钮，五秒钟只能允许请求一次后端服务。(APP 同理)
这样其实就可以过滤掉大部分普通用户。
但是防不住直接抓包循环调用。这种情况可以最简单的处理:在Web层通过限制一个 UID 五秒之类的请求服务层的次数(可利用 Redis 实现)。
但如果是真的有 10W 个不同的 UID 来请求，比如黑客抓肉鸡的方式。
这种情况可以在服务层 针对于写请求使用请求队列，再通过限流算法(限流算法)每秒钟放一部分请求到队列。
对于读请求则尽量使用缓存，可以提前将数据准备好，不管是 Redis 还是其他缓存中间件效率都是非常高的。
ps : 刷新缓存情况，比如库存扣除成功这种情况不用马上刷新缓存，如果库存扣到了 0 再刷新缓存。因为大多数用户都只关心是否有货，并不关心现在还剩余多少。
总结
- 如果流量巨大，导致各个层的压力都很大可以适当的加机器横向扩容。如果加不了机器那就只有放弃流量直接返回失败。快速失败非常重要，至少可以保证系统的可用性。
- 业务分批执行：对于下单、付款等操作可以异步执行提高吞吐率。
- 主要目的就是尽量少的请求直接访问到
DB。
正文到此结束
- 本文标签：
- 版权声明： 本文由HARRIES原创发布，转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
