这一次，彻底弄懂“秒杀系统”( 四 ) _秒杀系统

文章插图

负压力测试示意图
压力测试的步骤

文章插图

测试步骤
有了测试方法的加持，我们来看看需要遵循哪些测试步骤。下面的操作偏套路化，大家在其他系统的压力测试也可以这么做，给大家做个参考。
第一，确定测试目标。与性能测试不同的是，压力测试的目标是，什么时候系统会接近崩溃。比如：需要支撑 500W 访问量。
第二，确定关键功能。压力测试其实是有重点的，根据 2/8 原则，系统中 20% 的功能被使用的是最多的，我们可以针对这些核心功能进行压力测试。例如：下单，库存扣减。

文章插图

关注核心服务
第三，确定负载。这个和关键服务的思路一致，不是每个服务都有高负载的，我们的测试其实是要关注那些负载量大的服务，或者是一段时间内系统中某些服务的负载有波动。这些都是测试目标。
第四，选择环境，建议搭建和生产环境一模一样的环境进行测试。
第五，确定监视点，实际上就是对关注的参数进行监视，例如 CPU 负载，内存使用率，系统吞吐量等等。
第六，产生负载，这里需要从生产环境去获取一些真实的数据作为负载数据源，这部分数据源根据目标系统的承受要求由脚本驱动，对系统进行冲击。
建议使用往期秒杀系统的数据，或者实际生产系统的数据进行测试。
第七，执行测试，这里主要是根据目标系统，关键组件，用负载进行测试，返回监视点的数据。
建议团队可以对测试定一个计划，模拟不同的网络环境，硬件条件进行有规律的测试。
第八，分析数据，针对测试的目的，对关键服务的压力测试数据进行分析得知该服务的承受上限在哪里。
对一段时间内有负载波动或者大负载的服务进行数据分析，得出服务改造的方向。
总结
秒杀系统的特点，并发量大，资源有限，操作相对简单，访问的都是热点数据。因此，我们需要把它从业务，技术，数据上做隔离，保证不影响到现有的系统。
因此，架构设计需要分几层来考虑，从客户请求到数据库存储，到最后上线前的压力测试。

文章插图

简易的思维导图送给大家
思考顺序如下，客户端→代理层→应用层→数据库→压力测试：
客户端 90% 静态 HTML+10% 动态 JS;配合 CDN 做好缓存工作。
接入层专注于过滤和限流。
应用层利用缓存+队列+分布式处理好订单。
做好数据的预估，隔离，合并。
上线之前记得进行压力测试。
作者：崔皓
简介：十六年开发和架构经验，曾担任过惠普武汉交付中心技术专家，需求分析师，项目经理，后在创业公司担任技术/产品经理。善于学习，乐于分享。目前专注于技术架构与研发管理。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】

【这一次，彻底弄懂“秒杀系统”】