开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第14天，点击查看活动详情
@[toc]
第三章：OceanBase集群技术架构
4. 分布式事务、MVCC、事务隔离级别
4.1 分布式事务跨机执行时，OceanBase通过多种机制保证ACID
4.1.1 原子性Atomicity
原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生
依赖两阶段提交协议保证分布式事务的原子性
4.1.2 一致性Consistency
事务前后数据的完整性必须保持一致
保证主键唯一等一致性 约束 全局快照 - 单租户GTS服务，1秒钟内能够响应获取全局时间戳的调用次数超过200万次
4.1.3 隔离性Isolation
多个用户并发访问数据库时，数据库为每个用户开启的事务，不能被其他事务的操作所干扰
采用MVCC进行并发控制，实现read-committed的隔离级别 所有修改的行加互斥锁，实现写 - 写互斥 读操作读取特定快照版本的数据，读写互不阻塞
4.1.4 持久性Durability
一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响
Redo-Log使用Paxos协议做多副本同步
4.2 因服务器时钟差异，分布式数据库ACID挑战更大
和传统的数据库的单点全共享（即Shared-Everything）架构不同，OceanBase是一个原生的分布式架构，采用了多点无共享（即Shared-Nothing）的架构，在实现全局（跨机器）一致的快照隔离和多版本并发控制时，会面临分布式架构所带来的技术挑战
4.3 OceanBase全局一致性快照技术
OceanBase数据库利用一个集中式服务来提供全局一致的版本号。事务在修改数据或者查询数据的时候，无论请求源自哪台物理机器，都会从这个集中式的服务处获取版本号，保证所有的版本号单调向前并且和真实世界的时间顺序保持一致
4.4 创新的两阶段提交，任何故障均可以保障事务的原子性
4.4.1 技术难点
依赖两阶段提交协议保证事务原子性 两阶段提交：状态多、复杂、状态机容易卡住
4.4.2 OceanBase两阶段提交协议特点
事务协调者和所有参与者都是高可用的 单机多分区事务，所有参与者都prepare成功即认 为 事 务 进 入 提 交 状 态 ， 立 即返回 客 户 端commit 全自动处理异常情况
4.5 多版本并发控制（MVCC），解决读写互斥问题
4.5.1 MVCC核心功能
采用锁机制控制读写冲突时，加锁后其他事务无法进行读，导致读写竞争，影响读的并发度。MVCC可以有效解决该问题： • 全局统一的数据版本号管理，取自全局唯一的时间戳服务（GTS） • “读”、“写”操作都要从GTS获取版本号；同一个租户内只有一个GTS服务，可以保持全局（跨机）一致性 • 修改数据：事务未提交前，数据的新旧版本共存，但拥有不同的版本号 • 读取数据：先获取版本号，再去查找小于等于当前版本号的已提交数据 • 写操作获取行锁，读操作不需要锁，有效避免读写锁竞争，提高读写并发度
4.6 事务隔离级别（Isolation Level）
保证全局数据一致性的隔离级别
4.6.1 事务并发问题
脏读：读取了未提交的数据 不可重复读：指的是在同一事务内，不同的时刻读到的同一批数据可能是不一样的（期间被别的事务更新数据） 幻读：指的是在同一事务内，在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据（期间被别的事务插入或者删除了数据）
4.6.2 OceanBase支持多种事务隔离级别
基于全局一致的数据版本号管理，以不同的版本号策略实现不同的隔离级别 Oracle模式支持以下两种隔离级别，应用系统可以根据需求权衡使用任何一种隔离级别： Read-Committed：避免脏读，存在不可重复读和幻读（默认） Serializable：避免脏读、不可重复读、幻读 MySQL模式支持读已提交、可重复读两种隔离级别 不支持脏读（Dirty-Read），只能获取已提交数据
4.7 MVCC实际案例
MVCC实际案例（结果演示）
4.8 小结
本章节主要介绍OceanBase集群的OB Server如何协同工作来实现负载均衡、高可用、分布式事务等特性： • 每个分区的多个副本组成Paxos组，一般情况下由主副本对业务提供读写服务，主从副本之间通过同步Redo-Log日志确保数据的强一致性。主副本无需等待所有从副本的Redo-Log日志落盘,只要满足多数派落盘即可,这将提供更好的性能 • 一般情况下，副本以及主副本将被均匀打散到Zone内各个服务器中（与租户资源池一致），实现自动负载均衡，避免各个服务器忙闲不均 • 少数派故障,多数派将自动选出新的主副本,确保不影响业务 • OB Proxy是一个”无状态“的服务进程，不做数据持久化，对部署位置无要求 • OceanBase可以提供RPO=0，RTO<30秒的高可用，意味着当少数派故障时，OceanBase能够在30秒内恢复业务，且不会丢失任何数据 • OceanBase提供同城三机房三副本及三地五中心五副本的方案，同时为了利旧企业已有基础实施，也提供传统的同城两机房主备方案及两地三中心主备方案
