在redis 3.0.7版本上使用cluster出现问题，
在我们的集群中，存在着许多巨大的键，一些键的条目数已经达到了500M字节，甚至达到了数百万。
现在我们想使用migrate命令对集群进行横向扩展，但是这个命令是同步的，可能会导致源节点和目的节点阻塞。
是否有任何优雅的方式来迁移这些 key ？
最佳答案
根据我的实验，随着 key 长度的增加，响应时间 (RT) 增长迅速。
在这个实验中，我的目的是观察响应时间 (RT) 如何根据 key 长度而变化。我创建了一个 JavaScript 脚本来读取所有 key 并计算 RT。出于实验目的，我在节点中加载了 1000、5000 和 10000 个键。结果如下图所示。
我观察到 RT 增长迅速， key 长度增加。详细而言，对于具有 10000 个 key 且 key 大小为 10 的节点，RT 为 91.7 ms，而对于相同的节点和 key 长度为 24000，RT 为 1014.3 ms。此外，要检索一个大小为 10 的单个 key ，RT 为 0.0127，要检索一个大小为 24000 的单个 key ，RT 为 0,102。
因此，当批量加载和复制不可用时，您可以尝试使用 MIGRATE 一次迁移一个 key 。 MIGRATE 命令以原子方式将 key 从源数据库传输到目标数据库。但这是一个破坏性操作，除非传递了 COPY 选项(COPY -- 不要从本地实例中删除 key )。
从 Redis 3.0.6 开始，MIGRATE 支持一种新的批量迁移模式，该模式使用流水线在实例之间迁移多个键，而不会产生往返时间延迟和使用单个 MIGRATE 移动每个键时的其他开销打电话。
为了启用此表单，使用了 KEYS 选项，并将普通键参数设置为空字符串。实际的键名将在 KEYS 参数本身之后提供，如以下示例所示:
MIGRATE 192.168.1.34 6379 "" 0 5000 KEYS key1 key2 key3
因此，总而言之，除了上述方法之外，没有任何优雅的方法可以将 key 从源迁移到目标。
一种可能的解决方案是隔离一个或多个节点中的“大” key ，并设置一个关于 key 长度的阈值。如果 key 超过此阈值，则将 key 保留在当前节点中。如果没有，您可以在不同的节点或数据库中迁移。但是您必须进行一些实验，以便根据响应时间和可能的 SLA 设置此阈值并观察“大”的含义。
你也可以检查这个:https://fnordig.de/2014/03/11/redis-cluster-with-pre-existing-data/
关于redis - 如何在 3.0.7 上迁移 redis 集群中的巨大 key ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40416015/