秒杀系统总结与思考(二) 数据动静分离

关注

原创最新推荐文章于 2026-03-16 14:42:29 发布 495 阅读 AI 写同款· GEO 优化 ›

【Java】如何设计一个秒杀系统 说起秒杀，我想你肯定不陌生，这两年，从双十一购物到春节抢红包，再到12306抢火车票，“秒杀”的场景处处可见。简单来说，秒杀就是在同一个时刻有大量的请求争抢购买同一个商品并完成交易的过程，用技术的行话来说就是大量的并发读和并发写。不管是哪一门语言，并发都是程序员们最为头疼的部分。同样，对于一个软件而言也是这样，你可以很快增删改查做出一个秒杀系统，但是要让它支持高并发访问就没那么容易了。比如说，如何让系统面对百万级的请求流量不出故障？如何保证高并发情况下数据的一致性写？完全靠堆服务器来解决吗？阅读详情

何为动静数据

“动态数据”和“静态数据”的主要区别就是看页面中输出的数据是否和 URL、浏览者、时间、地域相关，以及是否含有 Cookie 等私密数据。比如说：
1、媒体类网站，无论谁访问，文章内容都一样，典型的静态资源
2、页面上的个性化推荐与个人信息等为动态数据

静态数据如何缓存呢

1、将静态数据缓存在用户最近的地方。常见的有三种:
· 用户浏览器
· CDN上
· 服务器的Cache上
2、静态化改造就是直接缓存HTTP连接。静态化缓存HTTP连接不是仅仅缓存数据，就连HTTP协议都不用重新组装
在这里插入图片描述
3、谁来缓存静态数据。不同语言的Cache处理效率各不同
以 Java 为例，因为 Java 系统本身也有其弱点（比如不擅长处理大量连接请求，每个连接消耗的内存较多，Servlet 容器解析 HTTP 协议较慢），所以你可以不在 Java 层做缓存，而是直接在 Web 服务器层上做，这样你就可以屏蔽 Java 语言层面的一些弱点；而相比起来，Web 服务器（如 Nginx、Apache、Varnish）也更擅长处理大并发的静态文件请求。

如何做静态分离的改造

1、URL唯一化。商品详情天然可以做到URL唯一化，以URL作为缓存的key
2、分离浏览者相关的因素。浏览者相关的动态数据，通过动态请求获取
3、分离时间因素。服务器输出的时间也通过动态请求获取（时间以服务器为准防止用户篡改）
4、异步化地域因素。详情页与地域相关因素做成异步获取
5、去掉Cookie。缓存的静态数据中不包含Cookie

动态内容处理方案

ESI（Edge Side includes）、CSI(Client Side Include)方案
1、ESI: 服web代理服务器上做动态内容请求，将请求插入静态页面中（服务端组装数据）
2、CSI: 页面单独发起异步js请求，异步动态获取动态内容。性能更加，稍有延迟（客户端数据分离异步）

动静分离的几种架构方案

1、实体机单机部署
2、统一Cache层
3、上CDN

方案1: 实体机单机部署

将虚拟机改成实体机，增大Cache容量，采用一致性Hash分组提高命中率。Cache分组，是希望能达到命中率和访问热点平衡。Hash分组越少，缓存命中率肯定越高，短板是单个商品集中在一个分组中，容易Cache击穿，应适当增加多个相同的分组，平衡访问任店和命中率。
在这里插入图片描述
实体机单机部署几个优点:
1、没有网络瓶颈，而且能使用大内存
2、既能提升命中率，又能减少Gzip压缩
3、减少Cache是要压力，采用定时失效方式，例如只缓存3秒中，过期自动失效

总结:
此方案中，通常只要把虚拟机或者容器运行的java应用换成实体机，会增加单机的内存容量，单会造成一定的CPU浪费。
实体机上部署了java又部署了Cache，造成运维上的复杂度。

方案二: 统一Cache层

将单机的Cache统一分离出来，形成单独的Cache集群
在这里插入图片描述
Cache层单独统一管理可减少运维成本，方便接入其他静态系统，还有其他的优点:
1、单独的一个Cache层，减少多个应用接入使用Cache的成本
2、统一Cache易于维护监控，自动化
3、共享内存，最大利用内从

带来的问题:
1、Cache层内部交换网络有瓶颈
2、缓存服务器的网卡也是瓶颈
3、机器少风险大，挂掉一台影响很大一部分缓存数据
解决上面问题，可以对Cache做Hash分组，即一组Cache缓存内容相同，避免热点数据过度集中

方案三: 上CDN

整个系统动静分离后，进一步的方案，是将Cache进一步移动到CDN,CDN离用户更近一些
需要解决的问题:
1、失效问题。静态数据虽然是“相对不变”，也就是可能变，如有错别字，如果缓存时效很长，就会有问题。我们需要保证CDN可以在秒级时间内，让分部在各地的Cache同时失效，对CDN的失效系统要求很高
2、命中率问题。Cache最重要的指标就是，高命中率。如果将数据放在全国的CDN上，Cache必定是分散的，就会带来命中率的问题
3、发布更新问题。如果业务系统每周都有日常业务需要发布，那么发布系统需要足够简洁高效，还要考虑快速回滚和问题排查的简便性

所以，将商品详情系统放全国所有CDN节点是不现实的，可选择若干节点尝试实施
1、靠近访问量比较集中的地区
2、离主站相对较远
3、节点到主站间网络比较好，稳定
4、节点容量大，不占用其他CDN太多资源
5、节点不要太多
在这里插入图片描述
基于以上因素，选择CDN的二级Cache比较合适，二级Cache数量偏少，容量更大，让用户请求先回源CDN的二级Cache中，如果没命中再回源获取数据。