消息推送的可靠性

redis 消息推送(基于分布式 pub/sub)多用于实时性较高的消息推送,并不保证可靠。其他的mq和kafka保证可靠但有一些延迟(非实时系统没有保证延迟)。redis-pub/sub断电就清空,而使用redis-list作为消息推送虽然有持久化,但是又太弱智,也并非完全可靠不会丢。

Kakfa 保证的可靠性,但是会有一定的延迟

订阅功能

Redis 发布订阅可以表示不同的 topic 外,并不支持分组功能

Kafka 中发布一个内容,多个订阅者可以进行分组,同一个组里只有一个订阅者会收到该消息,这样可以用作负载均衡。

场景(redis并不能实现这种场景):
kafka 中发布:topic = “帖子” data=”文章1” 这个消息,后面有一百台服务器每台服务器都是一个订阅者,都订阅了这个 topic,但是他们可能分为三组,A组50台,用来真的做发布文章,A组50台里所有 subscriber 都订阅了这个topic。由于在同一组,这条消息 (topic=”帖子”, data=”文章1”)只会被A组里面一台当前空闲的机器收到。而B组25台服务器用于统计,C组25台服务器用于存档备份,每组只有一台会收到。用不同的组来决定每条消息要抄送出多少分去,用同组内哪些订阅者忙,哪些订阅者空闲来决定消息会被分到哪台服务器去处理,生产者消费者模型嘛。

伦理问题(瞎扯:)

如果是仅仅redis就可以实现这些功能,那干嘛还要Kafka呢?哈哈哈。正是因为其中的不足,才有专业方向的,如 key - value 也可以用文件来,但正是由于其io的性能问题,redis应运而生,也正是因为redis的消息推送不能满足需求,才会有更专业的消息系统。哈哈哈。术业有专攻。