关于可能的命令“ValueScan”

[ncghost1]

之前在redis上提的关于string match新命令的issue，留言中有人提出了一个我认为也许更有意义的命令“ValueScan”，感觉这个命令能够缓解不小心存储了big key的问题，逐步扫描big key的值能够防止阻塞。
@enjoy-binbin 不好意思彬彬突然拉你出来讨论，我好奇据你所知有曾经讨论过关于ValueScan这类命令吗？感觉这是个有用的命令却一直没添加过。

[enjoy-binbin]

我这边没印象... （字符串匹配一直都不咋是 redis 擅长的，我印象中有一些 module 会特定做这些，例如 https://github.com/RediSearch/RediSearch ？）
从那个 issue pending 的情况也可以看出，core-team 不怎么关心它，或者太忙关心不了它

VALUESCAN cursor [MATCH pattern]
所以扫描 big key，是用 valueScan 去扫描对应字符串键的值吗？我能理解说用在字符串匹配里，不过这个跟 big key 是怎么挂钩上的？大键的值会有规律被我们 scan 出来吗

ref: redis/redis#10646

[ncghost1]

啊，突然才想起来有个getrange……确实getrange也可以这么做，但是怎么知道一个string的值是不是很大还得先用命令获取一次长度，多了1个RTT？而且getrange用起来扫描大key也没有value scan好用。如果有了ValueScan命令，我想是不是所有的Get实际上都能被ValueScan替代？
举个栗子～设定每次ValueScan 最多10000的长度，如果返回光标为0了就代表结束了，否则服务端代码可以让它从返回的光标继续扫描，直到0为止。这样所有的Get都可以用ValueScan替代，大的string如果拆掉是为了分多次从多个小的string获取值来拼接的话，也许不需要拆掉了，只要有这个ValueScan分多次就行。🤣

[enjoy-binbin]

可以是可以，就是感觉用起来有点重（当然如果有的话，对应的客户端都是会加命令方便使用）
主要是本身 redis 就不咋适合存 big key，如果你业务本身就知道这个是 big key 了，在业务层里做 big key 的拆分也可以
就是说对于 redis 本身来说，不是很重要 或者说不是 很常用的用户场景

[ncghost1]

嗯我知道了，我之前也觉得不是很重要，但是我觉得ValueScan也是一个有意义的命令。
再说一下我之前冒出的其他疑问🤣，redis也有多线程了，虽然执行命令还是单线程……
集群好像是通过ping来确认节点alive的吧？我在想能不能把ping在其他线程执行呢，这样就不会因为等待慢查询的命令导致阻塞而失活了。🧐

[enjoy-binbin]

好问题，理论上是可以，不过如果你主线程都因为慢查询被阻塞了，那么主从复制里的命令 master 传过来的命令应该也会被阻塞，此时就是主从延时了，主从延时理论上跟失活应该差不多

个人理解 非标准答案

[ncghost1]

我没有看过主从复制的代码哎🧐这个情况说的是也会对外提供服务的从节点吗？因为我想着如果只做数据备份的话，从节点不需要执行读命令。
没失活感觉还是值得的，如果失活了的话重新被发现会是个额外的时间代价🤔

[enjoy-binbin]

你是说 master 慢查询阻塞，例如阻塞个几十秒，然后因为心跳不了被集群踢下线，触发故障转移吗？
我感觉这种情况的确是要进行故障转移，如果是 master 的话，这都超过集群超时时间了还无法响应..

如果说是 slave 慢查询阻塞，阻塞个几十秒，就算有心跳保活（假如 ping 是子线程的），它主从复制都落后了很多

1. slave 客户端输出缓冲区超过限制，被 master 那边直接 kill 掉
2. 偏移量落后太多，master 那边没办法继续提供增量同步，可能会触发 full sync 全量同步？

主从复制可能是最重要的部分，保活啥的可能还在其次，主从复制的处理感觉就是个大工程
另外阻塞超过集群的超时时间，这个也蛮那个的，业务上来说我觉得怎么样都无法接受（就不用谈后面的失活，被踢出还能保证服务）

[ncghost1]

原来如此，谢谢彬哥！😊