存储类的应用，在扩容更多的节点后，数据是否应该被重新分配以保持平衡？

[RedisMasterNode]

比如有 5 个节点，哪一天因为容量不太够了（例如已经达到 70%了）想再加 5 个节点，那么加完之后：

• 原本 5 个节点仍然是 70%，但是增速可以变慢 50%;
• 新的 5 个节点是 0%，增速与上面一样;

如果要重新分配：

• 有一半数据要通过网络 IO 磁盘 IO 写来写去，可能很重，影响在线业务，也慢

如果不重新分配：

• 除非数据有过期淘汰机制，不然会一直不平衡

咋整？

[povsister]

存储层单独抽象出来，不要和业务耦合。
rebalance 过程要可观测可预测，做好限速。

正经的存储中间件都是必须考虑 rebalance 的，你这个大概率手搓的吧。

[edenzhang]

无他，做限流，做好跟业务 IO 的并发控制，优先保证业务

这是分布式存储中的典型场景了，设计初期就应该要考虑到

[RedisMasterNode]

Attach 不了，在评论里补个上下文：
是时序数据，例如监控指标，通常这些都会在一定时间后被删除（例如 3 个月，6 个月）

有这个前提下考虑：
- 做重平衡很重，而且如果没有重平衡其实数据过段时间自然就会平衡

但是很多人又想要这样的功能（思考 ing

实际上可以遇见的是，做出来算是一个复杂的特性，容易做错不说，错了肯定会被投诉，而且在上下文里总是觉得其实用户并不是真的需要这个功能，只是重平衡之后可以缓解容量焦虑（当然，也接受别人的不同观点，能理解）

[snipking]

参考 mongodb sharding ，支持重新平衡，可以设置什么时间到什么时间允许进行重新平衡

[Akiya]

任何支持分区的存储系统都做不到在线 rebalance ，你要业务不断，只能另起一个存储系统同步数据，数据同步完成之后直接把业务切换过来，这样可以做到最短的离线时间

[txwdcom]

@Akiya ceph 了解下，重平衡再正常不过的操作了