08-03 底层数据设计策略——高可用数据

数据备份和失效转移

数据备份

• 冷备（历史订单、业务报表、时效性不高）：最最最坏情况下才会用
  • 低成本
  • 定时
  • 数据丢失
  • 不一致
• 热备
  • 同步热备（一个库提交成功，别的提交失败，不容易控制）
  • 主从热备

Canal数据迁移神器

• 数据镜像
• 增量同步
• 数据异构
  • 加入根据订单id做分库分表的标识，但是需要根据用户id去查询，这时候就得一个一个库挨个查询，带来极大的性能问题，这时需要做数据异构。
  • 根据订单id做一套分库，再根据用户id做一套分库
  • 可以用Canal实现根据订单id的数据做一套根据用户id分库的数据，实现根据用户和订单都可以查询且不影响效率

借助NoSQL特性助力业务场景

MongDB

• 面向集合
• 适合高QPS读写，大对象存储

Redis

• key—value数据库
• 必须拿到key才能找到value，不能反向查询
• 业务缓存
• 限流、计数器

GraphQL

• 网状关系
• 图数据库

HBase

• 列数据库
• 适合大量数据，不适合小量数据（因为会做压缩）
• 适合聚合操作

ES

• 全文检索
• 分词
• 倒排索引：通俗理解就是通过value找到key

数据冗余——反范式设计

• 大宽表，用冗余数据提升查询效率

阿里系的数据订正流程规范

• Owner：数据库的创建者
• DBA：负责线上数据的规范，提出SQL性能调优的建议
• 一线码农：一般只有read权限

1. 提交变更给owner，需要执行的sql和预计的结果
2. owner审核
3. 手动执行

• 内部开放权限：Owner + DBA把控（因为相信，所以简单）

阿里开源项目Driud监控SQL效率

面试题

除了主从外，你还在项目中应用了那些其他的容灾备份手段

冷备 + 热备（数据实时镜像、同步）

数据异构方案的设计（数据迁移）

Canal是这类问题的终结者

场景设计题——底层存储

• NoSQL：根据场景特征选取合适的NoSQL数据库
• 互联网业务为了保证查询速度，都会有数据冗余

谈谈MySQL的同步方式

• BinLog方案
• Canal方案：基于BinLog的中间件