对于单用户/单IP需要频控，主要是防黑产和恶意用户。如果秒杀是有条件的，例如需要完成xxx任务，解锁资格，对于获得资格的步骤，可以进行安全扫描，识别出黑产和恶意用户。
（4）逻辑层
逻辑层首先应该进入校验逻辑，例如参数的合法性，是否有资格，如果失败的用户，快速返回，避免请求洞穿到DB。
异步补单，对于已经扣除秒杀资格的用户，如果发货失败后，通常的两种做法是：
- 事务回滚，回滚本次行为，提示用户重试。这个代价特别大，而且用户重试和前面的重试策略结合的话，用户体验也不大流畅。
- 异步重做，记录本次用户的log，提示用户【稍后查看，正在发货中】，后台在峰值过后，启动异步补单。需要服务支持幂等。
对于发货的库存，需要处理热key。通常的做法是，维护多个key，每个用户固定去某个查询库存。对于大量人抢红包的场景，可以提前分配。
（5）存储层对于业务模型而言，对于DB的要求需要保证几个原则：
可靠性
- 主备：主备能互相切换，一般要求在同城跨机房。
- 异地容灾：当一地异常，数据能恢复，异地能选主。
- 数据需要持久化到磁盘，或者更冷的设备。
一致性
对于秒杀而言，需要严格的一致性，一般要求主备严格的一致。
三、微视春节集卡瓜分活动实践 1. 用户体验流程
微视集卡瓜分项目属于微视春节项目之一。用户的体验流程如下:
微视集卡瓜分项目的架构设计如下图所示。
客户端主要是微视主APP和H5页面，主App是入口，H5页面是集卡活动页面和瓜分页面。
逻辑部分主要分为：发卡来源、集卡模块、奖品模块，发卡来源主要是任务模块；集卡模块主要由活动模块和集卡模块组成。瓜分部分主要在活动控制层。
奖品模块主要是发钱和其他奖品。
3. 瓜分降级预案为了做好瓜分时刻的高并发，对整个系统需要保证两个重要的事情：
全链路梳理，包括调用链的合理性和时延设置。
降级服务预案分析，提升系统的鲁棒性。
针对瓜分全链路调用分析时，需要特别说明的几点：
时延很重要，需要全链路分析。不但可以提高吞吐量，而且可以快速暴露系统的瓶颈。
峰值时刻，补单逻辑需要关闭，避免加剧雪崩。
我们的降级预案大概如下：
（1）一级预案（瓜分时刻前后5分钟自动进入）
入口处1分钟内陆续放开入口倒计时，未登录用户不弹入口。
主会场排队，进主会场20wqps，超过了进入排队，由接入层频控控制。
拉取资格接口排队，拉取资格接口20wqps，超过了进入排队，由接入层频控控制。
抢红包排队，抢红包20wqps，超过了进入排队，由接入层频控控制。
红包到账排队，如果资格扣除成功，现金发放失败，进入排队，24小时内到账。异步补单。
入口处调用后端非关键rpc:ParticipateStatus，手动关闭。
异步补单逻辑关闭。
（2）二级预案，后端随机丢请求，接入层频控失效或者下游服务过载，手动开启。 （3）三级预案，前端随机丢请求，后端服务过载或者宕机进入，手动开启。综上，整个瓜分时刻体验如下所示：
最后，对应漏斗模型，总结下这次活动的实践。
建立自己关于整个技术领域的知识图谱很重要，例如从访问一个网站开始，都经历了哪些技术点？从工作中学习，对每个技术点刨根问底，把工作中的积累放到自己的知识图谱中。
找机会总结、分享，把知识图谱分享给别人，一方面可以加深熟悉自己的知识图谱，另一方面可以和他人技术交流，提高自己分享表达的能力，也是对自身抽象能力的锻炼。
随着知识图谱的建立，熟悉互联网技术的分布式问题解决方案，可以进一步在自己业务上梳理和抽象业务模型，积累自身领域经验。
在业务发展和代码重构中，去体验和验证自己的领域经验。再把领域经验横向对比其他业务模型。