共计 2431 个字符，预计需要花费 7 分钟才能阅读完成。
起源：tuicool
https://www.tuicool.com/artic…
秒杀零碎波及到的知识点
- 高并发，cache，锁机制
- 基于缓存架构 redis,Memcached 的先进先出队列。
- 略微大一点的秒杀，必定是分布式的集群的，并发来自于多个节点的 JVM，synchronized 所有在 JVM 上加锁是不行了
- 数据库压力
- 秒杀超卖问题
- 如何避免用户来刷，黑名单？IP 限度？
- 利用 memcached 的带原子性个性的操作做并发管制
秒杀简略设计方案
比方有 10 件商品要秒杀，能够放到缓存中，读写时不要加锁。当并发量大的时候，可能有 25 集体秒杀胜利，这样前面的就能够间接抛秒杀完结的动态页面。进去的 25 集体中有 15 集体是不可能取得商品的。所以能够依据进入的先后顺序只能前 10 集体购买胜利。前面 15 集体就抛商品已秒杀完。
假如咱们的秒杀场景
比方某商品 10 件物品待秒. 假如有 100 台 web 服务器 (假如 web 服务器是 Nginx + Tomcat),n 台 app 服务器,n 个数据库
第一步 如果 Java 层做过滤, 能够在每台 web 服务器的业务解决模块里做个计数器 AtomicInteger(10)= 待秒商品总数,decreaseAndGet()>=0 的持续做后续解决, <0 的间接返回秒杀完结页面，这样通过第一步的解决只剩下 100 台 *10 个 =1000 个申请。
第二步, memcached 里以商品 id 作为 key 的 value 放个 10, 每个 web 服务器在接到每个申请的同时, 向 memcached 服务器发动申请, 利用 memcached 的 decr(key,1) 操作返回值 >= 0 的持续解决, 其余的返回秒杀失败页面，这样通过第二步的解决只剩下 100 台中最疾速达到的 10 个申请。
第三步, 向 App 服务器发动下单操作事务。
第四步, App 服务器向商品所在的数据库申请减库存操作 (操作数据库时能够 “update table set count=count-1 where id= 商品 id and count>0;” update 胜利记录数为 1, 再向订单数据库增加订单记录, 都胜利后提交整个事务, 否则的话提醒秒杀失败，用户进入领取流程。
看看淘宝的秒杀
一、前端
面对高并发的抢购流动，前端罕用的三板斧是【扩容】【动态化】【限流】
- 扩容：加机器，这是最简略的办法，通过减少前端池的整体承载量来抗峰值。
- 动态化：将流动页面上的所有能够动态的元素全副动态化，并尽量减少动静元素。通过 CDN 来抗峰值。
- 限流：个别都会采纳 IP 级别的限流，即针对某一个 IP，限度单位工夫内发动申请数量。或者流动入口的时候减少游戏或者问题环节进行消峰操作。
- 有损服务：最初一招，在靠近前端池承载能力的水位下限的时候，随机回绝局部申请来爱护流动整体的可用性。
二、那么后端的数据库在高并发和超卖下会遇到什么问题呢
- 首先 MySQL 本身对于高并发的解决性能就会呈现问题，一般来说，MySQL 的解决性能会随着并发 thread 回升而回升，然而到了肯定的并发度之后会呈现显著的拐点，之后一路降落，最终甚至会比单 thread 的性能还要差。
- 其次，超卖的根结在于减库存操作是一个事务操作，须要先 select，而后 insert，最初 update -1。最初这个 - 1 操作是不能呈现正数的，然而当多用户在有库存的状况下并发操作，呈现正数这是无奈防止的。
- 最初，当减库存和高并发碰到一起的时候，因为操作的库存数目在同一行，就会呈现争抢 InnoDB 行锁的问题，导致呈现相互期待甚至死锁，从而大大降低 MySQL 的解决性能，最终导致前端页面呈现超时异样。
针对上述问题，如何解决呢？淘宝的高大上解决方案：
I：敞开死锁检测，进步并发解决性能。
II：批改源代码，将排队提到进入引擎层前，升高引擎层面的并发度。
III：组提交，升高 server 和引擎的交互次数，升高 IO 耗费。
解决方案 1： 将存库从 MySQL 前移到 Redis 中，所有的写操作放到内存中，因为 Redis 中不存在锁故不会呈现相互期待，并且因为 Redis 的写性能和读性能都远高于 MySQL，这就解决了高并发下的性能问题。而后通过队列等异步伎俩，将变动的数据异步写入到 DB 中。
长处：解决性能问题
毛病：没有解决超卖问题，同时因为异步写入 DB，存在某一时刻 DB 和 Redis 中数据不统一的危险。
解决方案 2： 引入队列，而后将所有写 DB 操作在单队列中排队，齐全串行解决。当达到库存阀值的时候就不在生产队列，并敞开购买性能。这就解决了超卖问题。
长处：解决超卖问题，稍微晋升性能。
毛病：性能受限于队列处理机解决性能和 DB 的写入性能中最短的那个，另外多商品同时抢购的时候须要筹备多条队列。
解决方案 3： 将写操作前移到 MC 中，同时利用 MC 的轻量级的锁机制 CAS 来实现减库存操作。
长处：读写在内存中，操作性能快，引入轻量级锁之后能够保障同一时刻只有一个写入胜利，解决减库存问题。
毛病：没有实测，基于 CAS 的个性不晓得高并发下是否会呈现大量更新失败？不过加锁之后必定对并发性能会有影响。
解决方案 4： 将提交操作变成两段式，先申请后确认。而后利用 Redis 的原子自增操作，同时利用 Redis 的事务个性来发号，保障拿到小于等于库存阀值的号的人都能够胜利提交订单。而后数据异步更新到 DB 中。
长处：解决超卖问题，库存读写都在内存中，故同时解决性能问题。
毛病：因为异步写入 DB，可能存在数据不统一。另可能存在少买，也就是如果拿到号的人不真正下订单，可能库存减为 0，然而订单数并没有达到库存阀值。
总结
1、前端三板斧【扩容】【限流】【动态化】
2、后端两条路【内存】+【排队】
近期热文举荐：
1.600+ 道 Java 面试题及答案整顿 (2021 最新版)
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
