这是一个创建于 127 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如有 5 个节点，哪一天因为容量不太够了（例如已经达到 70%了）想再加 5 个节点，那么加完之后：
- 原本 5 个节点仍然是 70%，但是增速可以变慢 50%;
- 新的 5 个节点是 0%，增速与上面一样;
如果要重新分配：
- 有一半数据要通过网络 IO 磁盘 IO 写来写去，可能很重，影响在线业务，也慢
如果不重新分配：
- 除非数据有过期淘汰机制，不然会一直不平衡
咋整？
6 条回复 • 2024-07-19 15:29:59 +08:00
 |
1
povsister 127 天前
存储层单独抽象出来，不要和业务耦合。
rebalance 过程要可观测可预测，做好限速。 正经的存储中间件都是必须考虑 rebalance 的，你这个大概率手搓的吧。 |
 |
2
edenzhang 127 天前
无他，做限流，做好跟业务 IO 的并发控制，优先保证业务
这是分布式存储中的典型场景了，设计初期就应该要考虑到 |
 |
3
RedisMasterNode OP Attach 不了，在评论里补个上下文：
是时序数据，例如监控指标，通常这些都会在一定时间后被删除（例如 3 个月，6 个月） 有这个前提下考虑： - 做重平衡很重，而且如果没有重平衡其实数据过段时间自然就会平衡 但是很多人又想要这样的功能（思考 ing 实际上可以遇见的是，做出来算是一个复杂的特性，容易做错不说，错了肯定会被投诉，而且在上下文里总是觉得其实用户并不是真的需要这个功能，只是重平衡之后可以缓解容量焦虑（当然，也接受别人的不同观点，能理解） |
 |
4
snipking 127 天前
参考 mongodb sharding ，支持重新平衡，可以设置什么时间到什么时间允许进行重新平衡
|
 |
5
Akiya 127 天前
任何支持分区的存储系统都做不到在线 rebalance ，你要业务不断，只能另起一个存储系统同步数据，数据同步完成之后直接把业务切换过来，这样可以做到最短的离线时间
|
Select Language