聊一聊系列之：面对秒杀

秒杀：

类如拼夕夕9.9抢手机，双十一某宝12点半价活动

两个特点：

① 极短的时间内
② 定量库存

面对秒杀要解决的问题：

• 高并发

简而言之言而简之秒杀的问题根源在于数据是否正确，解决过程在于如何有效处理高并发

解决方案：

① CDN
为了让用户更快地访问到页面上的秒杀信息，通过CDN用户可以从最近的点获取到网络资源，不同的用户由于所在地不同所访问的节点也不同，这样前端页面资源就被分散在不同的地域。

② 负载均衡
nginx负载均衡，均衡分配请求，保证整体的吞吐量

③ 分布式缓存
web应用前端请求后端请求的是资源，对于秒杀必定存在热点数据，将热点数据放置在缓存中，但是缓存也存在一系列问题比如缓存雪崩等，那么就不得考虑考虑选择缓存的策略，主动加载和被动刷新，对于秒杀这个场景那肯定是用主动加载最好，在开始前用定时任务主动加载热点数据到缓存中。

④ 熔断
面对秒杀即便有负载均衡，我们也无法知道每台机器用户的请求量到底能达到什么程度，但是我们知道每台机器的性能上限，还能控制到达每台机器的请求上限。
熔断的方法：

• 熔断算法：例如令牌桶算法、漏斗算法
• 熔断器：例如Sentinel、Hystrix

⑤ 领域驱动设计模式
说到这个模式可能说的范围太大了，但是对于秒杀来说如果活动是存在几十万上百万的请求时，秒杀就不应该只是一个功能，而应该是作为一个系统层面来看，并且根据微服务设计理念来看，应将订单系统和秒杀系统隔离开来。这是因为，如果实在是出现了某些问题，我们不能让一个系统的崩坏而影响整体的核心功能。

⑥ 消息机制
系统拆分后，对于订单系统与秒杀系统间的交互有多种选择，那么为了更加符合秒杀这个场景，在交互时可以选用消息机制。消息机制的特性：

• 削峰
• 异步
• 容错
• 可横向扩展

⑦ 锁
之前说秒杀问题的根源在于数据是否正确，多线程访问数据库造成的问题是大家老生常谈的问题了。那么我在这里提供我的解决方案，在业务应用层和基础设施层中分别需要加上锁来保证业务的原子性：

• 基础设施层的话使用数据库的锁即可。
• 业务应用层这里推荐redis分布式锁，虽然redis分布式锁并不一定真正能够完全锁住，但是就从redis本身提供的事务和他单线程的特性以及lua脚本带来的极大扩展性使得面对秒杀的场景完全适用。这里如果你把校验库存和扣减库存两步 *** 作通过lua脚本缩减为一步 *** 作，那么在redis单线程下执行一步 *** 作不仅减少了多一次加锁的消耗，也不会存在线程安全的问题。

⑧ 防作弊
在某些平台上经常会发现有很多黄牛等代抢业务，他们会使用一些工具或者解析网站请求的方式去快速拿到秒杀的商品，在业务上来说这种情况属于正常流程，但对于客户来说极为不公平，而且会致使黄牛越发扰乱市场。面对作弊呢，我在这里提供几个意见：

• 尽可能晚地暴露秒杀链接
• 服务端应主动校验活动是否开始，防止作弊行为在客户端篡改时间或页面倒计时的数据
• 动态生成加密请求链接，不暴露任何规律性
• ip限流，同一ip地址在极短的一段时间内不该请求秒杀功能多次