开发者学堂课程【PolarDB-X 开源人才初级认证培训课程：入门介绍与部署】学习笔记（一），与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1075/detail/15541
入门介绍与部署
内容介绍：
一、PolarDB-X 发展史简介
二、PolarDB-X 产品介绍
三、资源介绍
四、开源 Roadmap
五、四种方式部署 PolarDB-X
一、PolarDB-X 发展史简介
PolarDB-X 这个产品的历史比较长，中间做过一些迭代和发展，在这节课开始学习一下产品发展的过程。
1、从阿里巴巴的“去 IOE”运动说起
他简单的历史可以追溯到2009年。03年淘宝成立，成立之后淘宝的业务发展非常快，后台的结构也会跟着迭代。2009后台数据库架构使用的是 IOE 这样一个组合。大家可能也听过去 IOE 这项运动。IOE 简单来说就是IBM的小型机、Oracle 数据库再加上EMC的高端存储，用它来作为后台系统，当数据量不是巨量的话，他是非常好用的，但是因为淘宝网数据规模非常多，所以09年的时候阿里巴巴内部发起去IOE运动，把这个架构给去掉。出发点是想用自己研发的分库分表TDDL+AliSQL（阿里自己研发的mysql分支）取代IOE这个组合，来解决两个问题。第一个是系统扩展性的问题，包括他并发的扩展以及存储扩展。第二个是把后台存储成本降低。这套组合是在2011年双11的时候成功的接管了核心库之一——商品库。验证了他的可行性，后来逐渐的推广开来，直到2013年IOE这项运动告一段落。最后 TDDL+AliSQL 这个组合就成为阿里巴巴所有业务接入数据库的标准，也就是说当前阿里所有的业务进入数据库，依然是这样一种方式。在2015年的时候TDDL 以中间件的形态在阿里云发布，成品的名称是 DRDS。如果之前有用过云产品的话，应该对这个名字是比较熟悉的，分布式关系型数据库服务。
2、从中间件到分布式数据库
上云之后这个产品一直持续的往下迭代，他迭代的点主要围绕的是解决在分库分表架构下一些难解决的问题。比如第一个是扩容，如果大家之前有运维过用分库分表支持的业务，会知道后台数据库的系统，比如如果要做扩容的时候还是非常麻烦的，就是他代价是非常高的。在16年的时候尝试用一个数据外部迁移的组件来自动化的来支持扩容。17年的时候基于 MySQL XA 实现内置的分布式事务这样一个方案。18年的时候尝试把中间件加上一个复杂的系统，想把他的运维成本降下来，所以又做了一个一体化的尝试。19年的时候把过去十年的经验和探索进行一个总结回顾以及对未来做了一个思考。在2020年的时候又推出了产品新的架构，并且对他的品牌从原来的 DRDS 升级为现在的 PolarDB-X，所以大家在印象里可能对PolarDB-X稍微有些陌生或者是新鲜，因为在2020年之前的名字不是这样的，但这个产品本身历史比较悠久。之后这个产品会一直迭代到现在。在去年云栖大会，即去年12月的时候 PolarDB-X 宣布了开源，这样也形成了今天这个课程与大家见面的引子。这就是 PolarDB-X 简单的发展过程，简单来说PolarDB-X具有十几年的发展历史的产品，他一路过来是从最早期的分库分表中间件到现在云原生的分布式数据库，不断地迭代的过程。
3、PolarDB-X 系统架构演进
简单来说一下它的系统架构的一个演进。最早业务一开始通常使用单机数据库就够了，所以会用一个在本地部署的，磁盘也是本机的磁盘，这样的一个单机的数据库，比如说 MYSQL 或者 PG。随着业务的发展可能需要对系统的容量，包括读写并发的支持或者是存储规模的扩展都会有比较强的诉求。这个时候通常在国内比较流行的解决方案就是用一个分库分表的中间件，也就是前面刚才提到的TDDL或者说是DRDS，这个就是中间件形态的，这样的一个来解决扩展性这样的诉求，扩展性的问题解决了。但是中间件会引入一些新的问题，所以这个架构也就会持续的往下迭代，这个也就是这张图里面所谓的分布式2.0这样的一个架构，也就是会尝试将上层的分布式的那个内层跟下层的存储层进行一个融合，很多的运维也好，或者说是很多的那种不必要的下层的一些参数也好来进行产品化的封装，这样就是一个一体化的形态，在使用的时候就会用一个比较低的成本来使用这样一个分布式的一个数据库，这是产品的大概的演进过程。
二、PolarDB-X 产品介绍
当前 PolarDB-X 架构组建的视角来看，中间这块是 PolarDB-X 核心的组件，从左往右看的是 CN，也就是分布式的计算层，这层就是上图讲到的计算层或者也可以理解成分库分表这一层，如果对中间件比较熟悉，这一层也就是跟业务即应用直接进行交互的一层。应用不管是用GDBC 直连还是用数据库的连接池，他首先连接的是 CN 这个组件上面，CN 这个组件是无状态的可以进行一个无限的扩展，目前PolarDB-X 这个产品节点最大规模可以扩展到1024个节点，这也是分布式数据库水平扩展能力很强的体现。这是第一个节点，同时他会负责将数据拆分计算之后路由这样一个计算。
第二点是系统里边会用到事务这样一个东西，他在PolarDB-X里因为分布式的数据库，所以里面会有分布式事务，CN 这一层也会支持分布式事务，这是CN这个组件。第二个组件是 DN 组件，为了便于理解可以把它简单的理解成一个 MySQL，只不过是深度定制的 MySQL。DN 就是数据层，也就是说最终数据还是存在了DN里面，CN是不存数据的。DN这个节点，他除了存数据也有一个非常强的扩展能力，他跟CN一样最大规模可以支持到1024个节点扩展，在PolarDB-X里面DN还有另外一个非常重要的特点。它是用自研的一个XPX这样的一个库来实现了他的高可用能力，也就是说每一个DN的节点，可以理解为它有三个副本在运行，这其中的任何一个副本挂了就里面的数据丢了，或者他所在的机器宕机了，或者说当前网络不可达也好，那都不影响这个节点的一个可用性，这也正是分布式系统所能够提供的高客用能力的核心体现，这是 DN 节点。
第三个是上面的 GMS 组件，这个组件其实也是一个 DN 或者说也是一个 MySQL,只不过它是一个扮演的特殊角色的DN,它首先在整个系统当中是一个节点，不像 CN 和DN 可以无限的扩展，它只有一个节点。只不过它是一个高可用的节点，也就是这里显示的它是一个三副本的一个高可用节点，他会提供这样几个功能，第一个是会为整个系统提供一个时间戳，这样的一个服务。在分布式事务里面，需要有一个能够提供全局时间戳这样的一个组件，那么在里面就是由 GMS 这个组件来提供的，也就是这张图里面说的 TSO。第二个功能是整个系统当中的元数据都是存在 GMS 里面的，比如库表的结构、账号信息、权限信息等等这些信息都存在GMS里面。它内部的一些结构的信息，比如说CN最终部署之后，它的IP和端口是啥、DN的端口是啥等等，这些信息也存在GMS里面。
最后一个组件 CDC，如果对其他类型的分布式数据库之前有所了解的话，会发现 CDC 这个组件可能在 PolarDB-X 里面是比较特别的存在，其他的数据库那边都没有，这个组件是 PolarDB-X用来提供全局日志的组建。所谓的全局日志，如果对MySQL 比较熟悉的话，它是用来提供跟 MySQL BINLogo 完全一致的，这样的一个全局 PolarDB-X 的组件，如果不了解的话 BINLogo 就是按照时间顺序严格的记录了这个系统当中所有的数据的一个变化。也就是说它是一个队列，如果从头到尾去消费了这个队列，然后在本地重放的话，可以把系统当中的数据原模原样的给还原出来，他就是一个增量日志组件，这就是 PolarDB-X 的四个核心的组件 CN、DN、GMS、CDC。
每个产品都会有自己的特点。PolarDB-X 也不例外。第一个特点是水平扩展，就是架构2.0。他说明了 PolarDB-X 的架构是所谓的share d-nothing架构，Shared-nothing 就是新节点，可能不共享任何数据或者是无状态的，可以做到很好的水平扩展的能力。目前 PolarDB-X 这个集群的最大的规模可以扩展到1024个节点，也就是说这个系统当中可以有1024个 CN、1024个 DN，那这样，这是非常夸张的分布式系统。同时是支持hash和Range这两种数据的路由算法。同时也支持水平透明的水平扩展能力。这里所谓的透明是可以像使用单机的 MySQL 一样去做建表或者加索引等等，这样一系列的TDDL操作或者是插入数据这样的操作。对分布式并不需要太强的了解就可以了。PolarDB-X 会自动把这些东西处理好，这就是所谓的透明水平扩展。这是 PolarDB-X 的第一个核心特性，它是一个分布式的数据库，那么采用的是 shared-nothing 的架构有很强的水平扩展能力，最强可以扩展到1024个节点。
第二个特性是高可用。在刚才讲DN节点的时候已经提到了，高可主要是依赖于自己实现的基于 X-Paxos 的强一致的库，这样一个一次性协议算法来实现。同时还会支持一些其他的能力，比如将数据进行重新的分布，可能有些SQL在进行查询的时候，尤其是一些 Join 相关的一些操作，在进行查询的时候，数据因为不同的拆分的算法导致数据的分布不同，会让查询效率降低，所以会提供一些其他的让你有能力去干预到这个数据分布的一些特性。比如将若干个表进行Group分组。在一个组里面的这些表，在数据的拆分方式上保持一致，这样在做一些join的相关操作的时候能够让他们进行更快的数据查询，。另外可以来指定这份数据在物理位置上是分布在某一个机房或者某一个可用区，来使我的应用访问的时候，可以有一个就近的原则等等，会提供这样一个能力。这个就是 PolarDB-X 提供的第二个能力叫做高可用。
同时高可用这边从架构可以看到，除了 DN 通过 X-paxos 来保证数据节点的高可用之外，CN 节点其实也是高可用的。因为他是个无状态的节点，所以可以比较容易地把它扩展出好多份，其中任何一个节点挂掉之后，其他节点都可以正常的工作，他们完全不依赖于那个挂掉的节点，所以CN他其实也具备高可用能力。这里的GMS也是一样的，因为它是三副本的设计，所以 GMS 3个节点当中，有一个挂掉之后是不影响对外服务的能力的，这里的 CDD 也一样。所以整个系统四个组件都是有高可用能力的。
第三个特点就是 MySQL 生态兼容，前面讲 PolarDB-X 产品发展的过程的时候。可以看得出来这个产品从一开始就是用分库分表中间件再加上 mysql 来做架构设计的，后续很多功能的迭代和持续的开发要考虑到 mysql 这个兼容，这是一个很自然的过程，因为出发点就是mysql，所以要考虑 mysql 兼容的生态，mysql不管是在国内还是在国外都是非常大非常繁荣的生态，兼容他也是一个合理的选择。PolarDB-X 在兼容 mysql 上面，第一因为他出发点就是 mysql所以有先发的优势。所以他在兼容上可以做得更深入一些，它不仅仅会做到对 mysql的通讯协议的兼容，通过GDBC连我的时候，可以把我当成mysql，发现MySQL不会语法报错，不会仅仅停留在这个层面，他会做得更深入一些，MySQL的大部分的语法以及他大部分的功能都是支持的，事务的隔离级别跟MYSQL是一样的，包括MySQL的上下游的一些系统生态兼容。
比如刚才提到的通过 CDC 这个组件提供了一个完全兼容 mysql binlog 一个叫做全集binlog 的能力。他可以实现这张图里面所示的无缝的跟 MySQL 的下游的系统进行互通 MySQL 系统。比如开源里面有一个非常有名的开源工具，叫 CONNEL。另外比如公有云上的阿里云提供的一个 DTS 的等等，这些 mysql binlog 的订阅工具都可以无缝地切到 PolarDB-X 里面。
另外一个比如大数据的系统，可以用 flink cdc 直接把 X-Paxos 当成MySQL来连接到 PolarDB-X 里面，这都是兼容的一部分。另外一点是MySQL的上游，比如MySQL通常在部署的时候会进行一个主备的一个搭建来让系统有高可用这样的能力。PolarDB-X也提供了一个Application这样的能力，可以将PolarDB-X无脑的，作为一个MYSQL的背来搭建一个MySQL到PolarDB-X的主备同步这样一个链路。这些都是在MySQL兼容上面所做的一些工作。在前段时间就是5月25号的时候，做过一个PolarDB-X的开源的新的版本的发布会，也就是2.1这个版本，那里面对Binlog尤其是Replication能力做了非常详细的展示，如果有兴趣的话可以再去看一下那个直播的回放。这是MySQL兼容的部分。
第四个是分布式事物，作为一个数据库，显然得提供事务这样一个基本的能力，如果对事务的实现有之前的各种方案有所了解，那么PolarDB-X的实现的方案是MVCC+tTSO+2PC这样的一种组合来实现了分布式事物的能力。同时做了大量的优化来使这个分布式事务的效率在一个生产可用的状态。
第五个特点是 HTAP，HTAP是目前做分布数据库的都会去往这个方向去靠的一个点，PolarDB-X 里面具体来说做的几个跟HTAP相关的一些能力。第一个具有原声的MPP的能力，所谓的原声MPP能力不是将一个外挂的类似于Spark这样的东西挂在PolarDB-X下面，对上面就提供了一个并行加速查询这样的能力。实现MPP这样的能力在站在使用的视角，用来做HTAP查询的C口跟用来做app查询C口是完全一样的，他们在语法的兼容，还有其他的功能等等很多的地方都是完全一致的，不会出现TP上面这个C口可以跑，但是如果 APP 下面挂的是Spark可能在SQL就不能跑了，出现这样一个诡异的行为。这是所谓的原声 MPP。
第二个是智能读写分离，通常来需要业务这边来将那Tp和app的流量做一个划分。Tp连接到tp所对应的那个连接串，app就连到app所对应的连接串，这无疑就增加了应用上面连接池的维护这个复杂度。第二个更主要的是会让负责做应用开发写SQL的那些同学，首先得判断这条SQL到底是做一个TP查询还是做一个app查询。很多情况下它是可以判断，但是也有很多情况他是处于一种中间态模棱两可的状态，所以这件事情是比较困难的。这边就提供了一个统一的记录点，就是说应用可以无脑的全部接入到PolarDB-X的CN节点上面，不管是TP的查询还是app的查询都可以直接将这个SQL发过来，CN会自己来判断这个SQL到底是tp还是app的查询，很多情况下是可以判断的，来将他们自动的进行一个隔离。所谓的隔离是指TP和app从CN到DN整个的查询的链路资源上面都可以做到物理的隔离，这样避免那些比较大的app的查询影响到在线的TP的业务，就是智能读写功能。这个功能是依赖于部署的时候需要一个特殊的指定。
再一个就是oss归档存储,当前都会在讲降本增效概念，就是尽量把我们的成本给降下来，后台系统当中很大的一个成本来自于数据的存储的成本。在数据库里面，其实有很多的数据，它本身没有那么高的频繁的访问的次数,就是所谓的冷数据，如果将她跟经常访问地震数据放在一起，那么它们都存储在一些比较贵的，类似于固态硬盘等等这样的一些存储上面，那么它的成本就会比较高，提供了一种可以将你的库里面的冷数据，将他们归档到OSS或者其他的一些比较低成本的存储上面的这样的一个能力来使系统的总体的成本呢降低。这是HATP能力。
再一个就是会提供一些企业级的特性，所谓的企业级特性可以认为是方便做一些运维或者做一些管理的功能。第一个功能就是SQL限流，业务可能在跑的好好的，突然有一个其他的应用新上线，但因为他的SQL没有经过充分的一个验证或者是调试。上线之后 MySQL 会把这个系统给打挂，这个时候可能没有办法在短时间内定位到来自于哪个应用，但如果知道是哪个CPU的话，可以通过接口限流这个功能直接将这个SQL进行限制，使系统可以快速的进行恢复。第二个就是索引推荐，需要对库表进行优化，可以通过索引推荐这个功能让系统来告诉在哪个表上面加一个怎样的索引可以提高查询效率等等。还有TDE、三权分立等等一些能力，提供所谓的企业级特性。
最后一个是云原生，它基于云的一些基础设施来做数据库，尤其是开源的部分提供了 K8S 的 Operator 这样部署的方式，如果业务是运行在 K8S 的那个这个基座上面的，可以将 K8S 的 Operate直接在上面进行部署来进行使用。另外一个就是我们寄予 Prometheus+Grafana 做了K8S部署形态的监控的系统。大家有兴趣的话也可以尝试后续还有更多的来基于K8S生态来做的一些能力，到合适的时间点会开放出来给大家使用。以上是 PolarDB-X这个产品的一些特点，水平扩展、高可用、MySQL生态兼容、分布式事务、HTAP、企业级和云原生。
