一、秒杀系统的基本构成
二、秒杀系统的常见问题
高并发
大量的请求进来，在Redis缓存层会发生缓存雪崩 缓存击穿 缓存穿透这些问题，这些问题就会打挂MySQL。这样就会导致活动失败用户体验差，本来为了赚人气的秒杀活动，导致人气下降，最后负责的还是开发人员。
超卖
假如还剩下1件商品，但是你接受了100个请求，那么最后数据库最后会显示-99件商品，意思就是说商品卖超了99件。你不发货用户投诉你，平台封你店，你发货就血亏，你怎么办？那最后只能杀个开发祭天解气了，秒杀的价格本来就低了，基本上都是不怎么赚钱的，超卖了就恐怖了呀，所以超卖也是很关键的一个点。
恶意请求
科普下，小道消息了解到的，黄牛的抢票系统，比国内很多小公司的系统还吊很多，架构设计都是顶级的，我用顶配的服务加上顶配的架构设计。那么所有的秒杀商品都会黄牛抢到了，转手高价卖出。
链接暴露
你卖这个东西实在便宜得过分，有诱惑力，你能保证开发不动心？开发知道地址，在秒杀的时候自己提前请求。。。（开发：怎么TM又是我）
打挂数据库
每秒上万甚至十几万的QPS（每秒请求数）直接打到数据库，基本上都要把库打挂掉，而且你服务不单单是做秒杀的还涉及其他的业务，你没做降级、限流、熔断啥的，别的一起挂，小公司的话可能全站崩溃404。
三、秒杀系统的解决技术
前端层面
资源静态化
静态化就是指把原本动态生成的html页面变为静态内容保存，用户客户端请求的时候，直接返回静态页面，不用再经过服务渲染，不用访问数据库，可以大大的减小数据库的压力，显著的提高性能。
URL动态化
我们上面说了链接要是提前暴露出去可能有人直接访问url就提前秒杀了，那又有小伙伴要说了我做个时间的校验就好了呀，那我告诉你，知道链接的地址比起页面人工点击的还是有很大优势。
我知道url了，那我通过程序不断获取最新的北京时间，可以达到毫秒级别的，我就在00毫秒的时候请求，我敢说绝对比你人工点的成功率大太多了，而且我可以一毫秒发送N次请求，搞不好你卖100个产品我全拿了。
那这种情况怎么避免？简单，把URL动态化，就连写代码的人都不知道，你就通过MD5之类的摘要算法加密随机的字符串去做url，然后通过前端代码获取url后台校验才能通过。
限流控制
限流可以分为前端限流和后端限流，这里先说说前端限流。
大家有没有发现没到秒杀前，一般按钮都是置灰的，只有时间到了，才能点击。这是因为怕大家在时间快到的最后几秒秒疯狂请求服务器，然后还没到秒杀的时候基本上服务器就挂了。按钮可以点击之后也得给他置灰几秒，不然他一样在开始之后一直点的。
Nginx层面
Nginx大家想必都不陌生了吧，这玩意是高性能的web服务器，并发也随便顶几万不是梦，但是我们的Tomcat只能顶几百的并发呀，那简单呀负载均衡嘛，一台服务几百，那就多搞点，在秒杀的时候多租点流量机。
国内某大厂就是在去年春节活动期间租光了亚洲所有的服务器，小公司也很喜欢在双十一期间买流量机来顶住压力。
风控层面
恶意请求拦截
前面的所有措施还是拦不住很多羊毛党，因为他们是专业的团队，他们可以注册很多账号来薅你的羊毛，而且不用机器请求，就用群控，操作几乎跟真实用户一模一样。
那怎么办，是不是无解了？这个时候就需要风控同学的介入了，在请求到达后端之前，风控可以根据账号行为分析出这个账号机器人的概率大不大，我现在负责公司的某些特殊系统，每个用户的行为都是会送到我们大数据团队进行分析处理，给你打上对应标签的。
那黑客其实也有办法：养号
他们去黑市买真实用户有过很多记录的账号，买到了还不闲着，帮他们去购物啥的，让系统无法识别他们是黑号还是真实用户的号。
怎么办？
通杀！是的没有办法，只能通杀了，通杀的意思就是，我们通过风管分析出来这个用户是真实用户的概率没有其他用户概率大，那就认为他是机器了，丢弃他的请求。
之前的限流我们放进来10000个请求，但是我们真正的库存只有1000个，那我们就算出最有可能是真实用户的1000人进行秒杀，丢弃其他请求，因为秒杀本来就是黑盒操作的，用户层面是无感知的，这样设计能让真实的用户买到东西，还可以减少自己被薅羊毛的概率。
后端层面
限流控制
秒杀的时候肯定是涉及到后续的订单生成和支付等操作，但是都只是成功的幸运儿才会走到那一步，那一旦100个产品卖光了，return了一个false，前端直接秒杀结束，然后你后端也关闭后续无效请求的介入了。
Tip：真正的限流还会有限流组件的加入例如：阿里的Sentinel、Hystrix等。我这里就不展开了，就说一下物理的限流。
服务单一职责
就是为秒杀系统新开一个独立的服务器，好处就是就算秒杀没抗住，秒杀库崩了，服务挂了，也不会影响到其他的服务。（高可用）
Redis层面
Redis集群
之前不是说单机的Redis顶不住嘛，那简单多找几个兄弟啊，秒杀本来就是读多写少，那你们是不是瞬间想起来我之前跟你们提到过的，Redis集群，主从同步、读写分离，我们还搞点哨兵，开启持久化直接无敌高可用！
库存预热
我们要开始秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去，让整个流程都在Redis里面去做，然后等秒杀介绍了，再异步的去修改库存就好了。
消息队列层面
秒杀就是这种瞬间流量很高，但是平时又没有流量的场景，那消息队列完全契合这样的场景了呀，削峰填谷。
你可以把它放消息队列，然后一点点消费去改库存就好了嘛，不过单个商品其实一次修改就够了，我这里说的是某个点多个商品一起秒杀的场景，像极了双十一零点。
MySQL层面
数据库用MySQL只要连接池设置合理一般问题是不大的，不过一般大公司不缺钱而且秒杀这样的活动十分频繁，我之前所在的公司就是这样秒杀特卖这样的场景一直都是不间断的。
单独给秒杀建立一个数据库，为秒杀服务，表的设计也是竟可能的简单点，现在的互联网架构部署都是分库的。
至于表就看大家怎么设计了，该设置索引的地方还是要设置索引的，建完后记得用explain看看SQL的执行计划。（不了解的小伙伴也没事，MySQL章节去康康）
分布式事务
因为上面的任何一步都是可能出错的，而且我们是在不同的服务里面出错的，那就涉及分布式事务了，但是分布式事务大家想的是一定要成功什么的那就不对了，还是那句话，几个请求丢了就丢了，要保证时效和服务的可用可靠。
所以TCC和最终一致性其实不是很适合，TCC开发成本很大，所有接口都要写三次，因为涉及TCC的三个阶段。
最终一致性基本上都是靠轮训的操作去保证一个操作一定成功，那时效性就大打折扣了。
大家觉得不那么可靠的**两段式（2PC）和三段式（3PC）**就派上用场了，他们不一定能保证数据最终一致，但是效率上还算ok。