消息推送的可靠性

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的消息推送不能满足需求，才会有更专业的消息系统。哈哈哈。术业有专攻。

This blog is under a CC BY-NC-SA 3.0 Unported License
本文链接：https://blog.suixin.kim/2018/05/16/kafka-redis-diff-why/