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

请问 Java 大佬如何处理这种 rpc 调用问题?

  •  
  •   ngx4ss · 2018-08-18 22:38:06 +08:00 · 5009 次点击
    这是一个创建于 2048 天前的主题,其中的信息可能已经有所发展或是发生改变。

    如题,公司用的是 motan /dubbo 之类的 rpc 框架

    • 现在,我这边调用别的同事写的 rpc 接口 但每次只能处理 300 个,我这边数据总共有 300 万个
    • 请问如何多线程异步消耗完这些数据 ? 用 mq 吗? 还是 FutureTask ?
    28 条回复    2018-08-20 12:59:21 +08:00
    jiangjz
        1
    jiangjz  
       2018-08-18 22:40:03 +08:00 via Android   ❤️ 1
    for 循环?
    ngx4ss
        2
    ngx4ss  
    OP
       2018-08-18 22:42:00 +08:00
    @jiangjz #1 不行的 ,一次性调用处理数据太多 就会 timeout 报错了
    gejun123456
        3
    gejun123456  
       2018-08-18 22:42:23 +08:00 via iPhone
    多线程同步调用呗
    boywang004
        4
    boywang004  
       2018-08-18 22:43:25 +08:00
    让「别的同事」努努力?
    notreami
        5
    notreami  
       2018-08-18 22:50:10 +08:00
    丢数据库里,让 别的同事,自己取数据,自己处理。
    wdlth
        6
    wdlth  
       2018-08-18 22:55:31 +08:00
    可以试试生产者消费者模式
    jason19659
        7
    jason19659  
       2018-08-18 22:56:32 +08:00 via Android
    分组多次请求
    livepps
        8
    livepps  
       2018-08-18 23:03:59 +08:00 via Android   ❤️ 1
    要处理的数据,放到任务队列中,每次执行 300 个。
    可以定时检查当前在执行的数量,不足 300 个,就执行新的任务;也可以做回调,就这样每次执行 300 个,直到任务队列为空
    ngx4ss
        9
    ngx4ss  
    OP
       2018-08-18 23:05:58 +08:00
    @livepps #8 请问大佬 任务队列是 blockqueue ?
    billlee
        10
    billlee  
       2018-08-18 23:06:18 +08:00
    异步请求限制 on-the-fly 的数量?简单做的话用信号量就可以了吧
    BBCCBB
        11
    BBCCBB  
       2018-08-18 23:31:36 +08:00
    你甩在 mq 里,他慢慢消费?
    veightz
        12
    veightz  
       2018-08-18 23:35:39 +08:00 via Android
    换我我选 mq
    dengtongcai
        13
    dengtongcai  
       2018-08-19 01:04:53 +08:00 via Android
    消息 mq 吧,消费整个多线程,速度很快
    metrxqin
        14
    metrxqin  
       2018-08-19 01:08:38 +08:00
    能不能详细说明每次只能处理 300 个什么意思? RPC 调用次数单位时间内不超过 300 次? 如果是这样瓶颈在哪里?

    还有就是 RPC 提供了什么功能?
    night98
        15
    night98  
       2018-08-19 04:42:28 +08:00 via Android
    线程池就行了
    bobuick
        16
    bobuick  
       2018-08-19 08:04:43 +08:00
    300w 数据,你场景应该不是 c 端用户的请求吧。
    更像是 OTAP 场景了。你们可能应该要改改这架构设计了。
    lihongjie0209
        17
    lihongjie0209  
       2018-08-19 09:27:54 +08:00   ❤️ 1
    @ngx4ss #2 多了 timeout 意味着你同事的接口的处理能力可能就是 1000 左右, 你用多线程提交那就是 DDOS 攻击了
    mkeith
        18
    mkeith  
       2018-08-19 10:14:11 +08:00 via iPhone
    你是怎么堆积到 300W 条数据的呢
    Kyle18Tang
        19
    Kyle18Tang  
       2018-08-19 10:27:31 +08:00
    @metrxqin 估计是处理了 300 个以后,时间就差不多超时了
    misaka19000
        20
    misaka19000  
       2018-08-19 10:44:04 +08:00 via Android   ❤️ 1
    一次能处理 300 个,假如说你每一个请求需要 1 秒钟,我算了一下,把 300 万个处理完,只不过是用两个小时而已,这种时候你使用并发是没有用的,因为这个瓶颈在提供方那边,你没有办法进行处理
    xuanbg
        21
    xuanbg  
       2018-08-19 13:30:31 +08:00
    这种情况,最好的办法就是你丢队列里面,他去慢慢消费。但总感觉你说的 300 万和 300 不是一个概念的东西
    ysweics
        22
    ysweics  
       2018-08-19 13:54:25 +08:00   ❤️ 1
    你这边瞬间 300W 的数据请求过来,然后 rpc 调用处理,这肯定不行呀,如果真的瞬间 300W 的数据过来,rpc 调用不能处理,就只能像楼上说的,用 mq,然后慢慢消费,但是我总感觉你 300W 的说法有问题,最好在你这边把这 300W 的数据给处理一下,一般很少一下子有这么大的数据,提供方的数据太大了
    ngx4ss
        23
    ngx4ss  
    OP
       2018-08-19 17:17:10 +08:00
    @ysweics #22 这边的 300W 数据是直接查询 mongo 数据库出来的
    sdushn
        24
    sdushn  
       2018-08-19 17:46:54 +08:00 via Android
    听描述感觉 mq 可以解决啊,你放进去他自己慢慢取就是了,我之前也遇到过类似的问题,就是用 mq 搞定
    ysweics
        25
    ysweics  
       2018-08-19 19:08:50 +08:00
    @ngx4ss 那你完全可以分批次处理,从 mongo 里面取的时候就一次少取一点,然后调用 rpc,感觉最好的办法还是 mq,然后多个生产者发送,多个消费者消费,这样并行处理,速度快些
    teek
        26
    teek  
       2018-08-19 21:06:25 +08:00
    塞 redis ? 300w 不多的。
    biaoliruyi
        27
    biaoliruyi  
       2018-08-20 09:59:22 +08:00
    spring 的 ApplicationEvent 异步事件 分页读再去请求 rpc
    cion
        28
    cion  
       2018-08-20 12:59:21 +08:00
    就是生产者消费者的问题,消费太慢肯定需要一个缓冲区的,缓存,mq,数据库随便选。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3265 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 14:03 · PVG 22:03 · LAX 07:03 · JFK 10:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.