兄弟们好，今天是秒杀项目第八天，我上次更新时第五天的时候，断更的原因也并不是因为我这几天都在休息，相反其实我一直都有敲代码。那我简单说一下这几天的进度吧，首先是第六天的时候，我为开通了支付宝支付，但是测试的时候使用沙箱模拟支付的，感兴趣的小伙伴也可以自行去csdn查看相应文章，我看了下，有好多讲的其实都挺好的，因此我自己就不卖弄了。然后第七八天就是压测为主了，同时也一直在根据压测的结果尽可能的优化代码。

那我说一下压测这一块吧，最后得出的结果是这个项目的极限qps大概在1158左右，也就是一秒能最多处理1158个用户请求，秒杀持续三秒的话就能够处理大概3400多个用户请求，想要达到1w+的话就只能加机器了，不过你自身服务器也会有影响，比如你用jmeter或者你自己写java测试脚本对你电脑上的项目进行测试的时候，你的电脑上的cpu不仅会被你的项目抢占，同时也会被你的测试工具抢占，导致你的测试结果会被相应拉低。我说一下优化改动吧，我将redis的操作尽量放在一个lua脚本中，用来减少网络请求的次数，因为你redis处理的时间消耗无论在lua脚本还是外部代码中都是一样的，但是你的网络请求则不一样，lua脚本总共只有一次，但是外部可能有多次，因此这里也是一部分开销。不过我觉得这些对于真正的代码性能优化而言只能算是小头，因为你一次可能也才1ms不到，真正大头的反而是数据库那种几百毫秒的。并且我在秒杀热路径下已经尽可能的避免数据库查询操作，将要进行先行验证的查询数据尽可能的先放在redis中，比如秒杀开始时间，这样能尽可能的优化性能。然后我为了防止redis崩溃，我甚至还加了个布隆过滤器来防止大量不必要的伪造id来进行攻击，不过我觉得redis一般应该不会崩吧，毕竟他就是干这个来防止数据库崩溃的😓。因此我更觉得在这个模块中我的redis是起到一个优化秒杀性能的作用，通过redis优秀的性能来减少数据库的操作次数。然后我还为MQ的异步下单添加了异步功能，怎么说呢，虽然说mq异步下单确实是能提升业务效率，但是他发送消息的时候自己也是要收到broker的回应才能发送消息的，因此我开启了异步化，顺便增加了十五分钟订单没付款自动取消的功能，这一部分就是利用延迟发送。

因此到目前为止，这个项目已经算是完成第一阶段了，后续可能会根据需要持续改动，大家拜拜。