数据库架构设计

说明: 设计侧重于关于运维层面

设计理念:

1. 稳定性要求高
2. 数据安全性高: 不丢失数据, 数据可恢复
3. 自调节化: 避免运行时人工干预, 基于 operator 方式主动状态维护

一些常见的需求方向

• 存算分离: 形式有多种, 核心是存储层来保障安全性和可用性, 计算层提供功能和性能;
• 缓存: 外置独立缓存 和 内置缓存 两种模式; 内置缓存一致性更高, 外置缓存灵活性更好;
• 异构数据同步: 例如基于 binlog or ETL 将数据同步到 es, clickHouse 等, 有效减少对核心原始库数据耦合;
• 数据强一致性: 直接使用 DB 来承载业务, 避开外部缓存;
• 数据预热: 一般指重启前 或 活动前, 将数据加载到缓存中;
• ratf: 现代数据存储大量使用raft来保障数据一致性

数据类型

1. 结构化数据
2. 半结构化数据: 行结构日志文件
3. 非结构化数据: 图片, 视频, pdf 等

事件

主从一致性

mysql 原生为异步复制, 写主读从可能会因延迟造成读取的数据不一致

1. 强制读主库: 简单, 可指定某些 sql 强制主库; 手动实现或者某些 sdk 支持标记路由;

2. 半同步复制:

   • 优点: 简单, 原生支持
   • 缺点: 是降低了主库写性能, 且半同步还是有可能退回到异步模式的

3. 全同步: 必须从库写成功后, 主库才响应;

4. 引入中间件:
   由中间件判断, 如果某个 key 最近一段时间(经验值)发生过写, 则读操作也路由到主库
   缺点: 多一个组件, 也难控制

5. 引入缓存: 和中间件机制类似, 即用一个外置锁来判断去主库还是从库
   写数据时: 先在缓存内设置一个 ttl 为 2-5s 的 key, 再写主库数据
   读数据时: 先读缓存, key 存在则明最近发生过写, 则读主库, 否则直接读从库
   优点: cache 操作简单, 缺点: 读写都多了一次 cache 操作

异构数据同步和查询

场景 1: 业务库是按照订单 ID HASH 进行分库, 但是后台统计需要按渠道 ID 进行统计;

解决办法:

1. 应用层处理: 多库查询, 复杂的 sql;
2. 新库新模型: ETL 全量 + 增量将数据读取写入统计库, 并进行字段或属性调整;
   缺点: 不好处理删除和更新的数据, 除非数据行内有加版本标识
3. 应用双写: 简单, 但很难保证数据一致性
4. 应用写 mq: 独立日志服务从 mq 读再写从库, 场景狭小, 且仍然存在一致性问题
5. 基于 binlog 的数据分析, 将解析后的数据存到异构库中, 推荐;

这几种方式都需要定期或实时做数据一致性校验

场景 2: 冗余表, 即另一个统计类的多字段表

1. 单机就采用事务方式写
2. 跨实例就采用双写或场景 1 的办法

基于 binlog 的异构数据同步

原理: 模拟从库获取 binlog, 解析后直接处理变更数据

优点:

1. 准实时性
2. 不需要修改业务
3. 记录了全部的增删改操作

推荐架构:
mysql -> binlog -> 程序格式化 binlog-> MQ(kafka) -> 消费后存入异构库

实现

1. canal(阿里巴巴开源项目, 纯 java 开发)

2. python-mysql-replication(python 开发) https://github.com/noplay/python-mysql-replication

3. https://github.com/danfengcao/binlog2sql.git

mysql 多节点写的一致性

即多主节点同时写或 update, 如何保障复制时数据一致不冲突和循环同步;

早期方案:

1. 每个表的主键自增 id 区分单双数
2. 引入集中式全局唯一 ID 生成器或分布式唯一 ID 生成器算法等来保障 ID 不冲突
3. 过滤掉 DDL 同步, 由维护人员多端采用在线 DDL 工具进行表结构变更
4. 使用 GTID 模式, 保障数据不会循环同步

外置同步机制:
不使用原生同步机制, 采用 binlog 解析后入 MQ, 远端再对 MQ 进行消费入本地库;
缺点很明显, 应用场景比较窄;

数据库秒级别平滑扩容

原架构: 应用程序通过 ID 模 2 来分库

• A–>B A 是主库
• C–>D C 是主库

需求: 2 主 2 从 扩容为 4 主 4 从

步骤:

1. 应用层关闭对从库的读
2. 由 2 主 2 从调整为 2 对主主结构 A>––<D
3. 此时插入的数据还是走的 AC 对应用不影响
4. 应用层由模 2 改为模 4
   0 -> A
   1 -> B
   2 -> C
   3 -> D
   因为 A 和 B 的数据是同步的, 所以此时 0 和 1 可读写的数据和原来无差别
5. 增加从节点
   A B C D
   | | | |
   E F G H
6. 移除 ABCD 中的冗余数据

1
2
3

id      uid    version       ext
1       100     1           {"a": 100, "b": 200}
2       101     2           {"a": 100, "b": 200, "age": 18}