其他文章: 异地多活关键点梳理 - fei33423 - 博客园
传统分库分表,
数据分布不依赖id具体规则, 在哪里是算的, 无论id是什么, 一旦扩容后, 因为无法对新老数据id区别, 需要进行数据迁移. 数据迁移时的可用性也很重要. 为此codis引入了slot模式, 将数据迁移降低到较低的程度.
这种对业务的侵入改造较少, 但没有考虑数据的远距离传输问题.
蚂蚁的逻辑数据中心
- 数据库连接的机器下降 + 尽量本地中心完成 + 异地多活的问题. 但是一个国际化用户可能会先通过网络路由到某个中心. 网络耗时仅一次.
https://blog.csdn.net/fei33423/article/details/114264410 phil转载加补充备注的
首先本地库的扩容,依赖了oceanbase, 类似slot模式,对用户无感.
其次为了解决异地多活灾备的问题, 一个数据过来查询,需要知道是在哪个城市,哪个机房, 故id上或者查询数据上要能体现出来.
数据在哪里,根据id来配置,或者传递一个字符串,告知在哪个库上, 不需要数据迁移. 但需要把对应的库/表/弹性位隐含到id中. 需要业务改造.
弹性位的诞生, 如果一个机房异常了,数据库挂了(异地灾备也挂了的情况下,数据未同步). 传统模式下,只需要将客户端的库访问切换到新的库即可. 但是由于ldc模式, 哪个库是有id本身决定的,老的id分库位还是要原来,读取失败(数据未同步过来). 新的要访问到新库上. (后续数据也要传递过来). 故需要在后台系统上配置一个弹性位值, 平时是0, 异常情况设置成1.
单元化部署
本质上就是分库分表. LDC 实现的关键就在于单元化系统架构设计,所以在蚂蚁内部,LDC 和单元化是不分家的,这也是很多同学比较困扰的地方,看似没啥关系,实则是单元化体系设计成就了 LDC。
但是又多了Rzone(Region),Czone(city),Gzone(global)的三种数据方式, Rzone是完全的分库分表,没有一个地方又全集, Czone是数据同步, 一个城市同步全部. Gzone呢,每个zone都有全集,都同步过去. 提高异地性能. [1]
ob的本质
由于分布式,需要元数据去管理各个切片.
ChunkServer主要功能包括存储多个子表,提供读取服务,执行定期合并和数据分发。
OceanBase将大表划分成256MB的子表,每个子表一般由一个SSTable组成,每个SSTable由多个Block组成,每个Block 4KB ~ 64KB之间。子表不能太大也不能太小,太大的话导致子表迁移以及负载均衡成本较高,也不能太小,太小导致元数据会比较大,增加RootServer负担。查找数据时,先根据子表数据分布定位到子表,然后在SSTable中执行二分查找,找到基线数据后,ChunkServer请求UpdateServer获取增量数据,合并基线数据和增量数据的结果。
一般在凌晨的时候,OceanBase会触发UpdateServer的数据分发和合并,这时ChunkServer向UpdateServer请求某段时间的更新操作,和本地数据合并。
国际化逻辑中心
场景人到火星上了,还能使用软件
错误的方案
id上还需要一个区域号. 需要用户自己配置, 未来一段时间在哪里生活. 将用户的数据同步到对应中心上. 所有异地获取的数据,都懒加载同步到本地/本全球区域中心上.(优先本地) 仅第一次慢. 后续都快. 写读到中心库, 普通读优先本地. 但问题就是缓存的更新难以解决. 需要有个同步中心集中管控.
这个势必增加数据库的复杂性和可靠性. 元数据的维护又是一个问题,因为同步的数据量大了之后就很难管理. 但也不会多, 跨世界流转的人不会多.
正确的方案
每份
附录
[2] 一致性hash