数据备份和失效转移
数据备份
-
冷备(历史订单、业务报表、时效性不高):最最最坏情况下才会用
- 低成本
- 定时
- 数据丢失
- 不一致
-
热备
- 同步热备(一个库提交成功,别的提交失败,不容易控制)
- 主从热备
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权限
- 提交变更给owner,需要执行的sql和预计的结果
- owner审核
- 手动执行
- 内部开放权限:Owner + DBA把控(因为相信,所以简单)
阿里开源项目Driud监控SQL效率
面试题
除了主从外,你还在项目中应用了那些其他的容灾备份手段
冷备 + 热备(数据实时镜像、同步)文章来源:https://www.toymoban.com/news/detail-441792.html
数据异构方案的设计(数据迁移)
Canal是这类问题的终结者文章来源地址https://www.toymoban.com/news/detail-441792.html
场景设计题——底层存储
- NoSQL:根据场景特征选取合适的NoSQL数据库
- 互联网业务为了保证查询速度,都会有数据冗余
谈谈MySQL的同步方式
- BinLog方案
- Canal方案:基于BinLog的中间件
到了这里,关于08-03 底层数据设计策略——高可用数据的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!