redis - 如何在避免竞争条件的同时实现相当于 "unique index"的 Redis？

Question

我正在尝试使用 Redis 作为持久存储。我想将用户存储在 Redis 中，但我希望用户 ID 以及用户电子邮件地址是“唯一的”。

这是我所在的地方:

MULTI
SET users:1 "<user encoded as JSON>"
HSET users-indexes:email user-email@gmail.com 1
EXEC

我使用事务是因为我不希望数据库在 Redis 崩溃时最终处于无效状态。

目前，这只会默默地覆盖现有值。如果电子邮件地址已存在于哈希中，我需要交易失败/回滚。

我可以使用 HSETNX 来防止索引被覆盖，但是此时用户对象已经被覆盖了。我可以提前检查电子邮件地址是否存在于索引中，但那样我就会与其他客户发生争用情况。

我可以向我的应用程序添加写锁，只要唯一的 Redis 客户端是我的应用程序的单个实例，这就可以解决我的问题，否则仍然会出现竞争条件。

在我的场景中，一个非常完美的解决方案是在创建用户时临时锁定 Redis 数据库。很少创建用户，因此不会对性能产生重大影响。但这似乎是不可能的。

我是否缺少一个简单的解决方案？

Answer 1

一种方法可能是:

• 用于存储电子邮件的 SET(用户:电子邮件)
• 一个 HASH (user:data) 添加用户 id 索引的用户对象

在执行事务 (EXEC) 之前，从应用程序中运行 SADD user:email user-email 命令，如果它返回 0，则电子邮件之前已经存在，因此您停止保存用户。如果它返回 1，用户不存在，那么你运行 HGET user:data user-id 命令，如果它返回 NULL，用户不存在，那么你可以执行事务，否则你停止保存当前用户，然后运行:

MULTI
SADD user:email user-email
HSET user:data user-id "<user encoded as JSON>"
EXEC

如果你真的为每个用户保留一个SET，你只需要将包含所有用户的HASH更改为每个用户的一个SET。但我建议您使用由用户 ID 索引的 HASH，这样您就可以将所有用户保存在一个 Redis 结构中，并且当您必须查找用户时，Redis 将管理更少的键。

无论如何，基本上，这里的想法是使用以前的查询来了解电子邮件是否已经存在。

使用先前查询的主要原因之一是因为 Redis 中的事务 (EXEC) 与我们所知的数据库事务不相似，没有回滚，如果事务中的一个命令失败则没有回滚，事务继续执行下一个命令，直到它完成处理所有命令。好消息是，事务会为每个命令返回一个包含所有返回值的数组。

这里有一篇关于为什么无法回滚 Redis 上的事务的清晰文章:http://openmymind.net/You-Cant-Rollback-Redis-Transaction/

我建议您阅读 Redis 文档中的事务主题 https://redis.io/topics/transactions了解 Redis 在运行事务后如何返回数据