秒杀系统上云，从1342ms提升到138ms

　　小伙伴们好呀，拖拖拉拉的我，终于把秒杀项目部署到云端上去了！
　　这次过程也比较顺利，搭建下RabbitMQ就好了。helminstallrabbitmqbitnamirabbitmqnamespaceprodfconfig。yaml
　　不过我发现，每次都得研究下这个配置文件，真的是头大，而且后面如果要装插件，开启插件这些好像也挺麻烦的，像Redis的布隆过滤器，RabbitMQ的延迟插件等等。
　　而且捣鼓到最后，还得打包成自己的镜像才能好好保存下来
　　越操作越不耐烦，还是写代码省心
　　这个算是我部署在云端的第一个有意义的k8s应用，有点小激动，狠狠地测试下
　　代码基本没啥改动，简单地调整下这些host。
　　顺手将redisson改成了主从，代码中lettuce还没修改。
　　写个Dockerfile部署下。FROMadoptopenjdk：11jrehotspotasbuilderMAINTAINERJav4yeWORKDIRapplicationARGJARFILEtargetseckilldemo。jarCOPY｛JARFILE｝application。jarRUNjavaDjarmodelayertoolsjarapplication。jarextractFROMadoptopenjdk：11jrehotspotWORKDIRapplicationCOPYfrombuilderapplicationdependencies。COPYfrombuilderapplicationspringbootloader。COPYfrombuilderapplicationsnapshotdependencies。COPYfrombuilderapplicationapplication。ENVTZAsiaShanghaiENVJVMOPTSXmx512mXms512mENTRYPOINT〔sh，c，java｛JVMOPTS｝org。springframework。boot。loader。JarLauncher〕
　　单机
　　jmeter测试
　　下面是十次测试结果数据，可以跳到阅读小结内容
　　第一次平均响应是1711ms，50的请求是1808ms，99是2552ms，最小是708ms，最大是2961ms，吞吐量是224。1s。
　　第一次
　　第二次平均响应是400ms，50的请求是394ms，99是1002ms，最小是21ms，最大是1198ms，吞吐量是503。3s。
　　第二次
　　第三次平均响应是337ms，50的请求是311ms，99是791ms，最小是11ms，最大是847ms，吞吐量是557。4s。
　　第三次
　　第四次平均响应是97ms，50的请求是85ms，99是236ms，最小是17ms，最大是365ms，吞吐量是745。2s。
　　第四次
　　第五次平均响应是124ms，50的请求是109ms，99是332ms，最小是11ms，最大是3033ms，吞吐量是248s。
　　第五次
　　第六次平均响应是84ms，50的请求是83ms，99是156ms，最小是14ms，最大是217ms，吞吐量是805s。
　　第六次
　　第七次平均响应是224ms，50的请求是224ms，99是486ms，最小是18ms，最大是565ms，吞吐量是657。5s。
　　第七次
　　第八次平均响应是92ms，50的请求是81ms，99是326ms，最小是9ms，最大是3024ms，吞吐量是250。5s。
　　第八次
　　第九次平均响应是80ms，50的请求是72ms，99是173ms，最小是14ms，最大是396ms，吞吐量是789。9s。
　　第九次
　　第十次平均响应是72ms，50的请求是63ms，99是138ms，最小是12ms，最大是347ms，吞吐量是792。4s。
　　第十次
　　小结
　　第一次这么认真的测试，但是这种测试还不严谨，看网上说要命令行的方式去运行jmeter测试，但是我还是偷个懒，这样和上文测试出来的结果也好有个比较。
　　在上文《写个简易版秒杀系统练练手》中，有下面这份报告
　　当然，上文的这个报告是取最好的那一次，也就是预热JVM后的结果。
　　这次，测试了十次，也是500并发。
　　可以看到第一次请求的数据效果非常差！99的请求要2552ms，这可能就是没预热JVM的情况。
　　第二次，第三次，效果也很差，但是到第四次开始，效果就好起来了99的请求在350ms以下。
　　最好的一次，是第十次，99的请求在138ms。
　　对比上文的结果，从1342ms提升到138ms，硬生生提升了10倍的效率，这要是放在生产环境下，那不得把牛吹坏了
　　当然，从表中还可以发现，这网络抖动还有点大，不知道怎的，这个max突然就卡到3024ms去，严重降低了这个吞吐量。
　　上文也提到过，最大的问题应该是网络开销，毕竟还是用了MQ异步下单，内存标记，Redis预扣库存等手段去优化。
　　现在都部署到k8s上，RabbitMQ，Redis，MySQL都在上面，就不会有这么大的网路开销了。接下来怎么优化呢？
　　目前只有零星的思路，比如吞吐量的话，我可能会尝试下这个reactive的方式，或者将Springboot内嵌的Tomcat换成jetty，undertow试试。
　　代码的话，试试将lettuce也更换成主从模式的看看，再看看API有哪些可以优化的。
　　最主要的，还是这个JVM，下次用VisualVM连上去看看JVM在这期间的变化，看看CPU，内存，等的变化。
　　集群（3个）
　　虽然一直吐槽部署变得麻烦，但是这个点一点就扩容，一下子就变成集群真的太赞了！
　　所以我在上文提到直接用分布式锁就好了，毕竟很难忍住不试下。
　　一下子变成多个消费者，但是好在用了这个分布式锁，避免了重复消费订单的问题。
　　这也很符合我理想中的代码，业务代码就归业务代码好了，微服务那一套能分离的就尽量分离出来，现在靠这个k8s就能实现负载均衡了，确实好方便，当然，不方便的就落到k8s运维人员身上去了，比如负载均衡策略的调整啥的。
　　第一次平均响应是1705ms，50的请求是1795ms，99是3838ms，最小是16ms，最大是4155ms，吞吐量是157。1s。
　　第一次
　　第二次平均响应是587ms，50的请求是529ms，99是2162ms，最小是20ms，最大是2265ms，吞吐量是388。7s。
　　第二次
　　这我就有点纳闷了，怎么还这么慢的！
　　按理说，我这集群是来提高吞吐量的啊！难道是因为我这是假的集群（都在minikube节点上）
　　结果查看容器日志时，发现居然有错
　　把日志下载到本地发现，原来是这个ID重复了
　　之前偷个懒，直接用hutool工具生成了，现在变成集群也不好修改呀。
　　那好吧，先暂时作罢，看来还得把这个分布式ID生成器搭建下。
　　那咱们下文见，下文就来看看单机下JVM的变化先吧，over！
　　喜欢的小伙伴记得关注下哦，全网同名