当前位置： 移动技术网 > IT编程>开发语言>Java > SpringCloud高并发性能优化

SpringCloud高并发性能优化

2019年08月15日  | 移动技术网IT编程  | 我要评论

1. springcloud高并发性能优化

1.1. 前言

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

1.2. 优化步骤

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

您可能感兴趣的文章:

如对本文有疑问， 点击进行留言回复！！

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网