多副本数据库的一致性与分布式事务处理

报告人：东北大学 张岩峰
报告链接： https://www.bilibili.com/video/BV14u411S7yX?spm_id_from=333.999.0.0

背景

多副本数据库：通过网络在多台机器上保存相同数据的副本。

优势：

• Data Locality（数据局部性）：使数据在地理位置上更接近用户，从而降低访问延迟；
• High Availability（高可用）：当部分组件出现故障，系统依然可以继续工作，从而提高可用性；
• Read Throughput（读吞吐量）：扩展至多台机器以同时提供数据访问服务，从而提高读吞吐量。

主要内容

典型的数据复制架构

主从复制

• 写操在在主节点，读操作分摊到从节点
• 大多数数据库都采用这种方式（MySQL、openGauss）
• 日志重放写数据，WAL
• 优点：写冲突处理简单
• 缺点：写负载集中

多主复制

• 各节点都支持读写，分摊读写操作，适合跨区域场景
• MySQL Tungsten、PGSQL BDR、Bitcoin、Fabric、区块链
• 需要解决跨节点写冲突
• 优点：多写分摊读写负载
• 缺点：写写冲突

无主复制

• 放弃主节点，各节点支持读写部分数据
• Dynamo、Cassandra、Riak
• quorum读写，w（写成功副本数）+ r（读成功副本数）> n（整个集群的节点数）
• 优点：较好的写性能，适合KV数据库
• 缺点：最终一致性，不适合关系数据库，无法保证某一行的数据一致性

数据分片+复制

• 把大表切分成更小的切片
• 分割后的数据块会分布在多个服务器中
• Hash划分，Range划分
• 优点：
  • 水平扩展，提升扩展性能
  • 热点均衡，减少资源争用
• 缺点：会出现跨主机节点的事务，保证ACID的开销会比较大

多副本分布式事务一致性方案

• 事务一致性：ACID中的C，可串行化
• 副本一致性：CAP中的C，各个副本状态保持一致性
  • 结果一致性
  • 次序一致性
    • 线性一致性（强一致性）
    • 顺序一致性（强一致性）
    • 因果一致性
    • 最终一致性

分布式事务一致性：事务一致性 + 次序一致性

方案一

• 读写操作事务在主节点
• 只读操作在从节点
• 没有跨节点事务
• 单机的事务处理技术+同步复制

问题：

• 读写过于集中在主节点
• 数据分片导致跨节点事务

方案二

• 跨节点事务
• 写操作在主节点
• 封锁/TO+2PC

问题：

• 死锁、活锁
• 需要一个全局时钟

全局时钟

• TrueTime
  • 原子钟+GPS
  • 机器之间时间戳不会超过一个阈值
  • Google Spanner
• TSO
  • 集中式时间戳管理
  • TiDB
• HLC
  • 物理时钟和逻辑时钟结合
  • CockroachDB

多主架构分布式事务一致性方案

方案一

• 各节点都接收事务，要处理写写冲突
• 封锁/TO+2PC+全局时钟

问题：

• 协调开销大
• 问题更复杂

方案二

——可参考区块链系统

• 各节点都接收事务
• 选出一个节点做做事务的排序（Bitcoin POW）
• 有个排序服务，单节点或PBFT（Fabric）
• 并行执行，串行排序，冗余验证（Hyperledger Fabric）

**问题：**排序共识开销大

方案三

• 各节点都接收事务
• 按批次交互
• 确定性排序
• Calvin [SIGMOD 2012]，Aria [VLDB 2019]

问题：

• 通信开销大
• 写放大

方案四

• 利用操作单调性的数学性质CALM，CRDT
• 业务对顺序不敏感
• 投票（counter），购物车（集合并集）
• Berkeley Anna [ICDE 2019]

**问题：**最终一致性

总结

• 优势：
  • 多写架构，更适合跨区域场景
  • 数据局部性
  • 可扩展的读性能
• 难点：
  • 性能：一致性 vs 写性能
  • 扩展性：写放大开销 vs 数据局部性收益

事务的ACID vs 多副本的ACID

	事务	多副本更新
定义	时间维度上的一些操作	空间维度上的一些副本更新
原子性	一个事务的（时间）操作序列，在一个数据表上：或者都做、或者都不做	一个更新在（空间）多个副本，在一个时间点（段）：或者都做、或者都不做
一致性	在一个数据表上，几个并行执行的事务，执行结果必须与某一串行执行顺序的结果相一致	在一个时间点上，在不同副本上的几个不同的更新操作，更新结果必须与按某一个更新操作顺序的结果相一致
隔离性	事务的执行不受其他事务执行的干扰，不同事务在不同时间上的结果，在空间上的可见性	副本的更新不受其他副本更新的干扰，不同副本在不同空间上的更新结果，在时间上的可见性
持久性	一个事务执行结果落盘到空间上	一个多副本更新结果在某个时间确认更新到所有副本

总结

跨区域数据库（分布式事务一致性）

• Spanner系列，CockroachDB，TiDB
• 跨域部署，性能并不理想
• 分析原因：
  • 分片架构和跨节点事务
    • 需要昂贵的跨域协调机制
  • 事务为粒度的副本一致性
    • 极致的事务一致性和副本一致性（可串行化和线性/顺序/因果一致性）
    • 依赖全局时钟的一致性保证,事务为粒度的副本一致性,开销巨大

GeoGauss

* 全副本多主架构（本地事务处理）
* epoch冲突合并（epoch粒度副本一致性）
* Epoch 10ms

实验结果