基础部分

总结

  • 分布式数据库特性:写多读少、低延迟、海量并发、海量存储、高可靠性、关系型数据库
  • 分布式数据库内部演化视角
    • 客户端组件 + 单体数据库,sharding-jdbc
    • 代理中间件 + 单体数据库,mycat
    • 单元化架构 + 单体数据库
  • 一致性模型
    • 分布式系统,探讨当系统内一份逻辑数据存在多个物理副本时,对其读写操作会产生什么影响,CAP理论
    • 数据库领域,于事务相关,进一步细化到ACID四方面
  • 数据一致性
    • 状态一致性 state consistency,数据所处的客观、实际状态所体现的一致性
    • 操作一致性 operation consistency,外部用户通过协议约定的操作,能够读取到的数据一致性
    • 强一致性
    • 弱一致性,最终一致性
      • 写后读一致性,读自己写一致性
      • 单调读一致性
      • 前缀一致性,因果关系
      • 线性一致性 linearizability,全局时钟
      • 因果一致性,逻辑时钟
    • 排序:线性一致性 > 顺序一致性 > 因果一致性 > {写后读一致性、单调一致性、前缀一致性}
    • 其他:
      • 有限旧一致性
      • 会话一致性
      • 单调写一致性
      • 读和写一致性
  • 事务一致性
    • WAL
    • 主从复制、基于paxos/raft的共识算法日志数据
    • SQL-92定义的四种隔离级别没有考虑到快照问题,少了一些情况
    • 幻读和写倾斜
  • 数据库的基本架构
    • 客户端通讯管理器
    • 进程管理器
    • 查询处理器
    • 事务存储管理器
    • 共享组件和工具
  • 架构风格
    • PGXC 单体数据库演进的架构
    • NewSQL风格,spanner架构
  • 全局时钟
    • 时间源:单个还是多个
    • 使用的时钟类型:物理时钟、混合逻辑时钟
    • 授时点:一个还是多个
    • 分类
      • TrueTime,多时间源 + 多点授时 + 物理时钟
      • HLC,多时间源 + 多点授时 + 混合逻辑时钟
      • TSO(Timestamp Oracle),PGXC架构中的GTM,单时间源 + 单点授时 + 混合逻辑时钟
      • STP(SequoiaDB Time Protocol)巨杉数据库的方式,单时间源 + 多点授时 + 混合逻辑时钟
  • 分片策略
    • hash分片,一致性hash;属于静态分片,写性能好
    • range分片-静态,PGXC风格 查性能好
    • range分片-动态,newsql风格,如bigtable这样的
    • 分片 + 共识
  • 数据复制
    • 静态分片
    • TiDB,无存储状态,每次上报全副本,方便raft选主
    • CockroachDB,去中心化,采用p2p方式大规模部署效率高
    • raft复制的问题:基于顺序投票,不能出现空洞
    • TiDB的raft优化
      • 批操作提交日志
      • 流水线,没发送一个batch后,不等follower,立刻进行下一个
      • 并行追加日志,发送给follower的同时,并发执行本地的append日志
      • 异步应用日志

分布式数据库的强一致性
左边的是事务一致性,最高等级是:可串行化;右边是数据一致性,最高等级是:可线性化

不同数据库的一致性比较

数据库的架构风格

PGXC风格的架构

NewSQL风格的架构

全局时钟的设计方式

分片类型

论文

分布式事务

总结

  • 原子性
    • Either all the changes from the transaction occur(writes, and messages sent), or none occur.
    • 实现事务原子性的两种协议
      • 面向应用层的TCC,try confirm cancel
      • TCC是应用层的分布式事务框架,完全依赖应用层编码
      • 面向资源层,2PC协议
      • 2PC的问题:同步阻塞、单点故障、数据不一致
    • 2PC的改进,NewSQL的Percolator
      • 需要数据库支持MVCC 多版本并发控制
      • 多个节点中只有一个节点拥有 主锁primary key,其他事务参与者指向主锁
      • 提交阶段就记录主锁,并记录最终数据(暂时不可见)
      • commit阶段,将主锁去掉,之后在读其他分片时,根据指向的主锁记录,可以认定为最终提交成功
      • 实际会有异步线程来处理从节点数据中的:指向主锁的信息
      • 2PC中的不一致,因为事务管理器只和主锁通信,单节点本身就是原子的,即可以解决一致性问题
      • 异步线程在事务管理器宕机后回滚分片上的事务
      • 事务管理器通过记录日志使自身无状态化,日志通过共识算法保存在其他节点
      • TiDB、CockroachDB都使用了Percolator算法

论文

数据库查询

实践部分

总结

  • 全球化部署
    • 异地多活
    • 单体数据库
      • 异地容灾
      • 异地读写分离
      • 异地双向同步
    • 分布式数据库
      • 机房级容灾(两地三中心五副本)
      • 城市级容灾(三地三中心五副本)
      • 三地五中心七副本
    • 架构问题
      • paxos风格的架构必须有一个主节点,一般在主机房
      • 只有一个全局时钟,异地写入增加通信延迟
      • 异地机器A获取的时间戳早,本地机器时间戳靠后,加上延迟,导致A写入比B迟,会失败
      • 类似问题:网购付款时会出现多个事务在短时间内竞争修改商户的账户余额
      • 全球化部署:多个时间源,多点授时,不同分片主副本可以分散在多个机房
    • 同城双机房
      • 为保证主机房高可用,raft在主机房部署多个副本
      • 理想的架构是:三地五副 + raft降级
    • follower read,源端读取无法保证一致性
      • CockroachDB支持,但无法保证一致性,TiDB的follower不支持跨机房部署
      • 利用raft无日志空洞,在数据密集情况下,日志时间戳 > 查询时间戳 即可保证最新
      • 分片数据比较冷时,将时间戳更新时间 附加到raft通信包中打包发送,其他节点判断
    • 全球化的意义
      • 真正的异地机房读和写
      • 异地机房如果是容灾需要定期演练,相比于时刻运行的系统,仍不能让人放心
  • 容灾与备份
    • 选择一个稳定成熟的逃生库
    • 异构数据库之间的复制方案
      • 数据文件,通过文件导入导出方式同步(全量)
      • ETL(Extract-Transform-Load)
      • CDC(Change Data Capture),业务入侵小
      • Oracle的OGG(Gold Gate)
      • DB2的Inforsphere CDC
    • 逃生方案
      • 日志格式适配,一般分布式数据库都兼容MySQL、PostgreSQL
      • 选择更强的单体数据库如Oracle,分布式数据库 -> 消息队列 <-> 逃生库 的架构
      • 事务一致性
    • 事务处理
      • 每个Raft Group的leader发送Raft日志
      • 难点在于跨分片日志的处理
      • 通过时间戳可以判断出 ts1 < ts2,然后重放ts1时刻的日志
      • ts1时刻可能产生了多条变更,逃生库在同一时间可能没有收到所有时间戳变更日志
      • CockroachDB引入了"Resolved"消息
  • 容器化
    • Kubernetes:
      • Container:Cgroup、Namespace、AUFS
      • Pod
    • 有状态服务,存储状态,还有状态拓扑,因为集群中不同角色作用不同
    • 底层基于分布式文件系统、挂本地盘方式
    • Operator:利用k8s自定义资源来描述用户期望的部署状态;在控制器里根据自定义API对象变化,完成部署和运维工作
    • 大数据可用性低于OLTP场景,但集群规模更大,更适合容器化
  • 产品测试
    • TPC-C(Transaction Processing Performance Council),国际事务性能委员会,针对OLTP场景
    • TPC-H 针对OLAP场景
    • 针对数据仓库建模又推出了TPC-DS
    • 开源的分布式一致性验证框架:Jepsen
    • 测试分布式数据库、键值系统、消息队列
    • 工作方式:Generator生成客户端操作;Nemesis实现故障注入;Checker分析每个客户端一致性
    • 混沌工程
      • 复杂性、实验、生成环境
    • TLA(Temporal Logical of Actions 行为时态逻辑)
      • 形式化验证(Formal Verification),用数学方法去证明系统是无Bug的
      • 需要用数学语言重写一遍,代价太高
      • 用TLA验证关键逻辑,剩余大部分靠测试验证
  • 银行案例
    • 工行OLTP:分布式中间件+开源单体数据库;OLAP联合华为GaussDB200,对标TeraData和GreenPlum
    • 邮政储蓄:PG,单元化架构,但是改造起来也很麻烦
    • 交通银行:自研NewSQL数据库CBase
    • 中信银行:自研GoldenDB,属于PGXC架构
    • 北京银行:OceanBase,南京银行也选用了这个数据库
    • 张家港银行:TDSQL
    • 城商行选择NewSQL的原因
      • 国产化诉求
      • 实际收益
      • 技术潮流
    • 光大银行:NewSQL+分库分表
    • 选型建议
      • 产品选型要服从项目整体目标
      • 先进的产品可能会延长项目交付时间
      • 当产品选型可能导致业务流程变更时,谨慎对待
      • 产品选中的非技术因素
      • 评估技术潮流对选型的影响
  • 分布式数据库
    • Spanner,F1(前端),兼顾OLTP和OLAP场景
    • CockroachDB
    • YugabyteDB
    • TiDB
    • PGXC,TDSQL、TBase、GoldenDB
    • VoltDB
    • SequoiaDB

全球化部署

同城双机房的退化模式

逃生库的分片日志复制方式

逃生库的事务一致性

Kubernetes架构

Kubernetes有状态存储-分布式文件系统方式

Kubernetes有状态存储-挂本地盘方式

论文

思维导图