微视春节项目中的集卡瓜分活动，是一个典型流量洪峰下的秒杀场景，本文作者参与其中，对高可用秒杀系统的架构设计做了一些思考和总结。（流量洪峰所带来的一系列挑战，足以激发每位程序员的斗志。云加社区将推出系列内容，欢迎关注）。
一、背景简介如今的互联网已经在海量服务领域有了很成熟的理论，有很多在流量洪峰下的实践。而微视春节项目中的集卡瓜分活动，主要环节包括发卡、集卡、瓜分等流程，涉及到高并发、降级预案等，是一个典型流量洪峰下的秒杀场景。我有幸参与其中，从0到1完整践行了海量服务。本文是对高可用秒杀系统的架构设计的一些思考，希望对读者有所帮助。
用户不能接受破窗的体验，例如：系统超时、系统错误的提示，或者直接404页面。
（2）如何应对瞬时高并发流量的挑战？木桶短板理论，整个系统的瓶颈往往都在DB，如何设计出高并发、高可用系统？
2. 如何设计秒杀系统？ （1）典型的互联网业务结构下图展示了一个典型的互联网业务结构抽象图，用户完成一个写操作，一般会通过接入层和逻辑层，这里的服务都是无状态，可以通过平行拓展去解决高并发的问题；到了DB层，必须要落到介质中，可以是磁盘/ssd/内存，如果出现key的冲突，会有一些并发控制技术，例如cas/加锁/串行排队等。
直筒型架构设计，指的是用户请求1:1的洞穿到DB层，如下图所示。在比较简单的业务中，才会采用这个模型。随着业务规模复杂度上来，一定会有DB和逻辑层分离、逻辑层和接入层分离。
漏斗型架构设计，指的是，用户的请求，从客户端到DB层，层层递减，递减的程度视业务而定。例如当10万人去抢1个物品时，DB层的请求在个位数量级，对于秒杀系统来讲，漏斗型架构设计就是比较理想的模型，如下图所示。
漏斗型的架构设计，是高并发的基础，能够做到：
及早发现，及早拒绝
Fast Fail
前端保护后端
3. 如何实现漏斗型系统？漏斗型系统需要从产品策略/客户端/接入层/逻辑层/DB层全方位立体的设计。
轻重逻辑分离，以秒杀为例，将抢到和到账分开；
- 抢到，是比较轻的操作，库存扣成功后，就可以成功了。
- 到账，是比较重的操作，需要涉及到到事务操作。
用户分流，以整点秒杀活动为例，在1分钟内，陆续对用户放开入口，将所有用户请求打散在60s内，请求就可以降一个数量级。
页面简化，在秒杀开始的时候，需要简化页面展示，该时刻只保留和秒杀相关的功能。例如，秒杀开始的时候，页面可以不展示推荐的商品。
（2）客户端
重试策略非常关键，如果用户秒杀失败了，频繁重试，会加剧后端的雪崩。如何重试呢？根据后端返回码的约定，有两种方法：
- 不允许重试错误，此时UI和文案都需要有一个提示。同时不允许重试；
- 可重试错误，需要策略重试，例如二进制退避法。同时文案和UI需要提示。
UI和文案，秒杀开始前后，用户的所有异常都需要有精心设计的UI和文案提示。例如：【当前活动太火爆，请稍后再重试】【你的货物堵在路上，请稍后查看】等。
前端随机丢弃请求可以作为降级方案，当用户流量远远大于系统容量时，人工下发随机丢弃标记，用户本地客户端开始随机丢弃请求。
（3）接入层
所有请求需要鉴权，校验合法身份。
如果是长链接的服务，鉴权粒度可以在session级别；如果是短链接业务，需要应对这种高并发流量，例如cache等。
根据后端系统容量，需要一个全局的限流功能，通常有两种做法：
- 设置好N后，动态获取机器部署情况M，然后下发单机限流值N/M。要求请求均匀访问，部署机器统一。
- 维护全局key，以时间戳建key。有热key问题，可以通过增加更细粒度的key或者定时更新key的方法。