V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
FONG2
V2EX  ›  Java

求助,想找一个发起高并发的 demo Java 项目参考一下

  •  
  •   FONG2 · 2023-11-10 17:46:03 +08:00 · 2058 次点击
    这是一个创建于 390 天前的主题,其中的信息可能已经有所发展或是发生改变。
    需求是
    7000 个用户,每 5s 请求外部接口更新一下用户信息,更新用户信息的 API 每次只能查 1 个用户

    关联多线程、调度、失败重试
    15 条回复    2023-11-12 03:22:53 +08:00
    pota
        1
    pota  
       2023-11-10 17:49:35 +08:00
    这压力不是在外部接口吗?
    FONG2
        2
    FONG2  
    OP
       2023-11-10 17:55:30 +08:00   ❤️ 1
    @pota 发起方同样存在吧,收到数据要入库的,要怎么写这个多任务才能满足每秒 1400 次发起请求
    burymme11
        3
    burymme11  
       2023-11-10 18:13:42 +08:00   ❤️ 1
    5 秒完成 7000 次 API 调用,一次完整的请求分配的时间 1ms 都不到,你确定这个设计合理?如果真要这么设计,那你首要任务应该是如何混进对方的机房。
    vacuitym
        4
    vacuitym  
       2023-11-10 18:18:34 +08:00
    弄个大点的线程池去跑。不过对方的 api 只给你使用吗,你这个对他们的压力可不低
    sdhjl2000
        5
    sdhjl2000  
       2023-11-10 19:05:33 +08:00
    使用 redis
    pota
        6
    pota  
       2023-11-10 19:35:01 +08:00
    @FONG2 #2 发起方反而好解决,多几台机器分流就行了。问题是在被调用方。
    FONG2
        7
    FONG2  
    OP
       2023-11-10 19:46:27 +08:00
    @pota 道理我都懂,我就想看看别人怎么写 少走弯路
    FONG2
        8
    FONG2  
    OP
       2023-11-10 19:48:06 +08:00
    @burymme11 我也觉得不合理,但是无能无力
    @vacuitym 对只给我用,并且每一次的调用的信息 对方都是实时计算生成的
    反正我只管我自己,对方压力怎么样 不归我管,到时候 5s load 不完 锅不在我
    ihuotui
        9
    ihuotui  
       2023-11-10 21:07:10 +08:00
    计算每个环节的延时,tps ,然后合理取舍 cap
    stinkytofu
        10
    stinkytofu  
       2023-11-10 21:15:37 +08:00
    这根本就不是高并发, 而且你 5s 内也不可能完成 7000 个用户的刷新, 要么你这边延长时间, 要么让接口改成批量用户刷新
    buliugu
        11
    buliugu  
       2023-11-11 01:57:39 +08:00
    java 的话可以考虑一下 Quasar ,直接起 7k 协程干碎丫的(逃
    litchinn
        12
    litchinn  
       2023-11-11 11:02:49 +08:00
    感觉这不是虚拟线程的典型使用场景吗
    lsk569937453
        13
    lsk569937453  
       2023-11-11 11:04:06 +08:00 via Android
    假设外部接口可以支持的并发没有上限,接口调用耗时 10ms 以内。假设更新用户信息到数据库(缓存)的耗时在 5ms 以内。

    1.方案一:
    xx-job 配置定时任务 5 秒一次,单机在 5 秒发起 7000 次请求,并且更新信息到数据库(缓存)。
    缺点:单机一秒内要完成 1400 次网络请求,用最新的 java 的虚线程还是有压力的。用户量增加的时候无法横向扩展机器,只能继续优化代码。


    2.方案二:
    使用 zk/etcd/redis 等工具,将所有在线的机器注册到一个节点上,每 5 秒定时启动时去该节点上拉取所有在线的机器信息,根据本机器的位置来均分任务。如果 10 台机器在线,每台机器则需要均分 700 个用户,然后发起请求去更新用户的信息。
    优点:可以横向扩展机器,理论上机器越多,可发起的请求数越多,方便用户增加后,直接加机器即可。

    缺点:多个机器的当前运行定时任务怎么保证是一个批次的(机器时间不一致的情况需要考虑)?
    lsk569937453
        14
    lsk569937453  
       2023-11-11 11:06:06 +08:00 via Android
    顺便补充下,非必要,不重试。你都 5 秒去更新一次了,频率非常高,失败后不需要重试。
    night98
        15
    night98  
       2023-11-12 03:22:53 +08:00
    你这个五秒是怎么规定的,我觉得完全可以把 7000 个用户平摊到五秒内分别请求,这样每秒只需要 1400 个用户同步,算你起一百个线程,那么同时只需要处理十四个用户的发起请求,相对来说就简单多了,我觉得你还是问问清楚为什么要这么做吧。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5344 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 03:46 · PVG 11:46 · LAX 19:46 · JFK 22:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.