cantian引擎的介绍
专栏内容：
参天引擎内核架构
本专栏一起来聊聊参天引擎内核架构，以及如何实现多机的数据库节点的多读多写，与传统主备，MPP的区别，技术难点的分析，数据元数据同步，多主节点的情况下对故障容灾的支持。手写数据库toadb
本专栏主要介绍如何从零开发，开发的步骤，以及开发过程中的涉及的原理，遇到的问题等，让大家能跟上并且可以一起开发，让每个需要的人成为参与者。
本专栏会定期更新，对应的代码也会定期更新，每个阶段的代码会打上tag，方便阶段学习。
开源贡献：
文章目录
前言
国内数据库的发展如火如荼，每年的各种大会都会听到好消息，今年除了数据库本身的各种技术演进之外，华为发布了参天引擎，而且是做为数据库的一种基座形式，也就是所有数据库可以在参天引擎基础上，构建形成多主分布式架构的数据库系统，这也就是它叫引擎的目的。
本专栏就来详细聊一聊参天引擎内部架构，以及如何适配参天引擎。
概述
据华为官网发布的新闻，题为：华为宣布CANTIAN引擎开源，携手共建数据库存储新生态，已经有万里数据库适配完成，万里数据库是基于mysql，也就是说mysql与参天引擎结合成功，达到了分布式数据库集群，基于共享存储的多主效果。
华为在数据库方向上开源了GuassDB之后，又宣布开始了参天引擎，这又是什么神器呢，今天我们就一起来看一看。
cantian引擎是什么
随着数据库国产化的推进，基础模型的数据库大多都与国外品牌有了对标产品，比如说主从，延伸出来的一主多从，读写分离等，已经很成熟，也有很多中间键可以应用开源数据库mysql,postgresql都有类型部署模式；
还有MPP模式，也就是元数据在master节点，通过切片将实际数据放在worker节点，已经有开源的citus, greenplum等数据库支持；
但是对于数据库巨头oracle的 oracle RAC产品对标产品一直没有进展，也就是说它还不能被很好的替代。
oracle RAC主要特点是高可用，不是其它一些模型能达到了，而华为cantian引擎的出现，就是干了这么一件事，可以对标oracle RAC了。
oracle RAC其实是一种基于共享存储的分布式集群架构，从上图可以看到，集群中的每个数据库节点都访问同一份相同的数据，同时每个数据库节点都可以进行读写操作，比如两个节点上同时可以对同一张表进行插入数据操作。
这种架构模型下，集群中一个节点故障后，其它节点完全可以接管所有业务。
参天引擎的目标是让数据库具有“分布式架构+集中式体验”的多主架构数据库，它通过client,server, 存储三层，将传统单机数据库，如mysql,postgresql与client进行结合，从而改造成多主的分布式集群式数据库。
换句话说，参天引擎可以是一种标准服务，只要数据库系统与client进行改造对接后，就可以使用server,存储层，这样就可以支持多主的分布式架构。
多主分布式架构的特点
oracle RAC类型的共享存储下的分布式数据库，有什么特点，或者它的优势在那里呢？
在历年的oracle RAC白皮书中反复提到这几个特性，而且对它们进行持继的更新演进，当然也是多主分布式架构的最核心特点。
高可用
集群中的多个节点完全对称，也就是任意两个节点是一模一样的，这就是说业务可以运行在任意节点上，真实使用时只是通过负载均衡将业务分散到了各节点上，使负载达到了均衡。
各节点对称，这一特性使得当任意节点故障时，业务可以立马转移到其它节点上，这与主从架构，MPP架构完全不同。
主从架构中，只有主具有处理所有业务的能力，从节点具有处理只读业务的能力，当主节点故障时，需要重新选主，再进行业务切换；
而MPP架构中，特点区分更加明显，它具有两个节点角色，对于master角色的节点，只存储元数据，也即数据分布信息，它的高可用一般也采用一主多从的形式，故障时处理与主从是一样的；而对于worker角色的节点，它们存储了一部分分片的数据，它们一般通过多副本机制达到冗余备份的高可用，故障节点的数量不能超过副本数量，副本越多管理成本越高。
按照oracle RAC最新的版本，这个故障处理的能力已经非常丝滑，可以达到事务级别的转移，这在其它两个架构，由于架构的限制很难做到。
业务连续性的用户体验，这在一些关键应用中体现非常重要，这里借用oracle rac技术白皮书中的一张图来说明。
扩展性
当然对于多主架构，集群中增加一个节点，业务负载就可以立即分担；同样减少一个节点时，对应业务负载也可以转移到剩余节点上。有点像现在的云部署的感觉，通过自动化的控制，完全可以按照业务负载调整资源的使用情况。
当然，这在其它架构也是很难达到的。
应用无修改
经过几年的数据库国产化后，这一点体验比较深刻，现在都会支持单机，主从，MPP部署，但这三种都需要应用能够做一些适配，尤其MPP部署，需要这种应用的业务要完全适合此种架构，就有很多限制，比如复杂联合查询就要特别当心了，最好提前能够整改了。
而对于多主分布式架构，这些情况都不存在，不需要区分只读，读写业务，也不需要担心SQL的不支持，单机部署也开发正确，在多主分布式架构下就是可以的；
这大大简化了业务应用的开发，同时对于业务应用架构设计的成本也降低了，不需要对每种数据库的限制深入了解。
多主分布式架构的技术难点
多主的分布式架构为什么迟迟在国内没有大的推进呢，它主要有几大技术难点，每个难度都是一个重量型的开发，所以对企业，尤其是资本业讲，很难在短期得到收益。
数据库元数据的同步
对于多主的分布式系统，最先面临的就是元数据的多机同步，数据库也是一样，在多写的情况下，每个节点都会产生元数据，需要实时同步。
数据库分布式锁
多节点如果访问同一数据元素时，需要进行加锁，那这个锁不再是单机系统下的某个内核变量，而是要扩展到分布式下多节点间的锁，在多节点起到加锁互斥的效果。当然在分布式下有很多实践，但是数据库这样高频使用场景下，如何能提高性能是不得不考虑的问题。
多节点事务一致性
在数据库概念专栏，分享并发控制的可串行化相关内容，那些都是单机架构下的，如何在多节点时做到事务的并发一致性，需要将封锁，时间戳，有效性确认几种方式扩展到多节点。
其中事务号，也就是事务时间戳的实现，就有好几种方式，如时钟，统一分发的序号等等。
多写下的恢复
多个节点都可以写入数据，那么故障时，如何恢复，数据的一致性又如何保障呢？
比如两个节点修改了数据，它们的先后顺序的确定，单机也是由日志的时间戳方式进行排序，而多机时，如何使用统一的日志，那竞争必然加大。
在数据库概念专栏中对于恢复，分享了几种技术，如redo, checkpoint等，那对于redo，checkpoint都需要日志先落盘，或者对日志进行回收处理，在多节点间如何保障日志先于数据落盘。
多机共享文件系统
当然以上各点都是对于数据库来讲的，对于基于共享存储的多主分布式架构，还有一个重要的技术难点，就是文件系统。
假如多个节点同时对一个表文件进行写入，或者扩展，传统的ext4,xfs肯定是不行的，多节点各自部署在独立的服务器上，对应着多个操作系统，各自的文件系统元数据是不交互的，此时就会混乱。
而对于分布式文件系统，一般都会将元数据缓存在客户端，也就是每个使用者的机器上，会导致更新不及时。
参天引擎可以做什么
从华为官方发布的消息来看，已经与厂商合作适配成功了，也达到了多主分布式集群的效果，从其它媒体发布的消息来看，测试的数据还是不错。
目前看起来对于mysql进行了适配，另一个主流开源数据库postgresql还没有看到消息，其它也没有看到更多介绍的文档。
既然开源了，那接下来我们就从源码角度看看，参天引擎可以做什么，拿postgresql来适配的话，难度会有多少。
结尾
非常感谢大家的支持，在浏览的同时别忘了留下您宝贵的评论，如果觉得值得鼓励，请点赞，收藏，我会更加努力！
作者邮箱：[email protected]
如有错误或者疏漏欢迎指出，互相学习。