浅谈数据库同步和迁移
|
高德地图 App 是国内首屈一指的地图及导航应用，阿里云 MongoDB 数据库服务为该应用提供了部分功能的存储支撑，存储亿级别数据。现在高德地图使用国内双中心的策略，通过地理位置等信息路由最近中心提升服务质量，业务方(高德地图)通过用户路由到三个城市数据中心，如下图所示，机房数据之间无依赖计算。
这三个城市地理上从北到南横跨了整个中国 ，这对多数据中心如何做好复制、容灾提出了挑战。如果某个地域的机房、网络出现问题，可以平滑的将流量切换到另一个地方，做到用户几乎无感知? 目前我们的策略是，拓扑采用机房两两互联方式，每个机房的数据都将同步到另外两个机房。然后通过高德的路由层，将用户请求路由到不同的数据中心，读写均发送在同一个数据中心，保证一定的事务性。然后再通过 MongoShake，双向异步复制两个数据中心的数据，这样保证每个数据中心都有全量的数据(保证最终一致性) 。如下图所示：
任意机房出现问题，另两个机房中的一个可以通过切换后提供读写服务。下图展示了城市 1 和城市 2 机房的同步情况。
遇到某个单元不能访问的问题，通过 MongoShake 对外开放的 Restful 管理接口，可以获得各个机房的同步偏移量和时间戳，通过判断采集和写入值即可判断异步复制是否在某个时间点已经完成。再配合业务方的 DNS 切流，切走单元流量并保证原有单元的请求在新单元是可以读写的，如下图所示。
4.2 某跨境电商 某跨境电商在中国和海外分别部署了 2 套 MongoDB，其中海外主库上提供读写服务，同时用户希望把海外的数据拉到国内进行离线计算，以及承担一部分读流量，以下是该用户采用 MongoShake 搭建的链路方案：
4.3 某著名游戏厂商 某著名游戏厂商采用了 MongoShake 搭建了异地容灾链路。用户在 2 个机房分别部署了 2 套应用，正常情况下用户流量通过北向的 DNS/SLB 只访问主应用，然后再访问到主 MongoDB，数据通过 MongoShake 在 2 个机房的数据库之间进行同步，一旦机房 1 不可用，DNS/SLB 将用户流量切换到备上，然后继续对外提供读写服务。
4.4 采用 Shake 的开源多活方案 这里是我们给出的根据 Shake 创建多活的方案，包括 MongoShake 和 RedisShake。 上文我们介绍在开源 MongoDB 下，可以根据控制流量分发来达到多活的需求。比如下面这个图，用户需要编写一个 Proxy进行流量分发(红色框)部分流量，比如对 a, b 库的写操作分发到左边的 DB，对 c 库的写操作分发到右边的 DB，源库到目的库的 Shake 链路只同步 a, b 库( MongoShake 和 RedisShake 均提供按库过滤功能)，目的库到源库的 Shake 链路只同步 c 库。这样就解决了环形复制的问题。 总结来说，也就是写流量通过 Proxy 进行固定策略的分发，而读流量可以随意分发到任意 DB。
4.5 采用 Shake 的级联同步方案 这个是一个全球的部署的用户采用 Shake 搭建的全球混合云级联方案的示例图。有些数据库位于云上，有些位于云下，Shake 提供了混合云不同云环境的同步，还可以直接级联方式的集群同步。
5. 总结 总结主要介绍了一下数据库同步和迁移的场景，然后结合功能和应用场景介绍了下我们开源的两款 Shake 工具。目前，我们的 Shake 工具还在持续功能迭代中，欢迎关注我们的 Github，有任何问题欢迎在 Github 上进行提问，也欢迎分享你们的使用场景，以帮助我们更好的完善产品。 【编辑推荐】
点赞 0 （编辑：拼字网 - 核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
