1
pota 360 天前
这压力不是在外部接口吗?
|
3
burymme11 360 天前 1
5 秒完成 7000 次 API 调用,一次完整的请求分配的时间 1ms 都不到,你确定这个设计合理?如果真要这么设计,那你首要任务应该是如何混进对方的机房。
|
4
vacuitym 360 天前
弄个大点的线程池去跑。不过对方的 api 只给你使用吗,你这个对他们的压力可不低
|
5
sdhjl2000 360 天前
使用 redis
|
8
FONG2 OP |
9
ihuotui 360 天前
计算每个环节的延时,tps ,然后合理取舍 cap
|
10
stinkytofu 360 天前
这根本就不是高并发, 而且你 5s 内也不可能完成 7000 个用户的刷新, 要么你这边延长时间, 要么让接口改成批量用户刷新
|
11
buliugu 360 天前
java 的话可以考虑一下 Quasar ,直接起 7k 协程干碎丫的(逃
|
12
litchinn 360 天前
感觉这不是虚拟线程的典型使用场景吗
|
13
lsk569937453 360 天前 via Android
假设外部接口可以支持的并发没有上限,接口调用耗时 10ms 以内。假设更新用户信息到数据库(缓存)的耗时在 5ms 以内。
1.方案一: xx-job 配置定时任务 5 秒一次,单机在 5 秒发起 7000 次请求,并且更新信息到数据库(缓存)。 缺点:单机一秒内要完成 1400 次网络请求,用最新的 java 的虚线程还是有压力的。用户量增加的时候无法横向扩展机器,只能继续优化代码。 2.方案二: 使用 zk/etcd/redis 等工具,将所有在线的机器注册到一个节点上,每 5 秒定时启动时去该节点上拉取所有在线的机器信息,根据本机器的位置来均分任务。如果 10 台机器在线,每台机器则需要均分 700 个用户,然后发起请求去更新用户的信息。 优点:可以横向扩展机器,理论上机器越多,可发起的请求数越多,方便用户增加后,直接加机器即可。 缺点:多个机器的当前运行定时任务怎么保证是一个批次的(机器时间不一致的情况需要考虑)? |
14
lsk569937453 360 天前 via Android
顺便补充下,非必要,不重试。你都 5 秒去更新一次了,频率非常高,失败后不需要重试。
|
15
night98 359 天前
你这个五秒是怎么规定的,我觉得完全可以把 7000 个用户平摊到五秒内分别请求,这样每秒只需要 1400 个用户同步,算你起一百个线程,那么同时只需要处理十四个用户的发起请求,相对来说就简单多了,我觉得你还是问问清楚为什么要这么做吧。
|