当前位置: 首页 > 新闻动态
高并发处理及高并发后限流的一些问题总结
时间:2022-12-09

最近还是有客户陆续问到高并发的解决方案的问题, 总体来说高并发是一种表现, 对于每个项目每个程序的处理方式都是不同的, 不能一概而论的说一种方法就能解决所有的高并发问题. 高并发的问题从根本上讲也可以说是成本的问题, 说白了就是用最少的钱接最多的客. 艾思软件结合最近解决的客户问题, 总结了以下几条常规思路, 让不懂这方面的客户有个大体认识.

 

1. 限流方式为限流接口即可:

因为http请求是无状态的一次请求完成后服务器会自动释放资源即使用户一直停在小程序的某一界面也不会对服务器造成压力所以只要在后台统计所有接口在某一时间内访问的数量即可

 

2. 统计多少数量时进行限流:

某一时间内统计多少数量开始限流这个需要对服务器的有代表性的频繁访问的接口(如首页的接口产品列表的接口产品详情的接口产品下单的一系列接口)进行压力测试设置的值比这个压力结果稍小.

 

3. 高并发优化的建议:

服务器的高并发的瓶颈主要体现在5个方面数据库带宽, CPU, 内存硬盘优化高并发主要是在这些方面进行平衡每一部分都充分利用以提高并发量在以往的经验当中数据库的读写是最关键的地方所以优化高并发最关键的地方是减少数据库的读写.

写缓存是压力给内存(radis)和硬盘(filecache)是最有效的方法如上面提到的接口中首页接口产品列表产品详情基本上数据变化较小可以直接写到硬盘缓存中当后台数据有变化时清除缓存前端有访问时重新生成缓存即可.

CPU优化只能是逻辑代码上的优化, 除有严重的代码逻辑编写不合理, 一般来说可优化程度不高而且在以往的经验中服务器堵塞时CPU占用量并不高除非某一接口单独访问时就明显卡顿然后去做代码优化否则如果出现CPU占到80%左右时就只能硬件升级CPU.

带宽优化就是把类似视频图片, JS/CSS(小程序不需要考虑)单独放OSS咱们的系统本身也是如此所以也没有太多可优化的地方.

综上所述在做高并发压力测试时要统计以上5种资源的利用情况根据实际情况做分析进行优化高并发优化没有统一的优化标准主要思想就是把数据库读写压力缓存到内存或硬盘.

 

4. 接口访问数量的如何统计:

在统计时有两个方案一个是识别用户一个是不识别用户.

两种方式都需要用到radis, 数据库两个键值对一个是用户IDtoken, 一个是访问时间新登录用户访问任何接口写入用户的ID及访问时间用户再次访问接口更新用户的访问时间即可每新进一个用户统计数量加1, 当超过某一并发值时(压力测试的并发值), 统计某一时间(10)"在线的"用户数量如果在线用户数量也大于预设值新进用户再访问接口,  直接返回排队信息不写入Radis. 在线的老用户可以正常访问接口有新请求时再次统计当统计结果低于预设值时新用户可以正常访问新用户访问时在线人数再添加超过之后再循环统计... 这种方案的好处是确保老用户能一直在线完成一个正常流程如定单流程需要好几步不至于正在下定单过程中不能访问接口当然如果定单流程中停顿10秒还是会被视为新用户这一方案的缺点是如果已经在线的用户频繁访问接口依然有风险超过服务器的极限并发量.

不识别用户方案只有一个键值:接口访问时间每新进一个访问写入一条记录同时统计一定时间内(接口平均正常返应时间)的访问数量如果也超过预设值(测试的并发量略小), 新进访问直接返回排队信息不写入数据删除旧的访问记录(超过接口平均反应时间的记录), 新进请求触发统计直到统计结果低于预设值为止如果没有超过预设值写入记录删除旧的访问时间正常访问优点时统计效率会更高限流效果和实时性更好缺点是同一用户在购买过程中会出现排队消息等待的情况

 

5. 注意:

以上两种方式都受radis并发量限制同时也受带宽和其它硬件的最高并发量如果并发量实在太大以上方案不能解决解决的办法只能添加硬件做分布式等

0.496386s