Redis消息到底发没发成功了？成功与否怎么判断啊，搞不清楚！

这个问题问得太好了，可以说是每个刚开始用Redis做消息传递的人都会遇到的一个坎儿，你感觉代码写对了，但心里就是没底：“我这消息，到底算不算发出去了？对面到底收没收到？” 这种感觉就像你发了一条重要的微信，却迟迟看不到那个灰色的“已送达”或者蓝色的“已读”,抓心挠肝的。

咱们得把“成功”拆成两个层面来看，不能混为一谈，这就像寄信：一个是“信成功塞进邮筒”，另一个是“收信人成功收到并回复了你”,这是两码事。

第一个层面：消息成功“塞进”Redis了吗？（来源：Redis官方文档对命令返回值的说明）

这个层面是最直接、最简单的，你用的那个发送消息的命令,它自己就会告诉你成功与否。

• 如果你用的是LPUSH、RPUSH（往列表里塞消息）： 这些命令执行成功后，会返回一个数字，告诉你操作完成后列表里总共有多少个元素，你往一个叫 my_queue 的列表发消息，发之前里面有2个元素，你发一条，它返回3，只要这个数字比你发之前大了，那铁定就是塞进去了，如果出错了，比如网络断了连不上Redis，或者Redis服务器崩了，你的客户端（比如Jedis，Lettuce这些）会直接抛出一个异常，代码会报错，这时候你肯定就知道“发送”这个动作失败了。

• 如果你用的是PUBLISH（发布订阅模式）： 这个命令会返回一个数字，表示有多少个客户端“订阅者”实时在线并接收到了这条消息，如果返回是0，说明消息成功发到了Redis的频道里，但是当前没有任何一个订阅者在听，这算成功吗？从“塞进邮筒”的角度看，算！邮局可不管你写的地址有没有人住，它只负责把信放进对应的邮箱。只要PUBLISH命令没有抛出异常，而是返回了一个数字（哪怕是0），就说明消息已经成功送达Redis服务器并被处理了。

在第一个层面，判断非常简单：看发送命令的返回值或者有没有异常，没有异常，就是成功了，这一步的可靠性，很大程度上取决于你的Redis服务器本身是不是稳定,以及网络好不好。

第二个层面：消费者成功“处理”了吗？（来源：基于Redis特性的通用实践理解）

这才是最让人头疼的地方，也是你疑问的核心，你把消息成功塞进Redis的列表或者频道里，这只是万里长征第一步，你怎么能确定消费者（也就是消息的接收方）一定拿到了消息并且把它处理好了呢？

这里就得看你用的是什么模式了：

1. 发布订阅（PUB/SUB）模式： 这个是“佛系”模式，消息发出去了，就像广播一样，只有当时正在连接的订阅者能收到，如果一个订阅者当时掉线了，那么它永远就错过这条消息了，Redis服务器不会为它保存这条消息，在这种模式下，你几乎无法确认消息是否被“成功处理”，只能知道它被“成功广播”了，它适合那种丢了就丢了也没关系的场景,比如在线人数统计的实时推送。

2. 列表（List）模拟的消息队列（用LPUSH/BRPOP）： 这种模式就实在多了，消息被LPUSH进列表后，会一直待在列表里，直到被某个消费者用RPOP或者BRPOP取走。取走的消息会从列表里删除，这听起来挺靠谱，对吧？但这里有个坑：消费者客户端可能发生这样的情况——它用BRPOP取走了消息，但在实际处理这个消息之前，它自己崩溃了！这下好了，消息已经被从Redis里删除了，但业务逻辑并没有执行，这条消息就彻底“丢失”了。

那怎么解决这个“处理成功”的确认问题呢？

人们想出了很多办法，都不是Redis自带的,而是在使用模式上做文章：

• 可靠队列模式（来源：Redis官方文档模式章节），消费者不用直接删除消息的RPOP，而是先用LRANGE看看消息是啥，等自己的业务代码彻底执行成功后，再手动用LREM命令把这条消息从列表里删掉，这样即使消费者中途崩溃，消息还在列表里，重启后可以重新处理，缺点是可能重复处理（同一个消息被多个消费者看到）,需要你的业务逻辑自己能处理重复。

• 更常用的方法是借用Sorted Set（有序集合）或者Stream数据类型（来源：Redis社区和官方推荐的现代方案），特别是Stream，它是Redis 5.0之后专门为消息流设计的，它有个“消费者组”的概念，消费者从Stream里取走消息后，消息状态是“待处理”，并不会立刻删除，等消费者业务处理完毕，再发送一个特殊的确认命令（XACK），这条消息才会被标记为已处理，如果消费者挂了，超过一定时间没有确认，这条消息就会被重新放回去，给其他消费者处理，这就实现了“至少处理一次”的可靠性。

回到你的问题“Redis消息到底发没发成功了？成功与否怎么判断啊？”

• 判断“发送到Redis”是否成功： 很简单，看你客户端发送命令的返回值或异常,无异常即成功。
• 判断“被消费者处理”是否成功： 很复杂，取决于你用的模式和额外的保障措施，单纯的PUB/SUB很难保证；用List需要自己实现确认机制；用Stream数据类型能提供内置的、更可靠的确认机制。

核心就是，别指望Redis像一些专业的消息队列（如RabbitMQ、Kafka）那样开箱即用地提供完善的消息确认机制，你需要根据业务对可靠性的要求，选择合适的数据类型和设计相应的处理流程，才能搞清楚消息到底“成功”到哪一步了。