2 秒杀系统架构
第一步 思考面临的问题和业务场景
秒杀系统面临的问题: 短时间内并发非常高，如果按照秒杀的并发做相应的承载会造成大量资源的浪费。第二解决超卖的问题。
第二步 思考目前的处境和解决方案
因为秒杀系统属于短时间内的高并发问题，我们不可能使用那么多的硬件资源去部署对应的承载。而且还有个问题，我们其实并卖不到那么多的商品，只是做一个商品促销的噱头吸引用户到我们的平台来，让他们知道我们的平台并记下我们的平台。
那么也就是说其实大部分用户买不到商品是正常行为，所以我们可以通过这个特性把大部分的用户在服务的上游就过滤掉，而不是公平的竞争有限的商品。基于这个思想我们对我们的设计进行一些优化。
- 用户在进行抢购前肯定是先打开页面，这是第一步。那么我们为了避免服务器资源被短时间大量的请求压垮，需要把页面静态化放到CDN上，减少服务器的压力
- 用户在到了秒杀的时间节点为了抢到商品肯定快速的点击页面，这个请求会使用到后台的服务，我们为了减少用户频繁的请求，在前端代码做一些控制，点击按钮后置灰不能多次的点击请求后台服务
- 用户在点击按钮无反应的情况下，可能会重写打开页面再次发起请求，可以利用页面缓存让用户在一段时间内打开的页面是缓存页面
- 用户打开页面时候，有些实时数据肯定是要最新的，要不然用户发现是假数据或者是缓存在浏览器和CDN上的时候，用户体验很差。比如像剩余库存这些数据，但是我们又不希望这些查询请求落到数据库，所以部分数据放在缓存中，减少数据库的压力(页面缓存也可以但是需要缓存的时间短，不能太长
当我们做了上面的工作之后，还是会有大量的请求涌入到后台服务。因为要解决超卖的问题，我们在买入操作的时候肯定是要给商品的数量加锁。如果请求并发太高，会造成redis分布式锁设置的失效时间失效，也会造成超卖的问题。
我们可以在购买商品，锁库存数量之前再过滤掉一部分请求。例如我们用不加锁的缓存下商品数量，当涌入的人数超过一定数量的时候比如超过商品库存的时候，或者商品库存N倍的时候，后面的请求就不会再进入到后面的处理逻辑。
我们在一个用户点击购买时，就给用户数量+1，超过一定数量就不让后面的人进入。这个时候有个问题，就是我们的缓存并未加锁，比如我商品库存是100件，由于未加锁，这个时候可能同时涌入300个用户进入购买流程。其实这个问题很容易解决，我们在这300个人进入购买流程后再加分布式锁，这个时候就能保证加锁的redis不会处问题。
上面的思想基本上是基于把用户进入到购买流程前尽量过滤掉，到真正购买的流程后其实没有那么多的竞争压力，对服务器的压力也减小很多。上面我们用到了很多缓存策略，我们还需要考虑缓存穿透的问题，雪崩的问题等等。这些细节我们在后面的文章中再做讨论，我们接着讲后面的设计
第三 不怕一万就怕万一，我们对系统的可用性做到尽量的好
假如我们在秒杀系统中有一些关键的点没考虑到，秒杀系统崩了。结果影响到其他正常的服务怎么办？
我们的解决方案是隔离。把秒杀系统的服务和正常的服务隔离开。我们知道秒杀活动是需要商家参与的，当商家加入秒杀活动的时候，我们在秒杀服务建立和正常业务同样的库表结构，商家参与秒杀的商品数量等信息同步到秒杀系统的库中，这样可以做到完全的物理隔离，即时秒杀系统崩了，其他的业务也能正常运行。
以上是秒杀服务设计中比较重要的几个点。具体的细节涉及到太多，我们不做深究。