- ScanOptions有两个参数count及match。其中match为匹配规则。count为每次扫描key的数量，而不是一次扫描返回结果集的数量。keys的时间复杂度是O(n)，scan命令是为了避免堵塞，分批扫描，所以别指望性能上的提升。redis底层默认count是10，建议设置大一点，毕竟多次的往返开销是不容忽视的。而太大的话，又失去分批扫描的意义。具体数量要根据实际权衡，大致1000~10000？存疑，有经验的可以解答下
- Cursor为scan扫描初次后返回的结果ScanCursor，其中包含关键的游标cursorId（<=0后则扫描结束），以及一次扫描的结果集等。ScanCursor中的hasNext经过重写，所以一次扫描的结果遍历后并不代表结束，还要看CursorState是否为FINISHED状态。如果当前批次已遍历完，但是状态还是OPEN的，则进行下一批次的scan，获取该批结果后更新cursorId、state、delegate。这边贴出部分编译后的源码：
public boolean hasNext() {
this.assertCursorIsOpen();
while(!this.delegate.hasNext() && !ScanCursor.CursorState.FINISHED.equals(this.state)) {
this.scan(this.cursorId);
}
if (this.delegate.hasNext()) {
return true;
} else {
return this.cursorId > 0L;
}
}
- 每批次scan的结果集可能重复，去要去重。原因与scan过程redis底层数据的hash扩容/缩容过程有关
- 'SCAN' cannot be called in pipeline / transaction mode. 需要做其他处理的，可以在扫描都完成后，再开启