Redis消息队列和KafKa优劣对比

Redis作为消息队列升级为KafKa记录

项目当中运营人员发送指定匹配用户(最高用户量几十万的级别)特定的消息,所以这块是确确实实需要使用专业级别的消息队列中间件的,但是可能由于当时开发的各种历史原因导致使用了Redis的队列结构来作为消息队里lpush,blpop等命令,项目开发进展到现在,用户量不断增大,包括不同的消息继承进来,包括举报反馈,小纸条(用户间消息发送),活动奖励通知,等等一些不同的消息进来以后,Redis可能会变得不那么可靠.

Redis作为消息队列

Redis的pub-sub模式非常像西式快餐一样,快产快消,全都是因为Redis是使用内存来做存取,所有你生产的消息立马会被消费者一次性全部处理掉,并且没有留下任何痕迹, 同时因为内存总是宝贵的,所以内存上会有限制,当生产者以及消费者上来的时候也会对redis的效率,还有Redis在处理发布和消费big size(10K+的文件)的数据的时候会表现出无法忍受的缓慢

如果有以下场景可以考虑使用Redis作为消息队列

1. 如果你的需求是快产快消的即时消费场景,并且生产的消息立即被消费者消费掉
2. 如果速度是你十分看重的,比如慢了一秒好几千万这种
3. 如果允许出现消息丢失的场景
4. 如果你不需要系统保存你发送过的消息,做到来无影去无踪
5. 需要处理的数据量并不是那么巨大

KafKa作为消息队列

KafKa的设计精妙,支持分布式,高可用的部署,并且对一个大的队列采用分成多个Partition(分区),来提高消息入队的吞吐量,分而治之的思想. 并且消费的时候支持group的概念,能够支持多个客户端消费同个队列,并且一个group中可以增加Consumer的数量来扩展消费的处理量.

KafKa不受生产者数量的影响,因为吞吐量足够支撑,即使在廉价的单机服务器上也可以有10万每秒的消息传输量,并且消费者是想什么时候消费都可以,消息它就在那里,十分灵活,不用担心来无影去无踪的恐慌.能把消息持久化,并以一定的策略(例如一定时间内删除,或者到达多大容量的时候清空)

当有一下场景的时候你可以考虑使用KafKa作为消息队列

1. 如果你想要稳定的消息队列
2. 如果你想要你发送过的消息可以保留一定的时间,并不是无迹可寻的时候
3. 如果你无法忍受数据的丢失
4. 如果速度不需要那么的快
5. 如果需要处理数据量巨大的时候