水平分库如何做到平滑扩展
这个对于我们常用的分库分表方案来说,有很大的优势,分库分表的扩容是一件头疼的问题,如果采用对db层做一致性hash,或是中间价的支持,它的成本过于高昂了,如果不如此,只能停机维护来处理,对高可用性会产生影响。 那是否有方案,既可以快速扩展,又不降低可用性?这一篇,我们聊聊分库分表的扩展方案,供大家一起探讨。 一、水平分库扩展问题 为了增加db的并发能力,常见的方案就是对数据进行sharding,也就是常说的分库分表,这个需要在初期对数据规划有一个预期,从而预先分配出足够的库来处理。 比如目前规划了3个数据库,基于uid进行取余分片,那么每个库上的划分规则如下: 如上我们可以看到,数据可以均衡的分配到3个数据库里面。 但是,如果后续业务发展的速度很快,用户量数据大量上升,当前容量不足以支撑,应该怎么办? 需要对数据库进行水平扩容,再增加新库来分解。新库加入之后,原先sharding到3个库的数据,就可以sharding到四个库里面了 不过此时由于分片规则进行了变化(uid%3 变为uid%4),大部分的数据,无法命中在原有的数据库上了,需要重新分配,大量数据需要迁移。 比如之前uid1...