![]() | 1 jiangjz 2018-08-18 22:40:03 +08:00 via Android ![]() for 循环? |
![]() | 3 gejun123456 2018-08-18 22:42:23 +08:00 via iPhone 多线程同步调用呗 |
![]() | 4 vela 2018-08-18 22:43:25 +08:00 让「别的同事」努努力? |
5 notreami 2018-08-18 22:50:10 +08:00 丢数据库里,让 别的同事,自己取数据,自己处理。 |
![]() | 6 wdlth 2018-08-18 22:55:31 +08:00 可以试试生产者消费者模式 |
![]() | 7 jason19659 2018-08-18 22:56:32 +08:00 via Android 分组多次请求 |
8 livepps 2018-08-18 23:03:59 +08:00 via Android ![]() 要处理的数据,放到任务队列中,每次执行 300 个。 可以定时检查当前在执行的数量,不足 300 个,就执行新的任务;也可以做回调,就这样每次执行 300 个,直到任务队列为空 |
10 billlee 2018-08-18 23:06:18 +08:00 异步请求限制 on-the-fly 的数量?简单做的话用信号量就可以了吧 |
![]() | 11 BBCCBB 2018-08-18 23:31:36 +08:00 你甩在 mq 里,他慢慢消费? |
12 veightz 2018-08-18 23:35:39 +08:00 via Android 换我我选 mq |
![]() | 13 dengtongcai 2018-08-19 01:04:53 +08:00 via Android 消息 mq 吧,消费整个多线程,速度很快 |
![]() | 14 metrxqin 2018-08-19 01:08:38 +08:00 能不能详细说明每次只能处理 300 个什么意思? RPC 调用次数单位时间内不超过 300 次? 如果是这样瓶颈在哪里? 还有就是 RPC 提供了什么功能? |
15 night98 2018-08-19 04:42:28 +08:00 via Android 线程池就行了 |
16 bobuick 2018-08-19 08:04:43 +08:00 300w 数据,你场景应该不是 c 端用户的请求吧。 更像是 OTAP 场景了。你们可能应该要改改这架构设计了。 |
17 lihongjie0209 2018-08-19 09:27:54 +08:00 ![]() @ngx4ss #2 多了 timeout 意味着你同事的接口的处理能力可能就是 1000 左右, 你用多线程提交那就是 DDOS 攻击了 |
![]() | 18 mkeith 2018-08-19 10:14:11 +08:00 via iPhone 你是怎么堆积到 300W 条数据的呢 |
19 Kyle18Tang 2018-08-19 10:27:31 +08:00 @metrxqin 估计是处理了 300 个以后,时间就差不多超时了 |
![]() | 20 misaka19000 2018-08-19 10:44:04 +08:00 via Android ![]() 一次能处理 300 个,假如说你每一个请求需要 1 秒钟,我算了一下,把 300 万个处理完,只不过是用两个小时而已,这种时候你使用并发是没有用的,因为这个瓶颈在提供方那边,你没有办法进行处理 |
![]() | 21 xuanbg 2018-08-19 13:30:31 +08:00 这种情况,最好的办法就是你丢队列里面,他去慢慢消费。但总感觉你说的 300 万和 300 不是一个概念的东西 |
![]() | 22 ysweics 2018-08-19 13:54:25 +08:00 ![]() 你这边瞬间 300W 的数据请求过来,然后 rpc 调用处理,这肯定不行呀,如果真的瞬间 300W 的数据过来,rpc 调用不能处理,就只能像楼上说的,用 mq,然后慢慢消费,但是我总感觉你 300W 的说法有问题,最好在你这边把这 300W 的数据给处理一下,一般很少一下子有这么大的数据,提供方的数据太大了 |
![]() | 24 sdushn 2018-08-19 17:46:54 +08:00 via Android 听描述感觉 mq 可以解决啊,你放进去他自己慢慢取就是了,我之前也遇到过类似的问题,就是用 mq 搞定 |
![]() | 25 ysweics 2018-08-19 19:08:50 +08:00 @ngx4ss 那你完全可以分批次处理,从 mongo 里面取的时候就一次少取一点,然后调用 rpc,感觉最好的办法还是 mq,然后多个生产者发送,多个消费者消费,这样并行处理,速度快些 |
26 teek 2018-08-19 21:06:25 +08:00 塞 redis ? 300w 不多的。 |
27 biaoliruyi 2018-08-20 09:59:22 +08:00 spring 的 ApplicationEvent 异步事件 分页读再去请求 rpc |
![]() | 28 cion 2018-08-20 12:59:21 +08:00 就是生产者消费者的问题,消费太慢肯定需要一个缓冲区的,缓存,mq,数据库随便选。 |