【分布式微服务秒杀系统】一、初识秒杀

最新推荐文章于 2023-01-25 13:54:27 发布

Y_lxl

最新推荐文章于 2023-01-25 13:54:27 发布

阅读量536

点赞数 5

分类专栏：分布式微服务

本文链接：https://blog.csdn.net/Y_lxl/article/details/108412860

版权

分布式微服务专栏收录该内容

5 篇文章 1 订阅

订阅专栏

介绍

所谓“秒杀”，就是在同一时刻大量请求争抢购买同一商品并完成交易的过程，我们应该都有用过或者见过，比如京东、淘宝、天猫、亚马逊电商平台的秒杀抢购以及12306 抢票。从架构维度来看，秒杀系统本质上是一个高性能、高一致、高可用的三高系统。

业务特点

瞬时并发量大
秒杀时会有大量用户在同一时间进行抢购，瞬时并发访问量突增 10 倍，甚至 100 倍以上都有。
库存量少
一般秒杀活动商品量很少，这就导致了只有极少量用户能成功购买到。
业务简单
流程比较简单，一般都是下订单、扣库存、支付订单。

设计思路

从高维度出发，整体思考问题。秒杀无外乎解决两个核心问题，一是并发读，一是并发写，对应到架构设计，就是高可用、一致性和高性能的要求。

动静分离

用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。采用动静分离，将动态页面改造成适合缓存的静态页面。分三步走：数据拆分、静态缓存、数据整合。

数据拆分

用户。用户身份信息相关要素可以单独拆分出来，通过动态请求进行获取；与之相关的推荐，如用户偏好、地域偏好等，同样可以通过异步方式进行加载。
时间。秒杀时间是由服务端统一管控的，可以通过动态请求进行获取。

静态缓存

缓存方式：将URL作为缓存键，直接缓存整个 HTTP 连接而不是仅仅缓存静态数据。Web 代理服务器根据请求 URL，可以直接取出对应的响应体然后直接返回，响应过程无需重组 HTTP 协议，也无需解析 HTTP 请求头。
缓存位置：通常将静态数据缓存在 CDN，选取条件：临近访问量集中的地区、距离主站较远的地区、节点与主站间网络质量良好的地区。选择 CDN 的二级缓存比较合适，因为二级缓存数量偏少，容量也更大，访问量相对集中。

数据整合
前端动态数据的加载处理，通常有两种方案：

ESI 方案：Web 代理服务器上请求动态数据，并将动态数据插入到静态页面中，用户看到页面时已经是一个完整的页面。这种方式对服务端性能要求高，但用户体验较好。
CSI 方案：Web 代理服务器上只返回静态页面，前端单独发起一个异步 JS 请求动态数据。这种方式对服务端性能友好，但用户体验稍差。

热点隔离

秒杀业务具备瞬时高并发的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。可以基于以下几个层次实现热点隔离：

业务隔离。秒杀作为一种营销活动，卖家需要单独报名，从技术上来说，系统可以提前对已知热点做缓存预热。
系统隔离。系统隔离是运行时隔离，通过分组部署和另外 99% 进行分离，另外秒杀也可以申请单独的域名，入口层就让请求落到不同的集群中。
数据隔离。秒杀数据作为热点数据，可以启用单独的缓存集群或者 DB 服务组，从而更好的实现横向或纵向能力扩展。

热点优化

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

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

扣减库存

秒杀系统中，库存是个关键数据，卖不出去是个问题，超卖更是个问题。秒杀场景下的一致性问题，主要就是库存扣减的准确性问题。采用预扣库存方案，买家下单后，有个 “有效付款时间”，超过该时间库存自动释放，释放后其他买家可以购买。

流量削峰

对于秒杀的目标场景，最终能够抢到商品的人数是固定的，无论 100 人和 10000 人参加结果都是一样的，即有效请求额度是有限的。并发度越高，无效请求也就越多。但秒杀作为一种商业营销手段，活动开始之前是希望有更多的人来刷页面，只是真正开始后，秒杀请求不是越多越好。
因此系统可以设计一些规则，人为的延缓秒杀请求，甚至可以过滤掉一些无效请求。

答题
主要是通过提升购买的复杂度，达到两个目的：防止作弊、延缓请求。答题目前已经使用的非常普遍了，本质是通过在入口层削减流量，从而让系统更好地支撑瞬时峰值。
排队
最为常见的削峰方案是使用消息队列，通过把同步的直接调用转换成异步的间接推送缓冲瞬时流量。排队方式的弊端主要有两点：
请求积压。流量高峰如果长时间持续，达到了队列的水位上限，队列同样会被压垮，这样虽然保护了下游系统，但是和请求直接丢弃也没多大区别。
用户体验。异步推送的实时性和有序性自然是比不上同步调用的，由此可能出现请求先发后至的情况，影响部分敏感用户的购物体验。
排队本质是在业务层将一步操作转变成两步操作，从而起到缓冲的作用，但鉴于此种方式的弊端，最终还是要基于业务量级和秒杀场景做出妥协和平衡。
过滤
过滤的核心结构在于分层，通过在不同层次过滤掉无效请求，达到数据读写的精准触发。
常见的过滤主要有以下几层：
读限流：对读请求做限流保护，将超出系统承载能力的请求过滤掉。
读缓存：对读请求做数据缓存，将重复的请求过滤掉。
写限流：对写请求做限流保护，将超出系统承载能力的请求过滤掉。
写校验：对写请求做一致性校验，只保留最终的有效数据。