HSCAN with redis 和 jedis 有很多零元素的结果答案

【问题标题】：HSCAN with redis and jedis has a lot of results with zero elementsHSCAN with redis 和 jedis 有很多零元素的结果
【发布时间】：2021-11-30 11:13:45
【问题描述】：

已编辑：由于更多的测试，我对这个问题有了更多的了解；它有很多返回零元素的 hscan 操作。

我正在使用 Jedis Java 库进行迭代 hscans 操作

我在使用 HSCAN 命令时遇到了一种奇怪的行为，该命令在 redis 上的 hashmap 上有一个自定义 COUNT，没有搜索模式。 hashmap 的大小为 350000 个元素（每个元素的大小为 1Kb）

我正在遍历 redis hasmap 元素。在每次迭代中，我将元素存储到一个列表中。当我达到扫描元素的限制（2000 个元素）时，我停止 hscan。然后我进行一些计算并将元素删除（hdel）到列表中。然后我返回执行另一个 hscan 操作（使用新的 zewro 光标启动）并将元素存储在列表等中......这个循环重复，直到 hashmap 耗尽

我已经使用不同的 COUNT 值进行了测试，计算了 hscan 操作的数量以及在每个 hscan 调用中检索到的元素。计算平均元素/hscan 并查看我正在执行多少个 redis 调用

X = COUNT value in each test
Y = mean number of elements returned in each HSCAN iteration
Z = number of HSCAN iterations until the map is depleted

 X   | Y    | Z
-----+------+-------
25   |  4.0 | 82720
50   |  8.0 | 41404
100  | 17.0 | 20766

我收到很多次迭代，结果为 0（但光标具有非零值）。然后，我收到了一些元素编号为 COUNT 值的迭代，没问题。 HSCAN 操作的数量非常多，这严重影响了我的应用程序的性能。内存和 CPU 使用情况受到监控，我没有发现这方面的问题。

我找不到对这种奇怪行为的任何解释，有什么想法吗？

【问题讨论】：

当您说“返回执行另一个 hscan”时，您是从光标值 0 重新开始吗？
改写：然后我返回执行另一个新的 hscan 操作 - 使用新的零初始化光标 - 并将元素存储在列表等中。（这是你的问题？）
HSCAN 有或没有匹配模式？
HSCAN 无模式

标签： performance redis jedis

【解决方案1】：

然后我返回执行另一个 hscan 操作（使用新的 zewro 光标启动）

使用上次 HSCAN 操作返回的光标重新启动 HSCAN 操作。

一旦 HSCAN 返回零光标，如果您愿意，请以零光标重新启动。

IMO，对于您的用例，100 是 COUNT 的低端值。您也可以尝试更大的 COUNT。

【讨论】：