目录
报告人:东北大学 张岩峰
报告链接: 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
实验结果