本文的作用：学习秒杀场景下压测计划，具体执行暂未执行。
压测内容
根据秒杀活动的业务图， 分析需要压测的接口：
- 秒杀商品详情页
- 商品静态信息
- 动态判断：是否可以点击下单：库存量、是否预约
- 结算页（确定下单接口）【暂未压测这个】
- 静态信息
- 验证码
- 提交订单接口
在这⾥后端订单服务通过MQ异步完成数据库中库存的扣减和订单的⽣成
压测步骤
1. 商品详情页
1.1 基准压测
秒杀系统redis缓存
主从节点做压测，先修改重要配置项
⽇志备份采⽤appendonly
appendonly yes
⽇志刷盘设置为每秒刷盘 --有些压测环境会配置为不刷盘，这样可以提升压测性能
appendfsync everysec
压测脚本
-- 主节点
-- 库存扣减，需要读写主节点， 压测主节点
-- 100并发（订单服务扣减库存） 20W的get set操作 测试的字节大小设置为8个字节
/usr/local/redis-6.2.7/src/redis-benchmark -c 100 -n 200000 -t get,set -d 8
-- 从节点-- 从节点主要负责同步秒杀库存数据。其作⽤主要是供 OpenResty 读取库存⽤，⽽OpenResty 我们配置的是开启7 个⼯作进程，加上主进程，⼀共是 8 个进程（OpenResty 读取库存）。
/usr/local/redis-6.2.7/src/redis-benchmark -c 8 -n 200000 -t get -d 8
秒杀系统Nginx静态网页
品详情⻚处理是分为两个步骤，
- ⾸先在秒杀开始时，通过 Freemark ⽣成商品对应的静态详情⻚，放到 OpenResty 当中。
- 然后秒杀过程中，客户每次访问详情⻚，都会在 OpenResty 中直接通过lua脚本访问 Redis，实时获取商品库存。
尝试访问⼀个秒杀商品的详情⻚：http://192.168.65.28/seckill_3_29.html 。使⽤ab，模拟 200 个线程发送 30000 个请求。（这个页面去掉了redis获取库存的逻辑，只是个静态页面）
-- 200个线程 30000个请求
root@192-168-65-190 src# ab -c 200 -n 30000 http://192.168.65.28/seckill_3_29.html
1.2 秒杀业务压测
秒杀商品详情页
在Nginx静态网页的基础上，增加了lua脚本访问redis获取库存的逻辑。
root@192-168-65-190 src# ab -c 200 -n 100000 http://192.168.65.28/product?
flashPromotionId=3\&promotionProductId=29\&memberId=462245
2. 秒杀下单接口
该接⼝整体的业务逻辑分为两个部分，
- ⾸先是从缓存中进⾏库存扣减，
- 然后异步发送消息到 MQ，完成下单操作。
在压测时，针对两个部分分别进⾏测试。
2.1 基准压测
MQ生产者基准测试，只需要将消息发送的RocketMq即可。
-- 使用rocketmq提供的压测benchmark的方式进行压测
root@192-168-65-164 benchmark# pwd
/app/rocketmq/rocketmq-all-4.9.5-bin-release/benchmark
root@192-168-65-164 benchmark# ./producer.sh -n rocketmq1:9876
如果性能比较低，可能是给rocketMq分配的内存不够，或者部署rocketmq的服务器还有其他的服务在跑。
2.2 秒杀业务压测
root@192-168-65-190 \~# ab -c 1000 -n 10000 -p "params" -T "application/json" -H
"Content-Type: application/json" -H "memberId: 1"