秒杀系统设计

一、性能上的优化方向

根本原则：东西要尽可能地少

1. 数据尽可能少

        用户请求与响应的数据，因为数据通过网络传输，占据带宽，需要耗费资源

2. 请求次数尽可能少

        每请求一次都要经历网络连接，比如三次握手四次挥手，可以将多个请求合并在一起一起返回

3. 路径尽可能少

        处理秒杀请求中经过的服务节点尽可能少，做的事情尽可能少

4. CPU执行时间尽可能少

        使用Profiler 和 Yourkit工具 可以查看整个请求中每个函数的CPU时间

        判断CPU成为瓶颈的办法：当QPS到达极限时，CPU使用率有没有超过95%。如果没有代表还有优化的空间，要么是有锁限制，要么有过多的本地I/O等待发生

5. 代码级别优化

5.1 减少编码

        每个字符的编码都需要查表，而查表操作非常消耗资源。所以减少 字符到字节或者 字节到字符的转换。

        将一些数据提前转换

        

5.2 减少序列化

        序列化大部分在RPC中发生，可以减少RPC

5.3 Java极致优化

        数据尽可能直接在nginx等上层直接返回，这样可以减少数据的序列化操作

        直接使用Servlet处理请求，这样可以减少一些MVC框架的繁琐配置节省1ms

        直接输出流数据，使用resp.getOutputStream()

---

二、安全上必须保证的设计

1. 避免单点

        服务需要无状态化，这样可以放心的启动多个节点

2. 限流保护

---

三、动静分离优化点

何为静态数据？静态数据就是没有与访问者相关的个性化数据。

我们应该将静态数据放在离用户最近的地方，减少传输消耗

比如一些资源文件提前下载到用户本地，秒杀时直接使用本地资源访问

资源还可以放在cdn上、浏览器缓存、服务端缓存

---

四、热点数据

1. 热点数据的发现，热点数据在哪里？

提前获得热点数据，开启保护，避免1%的请求影响了99%的请求

        1. 通过系统设置提前知晓：比如系统配置了秒杀商品

        2. 通过技术手段算出来，动态实时发现热点商品

2. 热点数据的处理

1. 优化：缓存热点数据
2. 限制：限制服务器资源
3. 隔离：应用部署隔离开、数据库隔离开，系统隔离开。就算宕机了也不会影响其他业务

五、流量消峰

方式

1. 请求异步化后台慢慢处理

        实现方式有将请求放入消息队列、将请求持久化到文件等，增加一个步骤做一个请求缓冲。

2. 将单次请求时间拉长

        请求峰值基于时间分片，请求会具有先后顺序，靠后的请求就已经没有库存了。降低并发度。

3. 分层过滤

        在不同层次尽可能过滤掉无效请求，让漏斗最末端才是有效请求

六、库存 扣减

用户创建订单即扣减库存，若用户未付款则恢复库存。

可能导致恶意下单问题，可以将此类用户（多次下单未付款等异常行为）打上标签，继续规约，限制此类用户下单等。

若库存结构简单，可直接放在redis中扣减库存。

避免产生锁

七、服务降级

当秒杀达到5w/s 时，某些操作进行降级（比如记录的获取从每页20条变为5条）

降级操作应该通过一个按钮点击即可完成。

需要提前规划、准备好这些兜底措施。

每个环节都需要有兜底方案（限流、拒绝服务、降级等），应对最坏的情况