系统有向第三方发起post的需求,当前是直接将任务丢给了redis-queue,然后使用异步http处理,但是该方案在并发处理多的时候可能导致资源占用过大,请问各位有没有办法控制,每次同时处理的数量呢?
1.把异步http请求改成同步 2.或者你想要并行,就将原来的单一消息按照n个分组然后投递队列,队列中并行这n个请求然后等待同步结果就行。
😄只能改回去了😄
本来放queue内已经算是异步处理了,在queue内还要再使用异步,频繁的上下文切换也是要资源的,毕竟是IO操作
对, 我按一秒30个请求这样处理,
可以控制一次性读取队列消息的数量,然后将读取出的这些数据并行处理。
队列还是 rabbit kafka 这样的好,可以分channel topic 啥的,redis 很多需要自己去实现,一个人搞难度很大
开16个进程每个进程1s处理两个请求 不就够了嘛 又想马儿跑 又不给吃草 肯定不行的
异步改同步,加大进程数,什么都够了
可以试试协程
协程 不一定有 阻塞快 协程太吃cpu了
1.把异步http请求改成同步
2.或者你想要并行,就将原来的单一消息按照n个分组然后投递队列,队列中并行这n个请求然后等待同步结果就行。
😄只能改回去了😄
本来放queue内已经算是异步处理了,在queue内还要再使用异步,频繁的上下文切换也是要资源的,毕竟是IO操作
对, 我按一秒30个请求这样处理,
可以控制一次性读取队列消息的数量,然后将读取出的这些数据并行处理。
队列还是 rabbit kafka 这样的好,可以分channel topic 啥的,redis 很多需要自己去实现,一个人搞难度很大
开16个进程每个进程1s处理两个请求 不就够了嘛 又想马儿跑 又不给吃草 肯定不行的
异步改同步,加大进程数,什么都够了
可以试试协程
协程 不一定有 阻塞快 协程太吃cpu了