与专业的消息队列对比
其实，一个专业的消息队列，必须要做到两大块：
1.消息不丢
2.消息可堆积
前面我们讨论的重点，很大篇幅围绕的是第一点展开的。
这里我们换个角度，从一个消息队列的「使用模型」来分析一下，怎么做，才能保证数据不丢？
使用一个消息队列，其实就分为三大块：生产者、队列中间件、消费者。
消息是否会发生丢失，其重点也就在于以下 3 个环节：
1.生产者会不会丢消息？
2.消费者会不会丢消息？
3.队列中间件会不会丢消息？
1) 生产者会不会丢消息？
当生产者在发布消息时，可能发生以下异常情况：
1.消息没发出去：网络故障或其它问题导致发布失败，中间件直接返回失败
2.不确定是否发布成功：网络问题导致发布超时，可能数据已发送成功，但读取响应结果超时了
如果是情况 1，消息根本没发出去，那么重新发一次就好了。
如果是情况 2，生产者没办法知道消息到底有没有发成功？所以，为了避免消息丢失，它也只能继续重试，直到发布成功为止。
生产者一般会设定一个最大重试次数，超过上限依旧失败，需要记录日志报警处理。
也就是说，生产者为了避免消息丢失，只能采用失败重试的方式来处理。
但发现没有？这也意味着消息可能会重复发送。
是的，在使用消息队列时，要保证消息不丢，宁可重发，也不能丢弃。
那消费者这边，就需要多做一些逻辑了。
对于敏感业务，当消费者收到重复数据数据时，要设计幂等逻辑，保证业务的正确性。
从这个角度来看，生产者会不会丢消息，取决于生产者对于异常情况的处理是否合理。
所以，无论是 Redis 还是专业的队列中间件，生产者在这一点上都是可以保证消息不丢的。
2) 消费者会不会丢消息？
这种情况就是我们前面提到的，消费者拿到消息后，还没处理完成，就异常宕机了，那消费者还能否重新消费失败的消息？
要解决这个问题，消费者在处理完消息后，必须「告知」队列中间件，队列中间件才会把标记已处理，否则仍旧把这些数据发给消费者。
这种方案需要消费者和中间件互相配合，才能保证消费者这一侧的消息不丢。
无论是 Redis 的 Stream，还是专业的队列中间件，例如 RabbitMQ、Kafka，其实都是这么做的。
所以，从这个角度来看，Redis 也是合格的。
3) 队列中间件会不会丢消息？
前面 2 个问题都比较好处理，只要客户端和服务端配合好，就能保证生产端、消费端都不丢消息。
但是，如果队列中间件本身就不可靠呢？
毕竟生产者和消费这都依赖它，如果它不可靠，那么生产者和消费者无论怎么做，都无法保证数据不丢。
在这个方面，Redis 其实没有达到要求。
Redis 在以下 2 个场景下，都会导致数据丢失。
1.AOF 持久化配置为每秒写盘，但这个写盘过程是异步的，Redis 宕机时会存在数据丢失的可能
2.主从复制也是异步的，主从切换时，也存在丢失数据的可能（从库还未同步完成主库发来的数据，就被提成主库）
基于以上原因我们可以看到，Redis 本身的无法保证严格的数据完整性。
所以，如果把 Redis 当做消息队列，在这方面是有可能导致数据丢失的。
再来看那些专业的消息队列中间件是如何解决这个问题的？
像 RabbitMQ 或 Kafka 这类专业的队列中间件，在使用时，一般是部署一个集群，生产者在发布消息时，队列中间件通常会写「多个节点」，以此保证消息的完整性。这样一来，即便其中一个节点挂了，也能保证集群的数据不丢失。
也正因为如此，RabbitMQ、Kafka在设计时也更复杂。毕竟，它们是专门针对队列场景设计的。
但 Redis 的定位则不同，它的定位更多是当作缓存来用，它们两者在这个方面肯定是存在差异的。
最后，我们来看消息积压怎么办？
4) 消息积压怎么办？
因为 Redis 的数据都存储在内存中，这就意味着一旦发生消息积压，则会导致 Redis 的内存持续增长，如果超过机器内存上限，就会面临被 OOM 的风险。
所以，Redis 的 Stream 提供了可以指定队列最大长度的功能，就是为了避免这种情况发生。
但 Kafka、RabbitMQ 这类消息队列就不一样了，它们的数据都会存储在磁盘上，磁盘的成本要比内存小得多，当消息积压时，无非就是多占用一些磁盘空间，相比于内存，在面对积压时也会更加「坦然」。
综上，我们可以看到，把 Redis 当作队列来使用时，始终面临的 2 个问题：
1.Redis 本身可能会丢数据
2.面对消息积压，Redis 内存资源紧张
到这里，Redis 是否可以用作队列，我想这个答案你应该会比较清晰了。
如果你的业务场景足够简单，对于数据丢失不敏感，而且消息积压概率比较小的情况下，把 Redis 当作队列是完全可以的。
而且，Redis 相比于 Kafka、RabbitMQ，部署和运维也更加轻量。
如果你的业务场景对于数据丢失非常敏感，而且写入量非常大，消息积压时会占用很多的机器资源，那么我建议你使用专业的消息队列中间件。
总结
好了，总结一下。这篇文章我们从「Redis 能否用作队列」这个角度出发，介绍了 List、Pub/Sub、Stream 在做队列的使用方式，以及它们各自的优劣。
之后又把 Redis 和专业的消息队列中间件做对比，发现 Redis 的不足之处。
最后，我们得出 Redis 做队列的合适场景。
这里我也列了一个表格，总结了它们各自的优缺点。
后记
最后，我想和你再聊一聊关于「技术方案选型」的问题。
你应该也看到了，这篇文章虽然始于 Redis，但并不止于 Redis。
我们在分析 Redis 细节时，一直在提出问题，然后寻找更好的解决方案，在文章最后，又聊到一个专业的消息队列应该怎么做。
其实，我们在讨论技术选型时，就是一个关于如何取舍的问题。
而这里我想传达给你的信息是，在面对技术选型时，不要不经过思考就觉得哪个方案好，哪个方案不好。
你需要根据具体场景具体分析，这里我把这个分析过程分为 2 个层面：
1.业务功能角度
2.技术资源角度
这篇文章所讲到的内容，都是以业务功能角度出发做决策的。
但这里的第二点，从技术资源角度出发，其实也很重要。
技术资源的角度是说，你所处的公司环境、技术资源能否匹配这些技术方案。
这个怎么解释呢？
简单来讲，就是你所在的公司、团队，是否有匹配的资源能 hold 住这些技术方案。
我们都知道 Kafka、RabbitMQ 是非常专业的消息中间件，但它们的部署和运维，相比于 Redis 来说，也会更复杂一些。
如果你在一个大公司，公司本身就有优秀的运维团队，那么使用这些中间件肯定没问题，因为有足够优秀的人能 hold 住这些中间件，公司也会投入人力和时间在这个方向上。
但如果你是在一个初创公司，业务正处在快速发展期，暂时没有能 hold 住这些中间件的团队和人，如果贸然使用这些组件，当发生故障时，排查问题也会变得很困难，甚至会阻碍业务的发展。
而这种情形下，如果公司的技术人员对于 Redis 都很熟，综合评估来看，Redis 也基本可以满足业务 90% 的需求，那当下选择 Redis 未必不是一个好的决策。
所以，做技术选型不只是技术问题，还与人、团队、管理、组织结构有关。
也正是因为这些原因，当你在和别人讨论技术选型问题时，你会发现每个公司的做法都不相同。
毕竟每个公司所处的环境和文化不一样，做出的决策当然就会各有差异。
如果你不了解这其中的逻辑，那在做技术选型时，只会趋于表面现象，无法深入到问题根源。
而一旦你理解了这个逻辑，那么你在看待这个问题时，不仅对于技术会有更加深刻认识，对技术资源和人的把握，也会更加清晰。
希望你以后在做技术选型时，能够把这些因素也考虑在内，这对你的技术成长之路也是非常有帮助的。
