这是一个创建于 3471 天前的主题，其中的信息可能已经有所发展或是发生改变。
redis 的发布 /订阅+node 接收的时候，因为接收到数据后要执行多个任务（比如执行 http 请求、存取数据库），导致发布订阅的速度大于接收订阅的速度。并发量过大，比如一秒有上百个订阅进入 redis ， node 这边会实时全部接收么？
要不要加个任务队列，接收到订阅后把任务放任务队列里。。但感觉这样是不是有点冗余， redis 的订阅实际上就已经类似于一个任务队列了？
要不要加个任务队列，接收到订阅后把任务放任务队列里。。但感觉这样是不是有点冗余， redis 的订阅实际上就已经类似于一个任务队列了？
 |
1
Mirana 2016 年 7 月 24 日  1
redis pubsub 是没有持久化的队列，短时间内请求多问题不大，如果并发一直很大 可以考虑在中间加个 kafka 这种带持久化的队列。
|
 |
2
wander2008 2016 年 7 月 25 日 via iPhone
redis 是单线程的
|
 |
3
fatpa 2016 年 7 月 25 日 1
sub 是一个个 listen 的，所以 node 处理慢了就会导致 redis 消息队列堆积，内存占用过多
BTW ，@wander2008 说的单线程跟这事情并没啥关系 |
|
4
wander2008 2016 年 7 月 25 日 via iPhone
@fatpa …。别这么急着下结论哦。只是说明咱思考不是在一个层次。
|
|
6
Mirana 2016 年 8 月 1 日
@phithon 短期的高并发可以这么搞，一直这么高的话是消费者的消费速度跟不上，磁盘很快就被写满了。
这种情况下可以考虑增加消费者，比如起多个实例增加系统的吞吐。 |
|
7
fatpa 2016 年 8 月 17 日
@wander2008 那你思考的层面是？
|
Select Language