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