【问题标题】:Redis transaction by fixed number of clients固定数量客户端的 Redis 事务
【发布时间】:2017-05-23 20:53:35
【问题描述】:

我已经阅读了多篇关于 redis 事务的文章。 我有一些包含消息的列表。我使用 redis 为这些消息生成自动增量 ID。 这是我正在尝试做的事情:

  1. 读取计数器值,然后对其进行 INCR。
  2. 将递增后的计数器值放入消息的Id 字段中,然后序列化消息。
  3. 将序列化的消息推送到列表中。

所以计数器总是在相应的列表中保存最后一条消息的 ID。我想在计数器键上加个锁,这样其他请求就无法读取和增加计数器并将另一条消息推送到与最后一个 ID 冲突的列表中。

由于我希望拥有有限数量的 redis 客户端,因此无法实现 WATCH MULTI EXCEC,因为它是同一个客户端进行事务。据我所知,WATCH MULTI EXCEC 适用于您有多个 redis 客户端的情况。

我想知道解决这个问题的正确方法是什么。我应该使用 LUA 脚本并让它序列化消息吗?

【问题讨论】:

    标签: redis


    【解决方案1】:

    Lua 绝对是创建可读写数据的原子逻辑单元的最佳选择。

    但是,在您的情况下,我不相信确实需要原子性。除非严格要求 ID 之间没有间隙,否则您可以调用 INCRBY 获取新 ID,然后在序列化消息时使用它。其他消息将不会获得相同的 ID,唯一的“风险”是在使用该 ID 序列化和存储消息之前让您的工作人员死亡(因此造成间隙)。

    【讨论】:

    • 我想到的“风险”是列表中的最后一条消息可能与计数器的ID不同。
    • 确实如此,如果没有原子性,列表中的消息顺序不一定正确。如果这是一个要求,请使用 Lua。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2015-09-29
    • 1970-01-01
    • 2012-06-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-07-11
    相关资源
    最近更新 更多