redis订阅发布服务的不足

上一篇说到redis 和 icestorm的订阅发布模式， 其中redis 的api很容易使用，性能也非常不错。redis也有一些不足， 比如“单点问题”，如果发布者的消息过多，一台redis-server处理不过来，redis还没支持负载均衡集群，主从配置在“消息过多”情况下还是无能为力，接收消息的压力始终都得在主的压力上面。那么这种情况下我们只能人为的将发布者的消息按照业务拆分，将某些消息发布到另外一台redis server上面去。

 

在icestorm当中有一个icebox，在订阅发布服务中，它的作用跟redis server是一样的。icebox就可以通过负载均衡集群来增加自己的接收消息的能力。

 

如果redis-server的消息分发能力不够，主从配置就能派上用处了。

 

 

如果redis-server的订阅端处理能力不足怎么办？这一点对于redis sever非常危险。因为redis-server会将消息存储在redis server 服务端内存中，如果订阅端的处理始终处理缓慢，那么redis server的内存就会不断变大。