这篇文章给大家分享的是有关redis和kafka的区别有哪些的内容。小编觉得挺实用的，因此分享给大家做个参考。一起跟随小编过来看看吧。
站在用户的角度思考问题，与客户深入沟通，找到靖远网站设计与靖远网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：网站设计制作、网站建设、企业官网、英文网站、手机端网站、网站推广、国际域名空间、虚拟主机、企业邮箱。业务覆盖靖远地区。
Kafka与Redis PUB/SUB之间较大的区别在于Kafka是一个完整的系统，而Redis PUB/SUB只是一个套件(utility)——没有冒犯Redis的意思，毕竟它的主要功能并不是PUB/SUB。
redis 消息推送（基于分布式 pub/sub）多用于实时性较高的消息推送，并不保证可靠。
其他的mq和kafka保证可靠但有一些延迟（非实时系统没有保证延迟）。redis-pub/sub断电就清空，而使用redis-list作为消息推送虽然有持久化，但是又太弱智，也并非完全可靠不会丢。
另外一点，redis 发布订阅除了表示不同的 topic 外，并不支持分组，比如kafka中发布一个东西，多个订阅者可以分组，同一个组里只有一个订阅者会收到该消息，这样可以用作负载均衡。
Redis，它首先是一个内存数据库，其提供的PUB/SUB功能把消息保存在内存中(基于channel)，因此如果你的消息的持久性需求并不高且后端应用的消费能力超强的话，使用Redis PUB/SUB是比较合适的使用场景。比如官网说提供的一个网络聊天室的例子：模拟IRC，因为channel就是IRC中的服务器。用户发起连接，发布消息到channel，接收其他用户的消息。这些对于持久性的要求并不高，使用Redis PUB/SUB来做足矣。
而Kafka是一个完整的系统，它提供了一个高吞吐量、分布式的提交日志(由于提供了Kafka Connect和Kafka Streams，目前Kafka官网已经将自己修正为一个分布式的流式处理平台，这里也可以看出Kafka的野心：-)。除了p2p的消息队列，它当然提供PUB/SUB方式的消息模型。而且，Kafka默认提供了消息的持久化，确保消息的不丢失性(至少是大部分情况下)。另外，由于消费元数据是保存在consumer端的，所以对于消费而言consumer被赋予极大的自由度。consumer可以顺序地消费消息，也可以重新消费之前处理过的消息。这些都是Redis PUB/SUB无法做到的。
Redis PUB/SUB使用场景：
1. 消息持久性需求不高
2. 吞吐量要求不高
3. 可以忍受数据丢失
4. 数据量不大
Kafka使用场景：
上面以外的其他场景：）
1. 高可靠性
2. 高吞吐量
3. 持久性高
4. 多样化的消费处理模型
感谢各位的阅读！关于redis和kafka的区别有哪些就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到吧！
