SpringCloud高并发性能优化

1. SpringCloud高并发性能优化

1.1. 前言

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

1.2. 优化步骤

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

转载于:https://www.cnblogs.com/sky-chen/p/11358280.html

你可能感兴趣的:(SpringCloud高并发性能优化)