大促场景系统稳定性保障实践经验总结( 二 ) 每到双11

1. 阿里全链路压测的完美复制（1）通过压测基础环境改造获得线上生产环境的读写压测能力；
（2）积累压测基础数据和业务流量模型经验，后续可通过购买PTS资源包继续进行常态化全链路压测；
（3）对于重大活动可以方便地提前预演，提前准备和应对。
文章插图
2. 流量防护提供业务系统全方位可用性防护，从网关防护和应用防护两个层面、入口/应用/应用间/单机负载多维度，提升系统的高可用性，包括低成本接入，全方位防护，多语言版本支持，秒级防护能力。
文章插图
3. 异地多活方案多活解决方案=定制技术产品+咨询服务+生态伙伴。
文章插图

故障演练混沌工程的专业技术和方案：遵循混沌工程实验原理并融合了阿里巴巴内部实践，提供了丰富故障场景实现，帮助分布式系统提升容错性和可恢复性。包括丰富演练库（基础资源、应用、云产品）；场景化演练（强弱依赖、消息、数据库等）；企业级实践（红蓝攻防、资损演练等）。

文章插图
三、秒杀最佳实践和解决方案第三位分享嘉宾是阿里云智能解决方案架构师鹿玄，他经历过大型分布式系统的开发和维护，并在云计算、云原生等领域有多年从业经验，对系统架构选型，问题排查和性能调优有着丰富的实战经验，致力于通过云原生架构转型来帮助阿里云各行业客户实现业务价值。

文章插图
首先我们来看秒杀业务流程，流程比较简单，一般就是下订单减库存：

文章插图
秒杀系统的设计原则包括以下几点：1 . 热点识别通过营销活动，卖家单独报名等方式，提前收集信息。
【大促场景系统稳定性保障实践经验总结】2 . 隔离原则在前端页面、应用层、数据层做好隔离。
3 . 将请求尽量拦截在系统上游。
传统秒杀系统之所以挂，请求都压到了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小，比如某种商品只有1000的库存， 100w个人来买，实际上绝大部分的请求有效率为0 。
4 . 读多写少的场景使用缓存
秒杀是一个典型的读多写少的应用场景，比如某种商品只有1000的库存， 100w个人来买，最多1000个人下单成功，其他人都是查询库存，写比例只有0.1% ，读比例占99.9% ，非常适合使用缓存。

文章插图
在秒杀场景中，从架构层面需要考虑的事情有以下几点：
1 . 库存缓存

文章插图
Redis作为大促期间库存扣减的主要承担方。商品ID作为Redis的KEY ，将可用库存=(总库存-暂扣库存)值作为Value 。利用LUA脚本的事务特性实现在Redis中“读剩余库存后扣减”的逻辑
2 . 容量规划
使用阿里云性能测试工具PTS ，模拟真实用户请求，验证全国用户真实业务操作对服务端性能、容量和系统稳定性的影响，确保重大活动平稳支撑。
3 . 性能调优
利用ARMS提供的立体式监控能力，在压测过程中实时监控应用及物理机各项指标，快速帮助开发人员定位排查问题，提升系统性能。

文章插图
4 . 限流防刷
使用阿里云应用高可用服务(AHAS) 实现限流降级，确保系统不被预期外的突发流量打挂。同时可配置热点规则，超过一定量的阈值后，系统会让购买热点商品的流量排队等待。例如购买同一商品， 1s内调用超过100次请求后，则其余请求进行等待

文章插图
5 . 异步解耦，削峰填谷
消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 版既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性