apache
Prefix scan didn't work well when enabling the cluster mode
Search before asking
- [X] I had searched in the issues and found no similar issues.
Version
centos 7.9
Kvrocks was running with two cluster nodes and slot distributions are 0-8191 and 8192-16383 (kvrocks 2.6.0 内含两个节点的集群，slot分别为0-8191、8192-16383)
Minimal reproduce step
What did you expect to see?
return keys should start with f character.
返回以f开头的key
What did you see instead?
Anything Else?
1.触发场景可能与大量的key被删除有关，因为当时的场景就是删除大量的key 2.依稀记得当时执行scan的时候，在程序里面超时了；然后我手动在redis-cli里面执行，响应速度也很慢
Are you willing to submit a PR?
- [ ] I'm willing to submit a PR!
@EasyProgramming could you provide a complete list of commands execute after a FLUSHDB so that we can reproduce locally?
@EasyProgramming It's a limitation in the scan command when enabling the cluster mode. It'll only look forward N(50) slots when scanning keys, for example:
If we have keys: aaaa(slot 0), bbbb(slot 10), cccc(slot 100), dddd(slot 200) and we scan with:
SCAN "0" MATCH "bb*"
it works well since bbbb is located at slot 10, and Kvrocks try to look forward next 50 slots. But if you scan with cc*:
SCAN "0" MATCH "cc*"
it will return empty array with cursor(_bbbb) since cccc is located at slot 100.
For the implementation, please refer: https://github.com/apache/kvrocks/blob/unstable/src/storage/redis_db.cc#L365
Of course, for this limitation will make the scan command very hard to use. We will try our best to improve this if possible. cc @tisonkun @PragmaTwice
@git-hulk 我这边使用Java的lettuce连接的kvrocks，看了lettuce对scan、hscan、sscan的实现方式，lettuce是以游标返回的是否为字符0来判断是否扫描完成的，所以想问一下，kvrocks这块关于scan、hscan、sscan扫描完成的标志为是否也是字符0呢，这样的话，对于我这边的程序来讲还是可以接受的
Could we make
HASH_SLOTS_MAX_ITERATIONSa configurable constant?
Yes, but this cannot resolve this problem unless they set it to MAX_HASH_SLOTS.
@git-hulk 我这边使用Java的lettuce连接的kvrocks，看了lettuce对scan、hscan、sscan的实现方式，lettuce是以游标返回的是否为字符0来判断是否扫描完成的，所以想问一下，kvrocks这块关于scan、hscan、sscan扫描完成的标志为是否也是字符0呢，这样的话，对于我这边的程序来讲还是可以接受的
Yes, you can continue iterating if the cursor is NOT "0".
Yes, but this cannot resolve this problem unless they set it to MAX_HASH_SLOTS.
But it is the only workaround I can come up with now, for both being compatible with currently behavior and solving the issue by manually setting the option.
The user can work around this by continuing the scan if the cursor is not "0", it will start with the new slot id instead of 0.