Redis - 具有可能过期的键模式的最大记录数

Question

假设我们是一家销售 T 恤的在线卖家。我们只剩下 1 件 T 恤要卖了。不完整的订单被放置在 redis 中，它们会在 1 小时后自动过期。我们不能卖出超过剩余的 1 件 T 恤，所以我们必须将 redis 中的挂单键的数量限制为 1。如果订单完成，redis 中的临时订单将被删除，并将完成的订单写入实现数据库。

如果有客户来，我们必须检查还剩多少库存(在我们的例子中，它是 1 件 T 恤)以及 redis 中已经有多少待处理订单(过期前)，如果没有可用的要出售的库存，如果我们没有足够的库存(在我们的假设示例中为 1 件 T 恤)，我们将不允许订购 T 恤。

这是我的尝试(我是第一次使用 redis - 主要是因为 redis 可以自动使我们在任何数据库中都不需要的挂起键过期)。

1. 客户 A 来访。检查 redis 是否存在挂单 - 扫描“order:t_shirtid:1”。不存在。
2. 开始交易 - watch "order:t_shirtid:1", multi, setex "order:t_shirtid:1"3600 1, exec
3. 如果客户 B 来访，我们将看到一个键为“order:t_shirtid:1”且值为 1 的待处理订单，并且不允许客户 B 下单
4. 如果 1 小时后，键“order:t_shirtid:1”过期且未完成，客户 B 访问时将看到 redis 中没有任何包含该键的内容，可以继续订购

这个策略有时会失败，因为客户A和客户B可能都去了不同的应用服务器，都发现redis中没有"order:t_shirtid:1"，都准备顺序写入redis(即watch不会有任何影响，因为，首先客户 A 走了，完成所有事情，然后客户 B 进入 redis 并写入相同的东西，但更重要的是，两者都先后完成了对“order:tshirt_id:1”的扫描，知道有redis 中没有挂单)。因此，即使只剩下 1 件 T 恤可供销售，我们也允许客户下订单。

那么处理这个用例的正确方法是什么？我有兴趣了解其他人所做的事情。在此先感谢您的帮助。

Answer 1

由于您使用的是 WATCH/MULTI/EXEC，因此只有当 B 在 A 完成(执行)事务后开始事务时才会发生竞争条件。

IMO，解决这个问题的更好方法是将临时订单存储在有序集中。这将使您可以用原子 Redis 操作替换 SCAN 并将其包含在事务流中，从而消除竞争条件(并提高性能)。但是，如果您采用这种方法，则需要手动使 ZSET 的成员过期(使用分数存储时间戳，定期/访问时删除 1 小时前的成员)。

顺便说一句，从您的示例来看，给定的 t_shirt ID 似乎只能有一个临时订单。