SpringCloud高并发性能优化

1. SpringCloud高并发性能优化

1.1. 前言

当系统的用户量上来，每秒QPS上千后，可能就会导致系统的各种卡顿，超时等情况，这时优化操作不可避免

1.2. 优化步骤

1. 第一步：优化大SQL，对于多表关联的SQL，当单表数据几百上千万行时，执行可能会达到好几秒，对微服务系统来说，我是不建议join多表操作，除非是数据量少的维表，我们可以将一句大SQL拆分成多个过程，逻辑在JVM中完成
2. 第二步：超时时间不要设的过长，一般一个接口的响应时间要控制在200ms以内，超时时间1s就够了，一旦接近或超过1s，就要考虑是否要用，缓存，索引，NoSQL等手段优化下了
3. 第三步：如果设置了1s超时，可能因为网络的抖动，某次请求超过1s，这个时候需要设置合理的超时重试
   
4. 第四步：设置重试，那就要考虑接口幂等性的问题，常见解决方案是建唯一索引，或者通过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之后恢复

参考：
每秒上万并发下的Spring Cloud参数优化实战
微服务架构如何保障双11狂欢下的99.99%高可用