yhxjack

This maybe be due to the ResourceVersion field

看了下，问题2应该是p.stat.Reset(false)这个方法，最后一次重置时又执行了一遍，导致所有结果都是真实值的2倍

> @yhxjack bigkeythreshold 的含义是说，对于太大的 hash、list、set、zset 的子元素超过 16384，并不是 byte or bit。 另外，这并不幼稚，说明我们文档确实没写清楚，感谢反馈，我们后续会更新文档。 我主要是做云原生的，对redis不要懂，我对大key的理解应该是说redis的key太大导致传输或者校验会有问题，这个大key和redis-shake中说的大key是一个概念吗

> @yhxjack 是一个概念，在 RedisFullCheck 中，key 太大的话，校验也会非常慢，因此这个参数可以控制当校验大key时，是否快速校验，比如值比较下 field 的个数是否相同，就不比较具体 filed 的每一个值了。 不是很理解呀，如果类型是单一的string呢，是不是需要大小的限制呢？

增量同步是通过aof实现的吗

此外，咱们有没有答疑的群，想要学习下

> 1. 内存占用取决于大 key 的大小，与原库大小无关。 大key < shake 2. 提供 shake 日志帮你看下 第二个是因为源集群是单节点，目标集群是3台节点的集群模式，同步过来之后，分片是不均的，前两个约是总数的1/6，最后一个节点有2/3的数据，这种情况是合理的吗？