微视春节项目中的集卡瓜分活动，是一个典型流量洪峰下的秒杀场景，本文作者参与其中，对高可用秒杀系统的架构设计做了一些思考和总结。（流量洪峰所带来的一系列挑战，足以激发每位程序员的斗志。云加社区将推出「高可用架构之流量洪峰」系列内容，欢迎关注）。

一、背景简介

如今的互联网已经在海量服务领域有了很成熟的理论，有很多在流量洪峰下的实践。而微视春节项目中的集卡瓜分活动，主要环节包括发卡、集卡、瓜分等流程，涉及到高并发、降级预案等，是一个典型流量洪峰下的秒杀场景。我有幸参与其中，从0到1完整践行了海量服务。本文是对高可用秒杀系统的架构设计的一些思考，希望对读者有所帮助。

                        

二、秒杀系统剖析

1. 秒杀系统面临的难点

（1）如何保证友好的用户体验？

用户不能接受破窗的体验，例如：系统超时、系统错误的提示，或者直接404页面。

（2）如何应对瞬时高并发流量的挑战？

木桶短板理论，整个系统的瓶颈往往都在DB，如何设计出高并发、高可用系统？

2. 如何设计秒杀系统？

（1）典型的互联网业务结构

下图展示了一个典型的互联网业务结构抽象图，用户完成一个写操作，一般会通过接入层和逻辑层，这里的服务都是无状态，可以通过平行拓展去解决高并发的问题；到了DB层，必须要落到介质中，可以是磁盘/ssd/内存，如果出现key的冲突，会有一些并发控制技术，例如cas/加锁/串行排队等。

（2）直筒型架构设计

直筒型架构设计，指的是用户请求1:1的洞穿到DB层，如下图所示。在比较简单的业务中，才会采用这个模型。随着业务规模复杂度上来，一定会有DB和逻辑层分离、逻辑层和接入层分离。

（3）漏斗型架构设计

漏斗型架构设计，指的是，用户的请求，从客户端到DB层，层层递减，递减的程度视业务而定。例如当10万人去抢1个物品时，DB层的请求在个位数量级，对于秒杀系统来讲，漏斗型架构设计就是比较理想的模型，如下图所示。

漏斗型的架构设计，是高并发的基础，能够做到：

• 及早发现，及早拒绝

• Fast Fail

• 前端保护后端

3. 如何实现漏斗型系统？

漏斗型系统需要从产品策略/客户端/接入层/逻辑层/DB层全方位立体的设计。

（1）产品策略

• 轻重逻辑分离，以秒杀为例，将抢到和到账分开；

  - 抢到，是比较轻的操作，库存扣成功后，就可以成功了。

  - 到账，是比较重的操作，需要涉及到到事务操作。

• 用户分流，以整点秒杀活动为例，在1分钟内，陆续对用户放开入口，将所有用户请求打散在60s内，请求就可以降一个数量级。

• 页面简化，在秒杀开始的时候，需要简化页面展示，该时刻只保留和秒杀相关的功能。例如，秒杀开始的时候，页面可以不展示推荐的商品。

（2）客户端

• 重试策略非常关键，如果用户秒杀失败了，频繁重试，会加剧后端的雪崩。如何重试呢？根据后端返回码的约定，有两种方法：

  - 不允许重试错误，此时UI和文案都需要有一个提示。同时不允许重试；

  - 可重试错误，需要策略重试，例如二进制退避法。同时文案和UI需要提示。

• UI和文案，秒杀开始前后，用户的所有异常都需要有精心设计的UI和文案提示。例如：【当前活动太火爆，请稍后再重试】【你的货物堵在路上，请稍后查看】等。

• 前端随机丢弃请求可以作为降级方案，当用户流量远远大于系统容量时，人工下发随机丢弃标记，用户本地客户端开始随机丢弃请求。

（3）接入层

• 所有请求需要鉴权，校验合法身份。

  如果是长链接的服务，鉴权粒度可以在session级别；如果是短链接业务，需要应对这种高并发流量，例如cache等。

• 根据后端系统容量，需要一个全局的限流功能，通常有两种做法：

  - 设置好N后，动态获取机器部署情况M，然后下发单机限流值N/M。要求请求均匀访问，部署机器统一。

  - 维护全局key，以时间戳建key。有热key问题，可以通过增加更细粒度的key或者定时更新key的方法。

• 对于单用户/单IP需要频控，主要是防黑产和恶意用户。如果秒杀是有条件的，例如需要完成xxx任务，解锁资格，对于获得资格的步骤，可以进行安全扫描，识别出黑产和恶意用户。

（4）逻辑层

• 逻辑层首先应该进入校验逻辑，例如参数的合法性，是否有资格，如果失败的用户，快速返回，避免请求洞穿到DB。

• 异步补单，对于已经扣除秒杀资格的用户，如果发货失败后，通常的两种做法是：

  - 事务回滚，回滚本次行为，提示用户重试。这个代价特别大，而且用户重试和前面的重试策略结合的话，用户体验也不大流畅。

  - 异步重做，记录本次用户的log，提示用户【稍后查看，正在发货中】，后台在峰值过后，启动异步补单。需要服务支持幂等。

• 对于发货的库存，需要处理热key。通常的做法是，维护多个key，每个用户固定去某个查询库存。对于大量人抢红包的场景，可以提前分配。

（5）存储层

对于业务模型而言，对于DB的要求需要保证几个原则：

• 可靠性

  - 主备：主备能互相切换，一般要求在同城跨机房。

  - 异地容灾：当一地异常，数据能恢复，异地能选主。

  - 数据需要持久化到磁盘，或者更冷的设备。

• 一致性

  对于秒杀而言，需要严格的一致性，一般要求主备严格的一致。

 

三、微视春节集卡瓜分活动实践

1. 用户体验流程

微视集卡瓜分项目属于微视春节项目之一。用户的体验流程如下:

2. 架构设计图

微视集卡瓜分项目的架构设计如下图所示。

• 客户端主要是微视主APP和H5页面，主App是入口，H5页面是集卡活动页面和瓜分页面。

• 逻辑部分主要分为：发卡来源、集卡模块、奖品模块，发卡来源主要是任务模块；集卡模块主要由活动模块和集卡模块组成。瓜分部分主要在活动控制层。

• 奖品模块主要是发钱和其他奖品。

3. 瓜分降级预案

为了做好瓜分时刻的高并发，对整个系统需要保证两个重要的事情：

• 全链路梳理，包括调用链的合理性和时延设置。

• 降级服务预案分析，提升系统的鲁棒性。

针对瓜分全链路调用分析时，需要特别说明的几点：

• 时延很重要，需要全链路分析。不但可以提高吞吐量，而且可以快速暴露系统的瓶颈。

• 峰值时刻，补单逻辑需要关闭，避免加剧雪崩。

我们的降级预案大概如下：

（1）一级预案（瓜分时刻前后5分钟自动进入）

• 入口处1分钟内陆续放开入口倒计时，未登录用户不弹入口。

• 主会场排队，进主会场20wqps，超过了进入排队，由接入层频控控制。

• 拉取资格接口排队，拉取资格接口20wqps，超过了进入排队，由接入层频控控制。

• 抢红包排队，抢红包20wqps，超过了进入排队，由接入层频控控制。

• 红包到账排队，如果资格扣除成功，现金发放失败，进入排队，24小时内到账。异步补单。

• 入口处调用后端非关键rpc:ParticipateStatus，手动关闭。

• 异步补单逻辑关闭。

（2）二级预案，后端随机丢请求，接入层频控失效或者下游服务过载，手动开启。

（3）三级预案，前端随机丢请求，后端服务过载或者宕机进入，手动开启。

综上，整个瓜分时刻体验如下所示：

最后，对应漏斗模型，总结下这次活动的实践。

                        

四、关于架构师成长的几点思考

• 建立自己关于整个技术领域的知识图谱很重要，例如从访问一个网站开始，都经历了哪些技术点？从工作中学习，对每个技术点刨根问底，把工作中的积累放到自己的知识图谱中。

• 找机会总结、分享，把知识图谱分享给别人，一方面可以加深熟悉自己的知识图谱，另一方面可以和他人技术交流，提高自己分享表达的能力，也是对自身抽象能力的锻炼。

• 随着知识图谱的建立，熟悉互联网技术的分布式问题解决方案，可以进一步在自己业务上梳理和抽象业务模型，积累自身领域经验。

• 在业务发展和代码重构中，去体验和验证自己的领域经验。再把领域经验横向对比其他业务模型。

作者所在的团队正在招聘后台开发同学，感兴趣的同学请在公众号后台回复“投简历”参与应聘~

标签：架构设计,用户,微视,重试,集卡,瓜分,秒杀,看高
来源： https://www.cnblogs.com/qcloud1001/p/12881478.html