今天听了一下某国产数据库RAC共享集群技术的在线分享，虽然讲得比较简单，但是也大概了解了一些内容。
从分享的架构来看，大致分为几层，Cohesive memory(类似Oracle rac cache fusion), 心跳网络，gls/grc/gcs，yfs以及ycs。其中yfs是文件管理系统，类似Oracle ASM，可以管理裸盘。
对于共享集群架构来讲，其性能的高低完全受限于中间的内存融合技术，也就是提到的Cohesive memory。从分享的材料来看，看上去也是略微简单：
我认为这个处理逻辑是非常简单的，相比Oracle的cache fusion极致来讲,另外看介绍说有自适应调整技术，可以优化不知道具体怎么实现的，以及效率如何。看上去似乎也就是脏数据+undo进行回滚，来走过一致性块，跟Oracle CR构造类似。
从分享讲师的说法来看，也使用了一致性hash算法来进行处理；实际上Oracle 10g RAC也是使用了一致性hash，同时还有预读操作；11g版本做了cache fusion做了优化，主要通过mostly read/write/lock技术（本质上仍然是判断对象的affinity），来降低通讯代价，尽可能的让本地节点多一些操作；到Oracle 12c版本中，进一步做了优化增强，Oracle称为智能区分，实际上就是更加智能到讲读的更多的block 放到本地节点，提升集群效率。
但是根据我们的经验来看，我想99%的Oracle DBA在安装rac集群的时候，都会关掉11g版本引入的mostly 特性，因为Bug实在是太多太多了。。。
另外从架构上看，提到有多种心跳机制，但是没有解释清楚，从图来看其实就2种。
实际上我们知道Oracle的心跳有3种，控制文件心跳、网络心跳、磁盘心跳。接下来我们看看最为重要的部分，那就是MVCC的实现机制。
从公开材料来看提到3种存储引擎机制，分别是append-only、in-place update (row),in-place update(block)。看名字我们就知道，这不就是openGauss中提到的2种存储引擎吗。astore和ustore。其中ustore目前还不够成熟，暂时还无法商用。
实际上Ip-place update （block）这个机制，就是跟Oracle undo mvcc 一样，至少大体上来看是一样的。如果不信，大家可以去看看Oracle DSI。
当实现了block级别的in place update之后，那么就可以多更多的事情了，比如闪回查询操作。
因此上面这个图就没有什么可讲了。
对于共享RAC集群，我们知道每个节读写是需要共享的，因此就需要同步一些关键操作，比如图中提到的SCN。实际上Oracle RAC集群是有sync scn的操作的；除此之外实际上还有全局flush sync redo的动作，当然这是另外一个话题。
我们来看看该数据库是怎么做的。
从ppt介绍来看，集群节点间scn同步使用了广播机制。我记得很早之前看Oracle文档提到，scn同步大致有2种方式，其中是Lamport 和Broadcast。lamport 表示每个节点自己产生自己的scn，然后会去做比较，选择使用大的scn；而广播就是广而告之，本地事务commit产生的scn会广播通知到其他节点。而Oracle 在早期是使用lamport方式，从10.2版本开始，默认使用了广播的机制。
很显然，单看ppt介绍，该国产数据库也是用了类似的机制。最后从其公开的节点故障转移的情况之下，RTO大约有接近20s的时间，看上去还是有点长。
其中中间凹陷的部分就是时间，代表该时间段内集群基本上是不可用的状态。
我们知道Oracle RAC实际上也有类似的问题，当一个节点突然crash之后，存活节点需要进行进行资源的reconfig操作，这期间要做很多事儿，实际上很早之前我研究就发现，Oracle 仍然在不断优化这个reconfig的过程，本质上就是资源remaster的过程。
根据我的理解，这个Oracle RAC 的这个reconfig 过程一般不会超过5s，大多数情况下就1-2s。
实际上除了这个数据库平台，据我了解达梦数据库也在2020年推出了dmdsc集群，人称DM-RAC，此外KingBase 也推出了kingbase RAC。目前从一些网友的的讨论观点来看，似乎都还不太成熟，都不建议使用。---当然这是网友们的观点。
实际上对于Orace RAC来讲，我们知道最早在98年推出了8i OPS（并行服务器，就是RAC的前身），2001年推出了Oracle 9i RAC，2005年才推出Oracle 10.2 RAC版本（实际上之前2004年推出的oracle 10.1版本几乎没人用，而且10.1版本 rac 资源remaster机制很弱，只能基于文件级别，完全无用，10.2版本才引入了dynamic reamster机制）。因此我们都能看到很多客户真正使用Oracle RAC相对普及的是Oracle 10.2版本（尽管以前个别客户也有Oracle 9i RAC，我记得2011年去某招聘网站做数据库巡检，他们使用的是Oracle 9208 RAC）。
在很多人眼中，尤其是甲方客户眼中，认为Oracle 10g rac都不可靠，可能主要是由于之前rac的很多机制还不友好，加上以前网络条件也有限，能用千兆心跳网卡的都不多，那么自然没法用好RAC了。
实际上根据我的经验，之前还是有不少客户使用Oracle 10.2.0.4 RAC集群，还是非常稳定的。但是Oracle 10.2.0.4 这个版本是2008年才发布的。
因此从98年的8i OPS到 2008年的Oracle 10.2.0.4,大概经历了10年。
因此大家认为国产数据库的RAC集群架构成熟还需要几年？
# # 写在最后，如果大家对国产数据库MogDB有兴趣或者想了解更新技术相关文章，可以关注MogDB的公众号，后续也会有一系列技术文章和视频推出！ MogDB 技术讨论群已经满，如有兴趣，可以添加我的微信(Roger_database)，我邀请入群！
如需了解更多详情如白皮书、异构数据迁移方案等请移步www.mogdb.io
如果你是软件开发商申请数据库适配，请联系市场营销marketing@enmotech.com
