这是一个创建于 1573 天前的主题，其中的信息可能已经有所发展或是发生改变。
正常一次一次点击返回时间是 300~700ms, 如果快速一直点击的话，就会卡住然后超时了, 这还是单机我一个人测试的的情况下
里面的操作大改是
1. 业务里面用了大量的同步 db 操作,select/udpate 的比较多
2. 有两个三方 sdk curl 的操作,但是这个耗时还好在 10ms 之内,所以问题还好
分段看了一下执行时间了一下,大多都是 db 的瓶颈好像
 | 1 Finest 2021-08-12 19:44:43 +08:00 via iPhone 并发读写数据库 跟数据库就近部署 |
 | 2 luckyrayyy 2021-08-12 19:59:43 +08:00 多大量？一般同机房的 db，数据库操作都在几毫秒的量级，除非你大量循环不然怎么也到不了几百毫秒。或者是跨城市的远程数据库？ |
 | 3 Kimen 2021-08-12 20:14:46 +08:00 前端也可以用节流或者防抖控制一下点击 |
 | 4 spikie 2021-08-12 20:25:34 +08:00 1. 前端限制点击间隔 3. 后端开线程池异步化处理 4. 增加接口服务器并发线程 |
 | 5 akira 2021-08-12 20:49:11 +08:00 你都说了瓶颈在 db，那就是针对你的 select/update 优化啦 |
 | 6 swim2sun 2021-08-13 07:44:59 +08:00 via iPhone 1.看看能不能并行话 2.优化查询 3.考虑加缓存 |
 | 7 |
 | 8 waitingChou 2021-08-13 17:15:24 +08:00 听起来感觉像是数据库锁竞争，没 SQL 也没啥思路。同一个用户的话做点击频率控制下 看你描述操作的内容不少，追求前端响应体验的话，可以把点击操作成功，改成点击提交成功。 接口只提交操作任务，后台慢慢执行，这个要看业务上能不能接受 |
| 9 qwer666df OP @waitingChou #8 是送礼的逻辑, 所以 sql 操作比较多, 也就不好贴出来了,. 因为是送礼, 所以不能控制频率, 后端这边只能提高性能, 白天看了一圈代码发现, 里面有用到事物, 还有一些方法甚至加上了 synchronize, 下周打算都去掉看看并发吧, 不行再上缓存了 |
Select Language