Redis写数据怎么确认成功？其实有几招你得知道才靠谱

当我们往Redis里写入数据,比如用SET命令存一个用户信息，或者用LPUSH命令往队列里加一个任务时，心里可能会嘀咕：这数据真的存进去了吗？尤其是在一些对数据可靠性要求比较高的场景，比如扣库存、发短信这种，要是写失败了却没发现，那麻烦就大了，怎么确认Redis写操作真的成功了，其实有几种不同“段位”的方法，你得根据自己业务的“靠谱”程度来选择。

第一招：最基础的一步——看命令的直接返回值

这是最简单、最直接的一招，几乎所有的Redis写命令，在执行后都会有一个返回值，对于写操作来说，这个返回值本身就是一种确认。

你用SET key value命令，如果成功写入了，Redis会返回一个OK的字符串，你在客户端程序里，只要检查返回值是不是OK就行了，如果是HSET（设置哈希字段），成功的话通常会返回1（表示新增了字段）或0（表示更新了已有字段），哪怕是像DEL（删除）这样的命令，也会返回一个数字告诉你删除了几个键。

这一招的优点是：零成本，非常简单，你写的每一行操作Redis的代码，本来就应该去处理这个返回值，如果连这个返回值都不检查，那就相当于闭着眼睛开车，非常危险，如果返回的不是预期值（比如SET命令返回了一个错误信息），那就能立刻知道这次写入出问题了。

但这一招的缺点是：它只能告诉你命令在Redis服务器端当时是否被正确执行了，它无法应对一些更极端的情况，你的命令确实被服务器接收并执行了，服务器也返回了OK，但这个成功的应答在通过网络传回给你的客户端的路上，网络连接突然断开了，你的客户端没收到这个OK，就会以为写入失败了，但实际上数据已经存在于Redis服务器里了，这种情况虽然不常见，但在不稳定的网络环境下是有可能发生的。

第二招：为了更靠谱——使用事务（Multi/Exec）

当你需要连续执行多个写操作,并且希望它们“同生共死”（要么全部成功，要么全部失败）时，就要用到事务了，Redis的事务是通过MULTI、EXEC命令组合实现的。

你先把一系列命令放在MULTI之后，这些命令会被排队，当你发出EXEC命令时，Redis才会一次性、按顺序执行所有排队命令，执行后，EXEC命令会返回一个数组，里面包含了队列中每个命令的执行结果。

这一招的确认方式就是：检查EXEC命令返回的整个结果数组，如果数组里的每个结果都是你预期的成功返回值（比如一堆OK），那就说明整个事务都成功了，如果事务中某个命令出了错（比如对错误的数据类型进行了操作），那么只有那条命令会失败，但它不会影响事务里其他命令的执行（这一点和数据库的事务不太一样，需要注意），你依然可以通过结果数组清晰地看到哪个成功了，哪个失败了。

事务的主要目的是保证一批操作的原子性执行，避免在操作过程中被其他客户端的命令打断，它在一定程度上提升了写的可靠性，因为你通过一个EXEC的返回值就能确认一批命令的整体执行情况。

第三招：追求极致可靠——结合持久化和WAIT命令

这是最“强迫症”、最靠谱的一招，主要用于那些数据绝对不能丢的场景，它涉及到Redis的持久化机制。

Redis为了把数据保存到硬盘上防止重启后丢失,提供了两种主要的持久化方式：RDB（快照）和AOF（追加写日志），光是把命令写成功还不够，我们可能还需要确认数据已经“安全着陆”，被持久化到硬盘上了。

Redis的持久化通常是异步进行的,也就是说，你收到OK的时候，数据可能还在内存里，还没完全写到磁盘上，如果这时候Redis突然宕机，这部分数据就丢了。

那怎么确认数据已经落盘了呢？这里就要提到WAIT命令了。WAIT命令的设计初衷就是解决这个问题，它的用法是，在你执行完一个写命令（比如SET）之后，紧接着调用WAIT命令。

WAIT命令需要两个参数：一个是从节点（Replica）的数量，另一个是超时时间（毫秒），这个命令会阻塞当前客户端，直到两种条件之一发生：要么，有指定数量的Redis从节点都已经确认复制了这条写命令（这保证了数据在多个副本上的可靠性）；要么，超过了指定的等待时间。

如何用它来确认成功呢？ 社区里的一种实践思路是（参考一些技术博客的分享）：你可以将WAIT命令的从节点数量参数设置为1（如果你有从库的话），甚至设置为0，当设置为0时，WAIT命令的语义就变成了：等待直到之前所有写命令的变更都已经持久化到AOF文件里（具体行为与Redis配置的AOF持久化级别有关，例如配置为appendfsync everysec时，最多等待1秒）。

流程大概是：

1. 执行写命令,比如SET key value。
2. 立即执行WAIT 0 1000（意思是：等待持久化，最多等1秒钟）。
3. 检查WAIT命令的返回值，它会返回一个数字，表示在超时前，有多少个从节点/持久化操作已经确认了写操作，如果返回1（或者大于等于0的数，取决于你的参数和配置），再结合第一步命令的返回值是OK，你就可以非常有信心地认为，这次写入不仅成功了，而且极有可能已经持久化到磁盘了。

需要注意的是，WAIT命令会阻塞客户端，肯定会增加操作的响应时间，所以它是以牺牲性能为代价来换取更高的数据可靠性，一般只在金融交易、关键状态更新等容错率极低的场景下使用。

总结一下

确认Redis写成功,不是一个有唯一答案的问题，而是一个根据业务需求选择合适“保险级别”的过程：

• 普通业务：认真检查每个写命令的直接返回值，这是必须做的基础动作，能解决大部分问题。
• 关联操作：使用事务（Multi/Exec），并检查EXEC的返回数组，确保一批操作的整体状态。
• 核心关键业务：在检查命令返回值的基础上，考虑使用WAIT命令，来确保数据已经复制到从节点或持久化到硬盘，真正做到万无一失，当然代价是性能会下降。

别再只写代码不管返回值了,根据你的业务有多“娇贵”，从上面几招里选一个合适的吧。