本文主要是介绍能否把 Redis 当做消息队列来用呢？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
这个问题并不是面试中经常会问到的问题，而是我在平时看一些大牛写的技术文章的时候看到的一个问题，这个问题引发了我强烈的思考，我感觉我想通了这个问题之后，对redis和kafka都有了一个全新的认识，感觉像发现了新大陆这种感觉。这其实是一个泛问题，如果一个人对redis和kafka都很了解，那回答这个问题绝对是侃侃而谈的。我这几天一直在思考这个问题，感觉已经将redis和kafka的这个脑图都给构建出来了。
在我看来，Redis 其实就是一个内存存储系统。我的理解就是 Redis 是一个可以用来存数据的系统，就这么简单。Redis 支持很多种数据结构，我的理解就是你的那些数据可以按照不同的结构存储在 Redis 中。比如 Redis 有 List 这种数据结构，那数据在 Redis 中就很有可能是排成一列这样子存放的。
所以这就引出了一个问题：既然 Redis 支持数据排成一列存放，那 Redis 可不可以用作消息队列呢？我听到最多的消息队列是 activemq、rabbitmq、rocketmq、kafka 这些，我基本没听说过 Redis 消息队列。
假如我们现在有一个最简单的 Redis 内存系统，那这个系统会有什么不足呢？首先 Redis 支持 List 这种数据结构，而 List 的底层实现是链表。按理来说，在头尾操作元素是很方便的事情，用作消息队列天然适配。但是，由于是链表，你在取消息的时候是直接把消息取出来的，取出来后，链表就会删除这个元素。万一现在有很多个消费者都想消费这条消息，本来这条消息是共享的，结果你直接自己消费了，其他消费者消费不了就很难受，而且万一你自己还消费不成功这条消息，想再从队列里取出来再消费一次，已经没机会了，你刚刚已经拿出来了，所以这样子是不行的。
所以后来才有了发布/订阅者模式，这种模式就可以完美的解决上述的问题。
其实，现在的 Redis 是有发布/订阅者模式的，但是其实还是有不足的地方，问题出在哪里？Redis 在关于数据不丢失问题做不到严格的保证。你想想，Redis 保证数据不丢失，也就是我们平时说的 Redis 数据持久化的时候，无非就是用 AOF日志 和 RDB内存快照，这两种方式都不能严格的保证数据不丢失，反而消息队列比如 kafka 这种，就使用 leader-follower 模式来严格的保证数据不丢失，而且 kafka 在生产者那里为了保证数据不丢失也做了处理，甚至在消费者那里，都考虑到关闭offset 这个参数，这种对数据不丢失的严谨性是 Redis 比不了的。
当然，这也很正常，毕竟 Redis其实都不是很在乎数据丢不丢，因为 Redis 用的最多的就是做缓存，丢一点数据其实对整体没有什么大的影响。不仅是保证不了消息不丢，在保证消息不被重复消费，保证消息被有序消费这些点上，Redis 都无能为力。
当然，我这里说的 Redis 是早期的 Redis，现在的 Redis 肯定不是这样子的。比如说在保证数据不丢这点，Redis 现在已经做的很好了，它采用了主从复制+哨兵选举的方式，感觉和 kafka 保证数据不丢的思路是有点相似的。此外，它还用了分片集群，通过分片集群，Redis 就可以轻松的进行横向扩展，处理更大规模的数据了。
上面就是我自己对于这个问题的理解。因为这是一个开放性的问题，所以不同的人都会有自己不同的理解。当然，假如你对 Redis 和 kafka 掌握的越好，那你回答这道题就越能侃侃而谈，甚至通过这道题把你懂得的所有 Redis 和 kafka 的细节都说出来。我觉得我应该多思考这种开放性的问题，研究这种问题感觉是有利于促进对知识点的理解的。这种问题也有利于检测对一个知识点的理解到底掌握到哪种程度。复习的时候，也可以用这个问题当做复习，就是问你这道题，你把你懂的关于 Redis 和 kafka 的所有知识点都讲出来。
这篇关于能否把 Redis 当做消息队列来用呢？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
