大型电商网站分布式秒杀系统设计三种姿势( 三 ) _分布式

热点优化：热点数据隔离之后，也就方便对这 1% 的请求做针对性的优化。
方式无外乎两种：

缓存：热点缓存是最为有效的办法。如果热点数据做了动静分离，那么可以长期缓存静态数据。
限流：流量限制更多是一种保护机制。需要注意的是，各服务要时刻关注请求是否触发限流并及时进行 Review 。

小结：数据的热点优化与动静分离是不一样的，热点优化是基于二八原则对数据进行了纵向拆分，以便进行针对性地处理。
热点识别和隔离不仅对“秒杀”这个场景有意义，对其他的高性能分布式系统也非常有参考价值。
系统优化对于一个软件系统，提高性能可以有很多种手段，如提升硬件水平、调优 JVM 性能，这里主要关注代码层面的性能优化。
①减少序列化：减少 Java 中的序列化操作可以很好的提升系统性能。序列化大部分是在 RPC 阶段发生，因此应该尽量减少 RPC 调用。
一种可行的方案是将多个关联性较强的应用进行 “合并部署”，从而减少不同应用之间的 RPC 调用（微服务设计规范）。
②直接输出流数据：只要涉及字符串的 I/O 操作，无论是磁盘 I/O 还是网络 I/O，都比较耗费 CPU 资源，因为字符需要转换成字节，而这个转换又必须查表编码。
所以对于常用数据，比如静态字符串，推荐提前编码成字节并缓存，具体到代码层面就是通过 OutputStream() 类函数从而减少数据的编码转换。
另外，热点方法 toString() 不要直接调用 ReflectionToString 实现，推荐直接硬编码，并且只打印 DO 的基础要素和核心要素。
裁剪日志异常堆栈：无论是外部系统异常还是应用本身异常，都会有堆栈打出，超大流量下，频繁的输出完整堆栈，只会加剧系统当前负载。可以通过日志配置文件控制异常堆栈输出的深度。
去组件框架：极致优化要求下，可以去掉一些组件框架，比如去掉传统的 MVC 框架，直接使用 Servlet 处理请求。
这样可以绕过一大堆复杂且用处不大的处理逻辑，节省毫秒级的时间，当然，需要合理评估你对框架的依赖程度。
总结一下性能优化需要一个基准值，所以系统还需要做好应用基线，比如性能基线（何时性能突然下降）、成本基线（去年大促用了多少机器）、链路基线（核心流程发生了哪些变化）。
通过基线持续关注系统性能，促使系统在代码层面持续提升编码质量、业务层面及时下掉不合理调用、架构层面不断优化改进。
一致性
秒杀系统中，库存是个关键数据，卖不出去是个问题，超卖更是个问题。秒杀场景下的一致性问题，主要就是库存扣减的准确性问题。
减库存的方式
电商场景下的购买过程一般分为两步：下单和付款。“提交订单”即为下单，“支付订单”即为付款。
基于此设定，减库存一般有以下几个方式：

下单减库存。买家下单后，扣减商品库存。下单减库存是最简单的减库存方式，也是控制最为精确的一种。
付款减库存。买家下单后，并不立即扣减库存，而是等到付款后才真正扣减库存。但因为付款时才减库存，如果并发比较高，可能出现买家下单后付不了款的情况，因为商品已经被其他人买走了。
预扣库存。这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 15 分钟），超过这段时间，库存自动释放，释放后其他买家可以购买。

能够看到，减库存方式是基于购物过程的多阶段进行划分的，但无论是在下单阶段还是付款阶段，都会存在一些问题，下面进行具体分析。
减库存的问题①下单减库存
优势：用户体验最好。下单减库存是最简单的减库存方式，也是控制最精确的一种。
下单时可以直接通过数据库事务机制控制商品库存，所以一定不会出现已下单却付不了款的情况。
劣势：可能卖不出去。正常情况下，买家下单后付款概率很高，所以不会有太大问题。
但有一种场景例外，就是当卖家参加某个促销活动时，竞争对手通过恶意下单的方式将该商品全部下单，导致库存清零，那么这就不能正常售卖了——要知道，恶意下单的人是不会真正付款的，这正是 “下单减库存” 的不足之处。
②付款减库存
优势：一定实际售卖。“下单减库存” 可能导致恶意下单，从而影响卖家的商品销售，“付款减库存” 由于需要付出真金白银，可以有效避免。