数据库传输服务
拓扑类型 | 拓扑图 | 特点 |
单写多读 | | 单写多读架构的主要特点如下。
|
多写多读 | | 多写多读架构的主要特点如下。
数据整体时延与拓扑结构复杂度有关,拓扑结构越复杂,时延越大。
说明 |
冲突处理策略 | 说明 | 推荐程度 |
冲突覆盖 | 当源端数据与目标端数据冲突时,源端的数据会覆盖目标端的数据。 说明 在大多数情况下,选择冲突覆盖得到的数据是业务想要的数据,但也有特殊情况。比如在 A 和 B 双向同步的场景中,如果 A 写入数据的时间是 t1,B 写入数据的时间是 t2(t1 比 t2 晚),在 A 的反向链路场景里,B 的数据传到A 这边时,就会把 A 在 t1 时刻后写入的数据覆盖掉。 | 优先推荐 |
冲突忽略 | 当源端数据与目标端数据冲突时,忽略冲突,源端数据与目标端各自写入数据。 说明 冲突忽略会造成源端和目标端的数据不一致。 | 不推荐 |
冲突报错 | 当源端数据与目标端数据冲突时,需手动修改冲突数据,否则同步任务会暂停并且报错。 说明
| 仅测试环境中推荐 |
源库类型 | 源库版本 | 同步类型 | 目标库类型 | 配置文档 |
火山引擎版 MySQL |
|
| MySQL | |
火山引擎版 veDB MySQL | MySQL 8.0 | | MySQL | |
公有网络 MySQL |
| | MySQL | |
专有网络 MySQL |
| | MySQL |
正常切流流程 | 异常切流流程 |
|
|
正常切流流程 | 异常切流流程 |
|
|
现有痛点 | 业务单元化改造后 |
数据库连接瓶颈 | 数据库连接属于极为宝贵的资源。业务单元化改造后,每个单元内的数据读写都是内网自闭环,这样能够减少数据库连接。 |
机房延时 | 如果单元化做的比较好,即业务只会在单元内访问自己。每个单元内的数据读写都是内网自闭环,无跨机房调用。 |
流量入口 | 用户通过路由网关,每次都会请求到自己所在单元的数据中心。比如用户在 A 中心,单元化后,用户 A 的请求都会路由到 A 中心,不会路由到 B 中心。从入口流量到分布式服务,全链路消除了单点。 |
数据冲突 | 将用户按某个规则进行分组,每组用户写入数据时只能写入到指定的数据中心,相当于将用户与数据中心进行绑定,这样就保证了在双向同步之前不同用户组的数据不会冲突。 |
拆分方案 | 业务场景 | 业务单元化分析 |
方案一 | 某客户是物流供应商,提供淘宝、京东等多个电商平台的物流服务,其业务关键表订单表概要字段如下所示。
| 客户在数据库 A 中存储来自淘宝的订单,在数据库 B 中存储来自京东的订单,此时可针对数据库 A 和 B 构建一条双向同步链路。由于淘宝端的订单变更(INSERT/UPDATE/DELETE)仅源自数据库 A,京东端的订单变更(INSERT/UPDATE/DELETE)仅源自数据库 B,数据依据“订单来源”进行天然分区,不会引发数据冲突。 |
方案二 | 某客户是 C 端运动 App,由于用户量巨大,客户使用了数据库 A、B 来存储用户数据,其 User 表关键字段如下所示。
|
|
方案三 | 某客户是国际化 B 端 Saas 提供商,国内租户数据写入 CN 库,国外租户数据写入 US 库,其租户表大致如下所示。
|
|