Set cluster slot for scan commands, rather than random#2623
Conversation
36a52f2 to
f39ee1e
Compare
scan commands, rather than random
c2c460f to
3898d71
Compare
|
Hi @vmihailenco. Is there any chance you could have a look over this, and let me know if this is a change you'd be interested in? Thanks! |
3898d71 to
e0fbcea
Compare
|
Hi @vmihailenco. Just following up on this pr. Is it a change that you would consider? |
|
@chayim Hi! This is a change we've been carrying in a fork for about 6 months now. Do you have any time to have a look over and see if this is something this project would be willing to accept? The idea is basically lifted from the Redis clients for other languages. |
|
Would it be an option for scan to implicitly run over all shards if no hash-tag is included? |
|
The Java clients actually error if you don't provide a hash tag. I kinda think that behaviour is better, as it avoids the surprising result of your scan not really working at all, but it would be a breaking change for this library. |
|
Hello @pete-woods , feel free to sync with master and we can check this. |
e0fbcea to
accd6ed
Compare
|
Okay - did a quick rebase |
… client - At present, the `scan` command is dispatched to a random slot. - As far as I can tell, the scanX family of commands are not cluster aware (e.g. don't redirect the client to the correct slot). - You can see [here](https://github.com/redis/jedis/blob/869dc0bb6625b85c8bf15bf1361bde485a304338/src/main/java/redis/clients/jedis/ShardedCommandObjects.java#L101), the Jedis client calling `processKey` on the match argument, and this is what this PR also does. We've had this patch running in production, and it seems to work well for us. For further thought: - Continuing looking at other Redis clients (e.g. Jedis), they outright [reject as invalid](https://github.com/redis/jedis/blob/869dc0bb6625b85c8bf15bf1361bde485a304338/src/main/java/redis/clients/jedis/ShardedCommandObjects.java#L98) any scan command that does not include a hash-tag. Presumably this has the advantage of users not being surprised when their scan produces no results when a random server is picked. - Perhaps it would be sensible for go-redis to do the same also?
accd6ed to
7b39fda
Compare
|
@ndyakov please let me know what you think, now the pr is up to date |
|
@pete-woods Looks good, will double check with Jedis and see if we can include this in the next release, thank you. |
|
After couple of discussions I don't see how this can break the current behavior, it can only improve it for when there is a hashtag in the pattern. Thank you for the contribution! |
|
Great stuff. I'd also consider erroring for cluster mode, when there's no tag set like the Java clients do, but that's a separate decision. |
… client (redis#2623) - At present, the `scan` command is dispatched to a random slot. - As far as I can tell, the scanX family of commands are not cluster aware (e.g. don't redirect the client to the correct slot). - You can see [here](https://github.com/redis/jedis/blob/869dc0bb6625b85c8bf15bf1361bde485a304338/src/main/java/redis/clients/jedis/ShardedCommandObjects.java#L101), the Jedis client calling `processKey` on the match argument, and this is what this PR also does. We've had this patch running in production, and it seems to work well for us. For further thought: - Continuing looking at other Redis clients (e.g. Jedis), they outright [reject as invalid](https://github.com/redis/jedis/blob/869dc0bb6625b85c8bf15bf1361bde485a304338/src/main/java/redis/clients/jedis/ShardedCommandObjects.java#L98) any scan command that does not include a hash-tag. Presumably this has the advantage of users not being surprised when their scan produces no results when a random server is picked. - Perhaps it would be sensible for go-redis to do the same also? Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>
… client (#2623) - At present, the `scan` command is dispatched to a random slot. - As far as I can tell, the scanX family of commands are not cluster aware (e.g. don't redirect the client to the correct slot). - You can see [here](https://github.com/redis/jedis/blob/869dc0bb6625b85c8bf15bf1361bde485a304338/src/main/java/redis/clients/jedis/ShardedCommandObjects.java#L101), the Jedis client calling `processKey` on the match argument, and this is what this PR also does. We've had this patch running in production, and it seems to work well for us. For further thought: - Continuing looking at other Redis clients (e.g. Jedis), they outright [reject as invalid](https://github.com/redis/jedis/blob/869dc0bb6625b85c8bf15bf1361bde485a304338/src/main/java/redis/clients/jedis/ShardedCommandObjects.java#L98) any scan command that does not include a hash-tag. Presumably this has the advantage of users not being surprised when their scan produces no results when a random server is picked. - Perhaps it would be sensible for go-redis to do the same also? Co-authored-by: Nedyalko Dyakov <1547186+ndyakov@users.noreply.github.com>
scancommand is dispatched to a random slot.processKeyon the match argument, and this is what this PR also does.We've had this patch running in production, and it seems to work well for us.
For further thought: