SpringCloud高并发性能优化
本文内容纲要：
-1.SpringCloud高并发性能优化
-1.1.前言
-1.2.优化步骤
-1.3.Hystrix参数优化
-1.4.降级操作
1.SpringCloud高并发性能优化
1.1.前言
当系统的用户量上来，每秒QPS上千后，可能就会导致系统的各种卡顿，超时等情况，这时优化操作不可避免
1.2.优化步骤
- 第一步：优化大SQL，对于多表关联的SQL，当单表数据几百上千万行时，执行可能会达到好几秒，对微服务系统来说，我是不建议join多表操作，除非是数据量少的维表，我们可以将一句大SQL拆分成多个过程，逻辑在JVM中完成
- 第二步：超时时间不要设的过长，一般一个接口的响应时间要控制在200ms以内，超时时间1s就够了，一旦接近或超过1s，就要考虑是否要用，缓存，索引，NoSQL等手段优化下了
- 第三步：如果设置了1s超时，可能因为网络的抖动，某次请求超过1s，这个时候需要设置合理的超时重试
- 第四步：设置重试，那就要考虑接口幂等性的问题，常见解决方案是建唯一索引，或者通过redis判断下唯一id，保证接口被多次调用时不重复插入数据
1.3.Hystrix参数优化
- 我们知道Hystrix线程池的大小和超时时间我们都是可以设置的，线上环境，我们需要对这些参数进行调整，该如何调整呢？
- 假设你的系统B，预计QPS是30，每秒请求响应时间是200ms，那么可以算出30*0.2=6，然后再加点缓冲空间，比如4，那么总共就是6+4=10的线程数量，当然这个4你可以自己调整，这是为了防止突然增大的流量给个缓冲的余地
- 当然这个缓存增加的线程数量对设置超时时间是有参考意义的，比如上面我如果设置了10条线程，此时的超时时间该设置多少？并不是越多越好哦，应该是这么算：10/30=0.333，那么也就是在300ms左右，10是线程池数目，30是你预计的QPS。
- 想象下，如果超时时间设为500ms，当很多请求都变为500ms时，也就是10/0.5=20，你的QPS变成了20，那么多余的请求就不会不断堆积，导致线程卡死，线程卡死后的恢复速度会是比较慢的，所以要合理设置线程池和超时时间
1.4.降级操作
对于降级操作，可以举些例子参考
- 比如redis挂了，对查询可以查本地缓存，mysql等
- 对插入操作，数据库挂了，可以尝试写入日志文件，或写入MQ之后恢复
参考：
每秒上万并发下的SpringCloud参数优化实战
微服务架构如何保障双11狂欢下的99.99%高可用
本文内容总结：1.SpringCloud高并发性能优化，1.1.前言，1.2.优化步骤，1.3.Hystrix参数优化，1.4.降级操作，
原文链接：https://www.cnblogs.com/sky-chen/p/11358280.html