Redis Module - Accessing Multiple Keys with Clustering in Mind

I have a Redis module with a custom command that issues commands to two different keys at once.

The custom commands receives a key (e.g. myKey), and some values, and issues HSET myKey_sd1 ... and ZADD myKey_sd2 ... commands.

I wonder what would happen in a cluster configuration, where each key could exist in a separate node.

Right now, inside the module's custom command I enclosure the key that is given to me in { and }, so I end up issuing HSET {myKey}_sd1 and ZADD {myKey}_sd2

Which works but I wonder if it's necessary.

I also wonder what happens if I receive a key that is already enclosed in curly brackets (because the user of the module wants to control the hash slot by himself) - e.g. 123_{myKey}

Right now, I would still enclose this key in my own curly brackets when I issue the HSET and ZADD - HSET {123_{myKey}}_sd1 ... and ZSET {123_{myKey}}_sd2

In this case, as far as I know, Redis would compute the hash for 123_{myKey which undermines the input of the user (since they didn't wish to enclose the 123_ part)

To fix it, I could have my custom command look for a { in the key that it received, if it didn't find a {, it would enclose the key in { and }, like I described above. However, if it did find a {, it would leave the key as is, resulting in (in the case of the example above) HSET 123_{myKey}_sd1 ... and ZADD 123_{myKey}_sd2 - which works both for the user and for the inner workings of the module.

So I wonder

  1. Is enclosing the keys that I receive from the user in { and } the right way to support clustering?

  2. If so, am I handling the case where the user provides a key which is already enclosed in { and } in the right way?

1 answer

  • answered 2019-02-10 13:27 Kevin Christopher Henry

    1. Is enclosing the keys that I receive from the user in { and } the right way to support clustering?

    The Redis Module cluster documentation is "missing", but I believe it's the case that your module must make sure to use the same node as the key that was passed as an argument.

    So, yes, you must use hash tags to ensure that your keys are using the same hash slot as the passed key.

    1. If so, am I handling the case where the user provides a key which is already enclosed in { and } in the right way?

    Your proposed fix (not your current implementation) is right. You must hash to the same slot as the key that is passed, which means respecting any specified hash slot.

    Just make sure you're following the exact algorithm for interpreting hash tags. You don't want any edge cases here.