分布式数据库思考以及Oracle RAC如何处理多主的事务管理？

最近看分布式相关的资料，分布式数据库如何保证事务的一致性的，如何做MVCC的版本控制。

CAP原理：

一致性（Consistency）：保证分布式集群中每个节点都返回相同、最近更新的数据，也就是任意时刻所有节点看到的数据是一样的。这是强一致性，也叫做原子一致性。就保证事务的一致性和数据的一致性也可以理解为MVCC隔离一致性。

可用性（Availability）：每个非失败节点在合理的时间内返回所有读取和写入请求的响应。表示即使是有节点坏了，也应该有备用节点替代，保证对外服务不中断。

分区容忍性（Partition Tolerance）：尽管网络可能出现抖动或者分区，仍要保证系统的正常运行和一致性。表示即使网络出现隔离，那么系统仍要是可用的，不会出现脑裂已经不可用。

分区容忍性是一定要实现的，那么在可用性和一致性方面就要有所取舍，就衍生出了最终一致性和最终可用性的说法。

BASE原理：

BA（Basicall Availabilty）：基本可用，出现故障时，允许可用性低一点，只要保证最终是可用的，不会出现故障就导致集群无法使用，数据丢失；可用通过多副本和副本分布的算法，保证最终能恢复集群，时间可以久一点都可以。

S（Soft State）：软状态，允许系统存在中间状态，但中间状态不影响系统整体可用性。单机数据库的一致性表示数据库的事务不能破坏数据库的完整性和一致性，事务的执行前和结束，数据库都是一个一致性的状态。如果执行中出现故障，已经有一部分数据写入磁盘，那么这就不是一致性的状态。就需要通过undo的方式抛弃这个事务，数据库达到一致性。

E（Consistency）：最终一致性，系统中所有的数据副本不管多少时间，只要最终能达到一致的状态。也即是commit成功了，那么不管用什么技术，能保证所有的副本都commit成功了。

那么在一致性和可用性方面，就需要实现：

分布式事务的一致性：相应的技术2PC、3PC。

每个节点看到的数据是一样的：节点实时cache所有的变化信息，事务的MVCC隔离技术要一致，不能某些节点看到的事务要高，某些低，那么数据的可见性就错了。常见的有三种：

1）基于事务的快照，每个节点都获取当前活跃的事务快照。这样事务的快照就要是全局的，且更新非常频繁。

2）基于原子时钟+GPS，也就是Spanner的实现。虽然时钟会定时的同步，但是有也存在一点延迟，一般在几毫秒。

3）基于逻辑时间从TSO上获取时间，这样的时间同步的频率和本地时间差可能要差一点。

对数据做多副本：相应的技术是主从流复制、Raft、Paxos等算法来实现。

那么在Oracle RAC的多主可写，各个实例用有自己独立的redo、undo日志的情况下，怎么做到事务和数据的一致性、MVCC版本控制的呢？

事务的一致性怎么保证？是否有一个全局的事务管理服务，他的SCN对全局有效的，如果能保证这个事务的顺序，已经提交事务的全局刷新，确实是可以让每个节点写自己的redo和undo，但这样的OLTP的性能怎么没有受影响？

下面是查了一些资料，但没有详细说明RAC的事务处理过程：

下面的参考自：https://www.cnblogs.com/andy6/p/6016161.html

读一致性

Oracle数据库的主要特征之一就是能同时提供不同视野下的数据，这个特征叫做多版本读一致。查询是读一致的，写不会阻塞读，反之亦然。当然，多版本读一致对RAC一样有效，但涉及到一点其他的工作。

System Change Number(SCN)是一个Oracle的内部时间戳，对读一致非常重要。如果本地实例请求一个块的读一致版本，它需要联系这个块的resource master来确定这个块是否有相同SCN的版本，或者更新的版本存在于某个远程实例的buffer cache中。如果这个块存在，那么resource master会发送请求给相应的远程实例来转发这个块的读一致版本给本地实例。如果远程实例持有这个块的请求时间SCN的版本，那么它会马上发送这个块。如果远程实例持有的是这个块更新的版本，它将创建这个块的拷贝（称为前镜像），并对这个拷贝应用回滚使其回到对应的SCN的状态，然后将其通过内部连接发送。

 

System Change Number(SCN)

 

SCN是Oracle数据库产生和使用的内部时间戳，数据库中发生的所有事件都以SCN标记，事务也一样。Oracle的读一致严重依赖于SCN和undo表空间中的信息。SCN需要在集群中同步，RAC中用来使SCN在所有节点间通用的方案有两个：broadcast-on-commit和Lamport。

broadcast-on-commit是10.2以后的默认方案，它解决了Lamport方案的一个问题：在以前，这个默认方案是Lamport，它承诺了更好的扩展性，让SCN像集群其他通讯一样来传播，但并不是在一个节点中commit后马上发生。这在大部分情况下都能满足要求，但是，Lamport方案有一个问题：一个节点的SCN相对另一个节点的SCN有延时是可能的，特别是在在消息传送不活跃的时候。这种SCN的延时意味着在一个节点上提交的事务从另一个延时的实例上“看起来”会有点太新了。

另一方面，broadcast-on-commit方案更加资源集中一点。LGWR进程在每次commit之后更新全局的SCN并将其广播到所有的其他实例中。在RAC11.1中，初始化参数max_commit_propagation_delay允许数据库管理员来修改默认的设定，这个参数在11.2中被移除。

转载：http://blog.sina.com.cn/s/blog_5fe8502601016avf.html

另一个：

https://stor.51cto.com/art/201811/586519.htm

RAC 并发(DLM-->GRD)

RAC 的本质是一个数据库，运行在多台计算机上的数据库，它的主要任务是数据库就是事务处理，它通过 Distributed Lock Management(DLM:分布式锁管理器) 来解决并发问题。因为RAC的资源是共享的，为了保证数据的一致性，就需要使用DLM来协调实例间对资源的竞争访问。

RAC 的DLM 就叫作 Cache Fusion。

在DLM 中，根据资源数量，活动密集程度，把资源分成两类：Cache Fusion和Non-Cache Fusion。

Cache Fusion Resource指数据块这种资源，包括普通数据库，索引数据库，段头块(Segment Header),undo 数据库。

Non-Cache Fusion Resource是所有的非数据库块资源, 包括数据文件，控制文件，数据字典，Library Cache，share Pool的Row Cache等。Row Cache 中存放的是数据字典，它的目的是在编译过程中减少对磁盘的访问。

在Cache Fusion中，每一个数据块都被映射成一个Cache Fusion资源，Cache Fusion 资源实际就是一个数据结构，资源的名称就是数据块地址(DBA)。每个数据请求动作都是分步完成的。首先把数据块地址X转换成Cache Fusion 资源名称，然后把这个Cache Fusion 资源请求提交给DLM， DLM 进行Global Lock的申请，释放活动，只有进程获得了PCM Lock才能继续下一步，即：实例要获得数据块的使用权。

Cache Fusion要解决的首要问题就是：数据块拷贝在集群节点间的状态分布图， 这是通过GRD 实现的。

GRD(Global Resource Directory)

可以把GRD 看作一个内部数据库，这里记录的是每一个数据块在集群间的分布图，它位于每一个实例的SGA中，但是每个实例SGA中都是部分GRD，所有实例的GRD汇总在一起就是一个完整的GRD。

RAC 会根据每个资源的名称从集群中选择一个节点作为它的Master Node，而其他节点叫作Shadow Node。 Master Node 的GRD中记录了该资源在所有节点上的使用信息，而Shadow Node的GRD中只需要记录资源在该节点上的使用情况，这些信息实际就是PCM Lock信息。PCM Lock 有3个属性： Mode，Role 和 PI(Past Image)。

理解Google Spanner(3)：分布式事务原理与实现：

https://www.jianshu.com/p/45d10cee1773?utm_campaign=haruki