开发者学堂课程【PolarDB-X 动手实践：开始使用 PolarDB-X】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/944/detail/14748
开始使用 PolarDB-X
内容介绍
一、课程简介
二、Spring Boot
三、World press
一、课程简介
重新介绍一下直播的主要内容：如何使用 PolarDB-X 动手实践系列，两周前已经讲过了如何在本地拉起 PolarDB-X 的实例或集群，今天学习怎么在应用开发中使用 PolarDB-X。
我们这个课程讲的是 PolarDB-X 的开源版本，这个版本对应的是商业版本 2.0，面向群体主要是开发者，架构师，DBA 等等，只要是对 PolarDB-X 感兴趣的都可以来听，主要内容是围绕 PolarDB-X 使用的全过程的场景化介绍。
主要包含以下内容：
第一讲是如何一键部署 PolarDB-X，今天讲如何使用它，今天的实践需要有这些环境配置，系统是 CentOS,macOS,Ubuntu,windows 都可以，配置差不多就行，需要注意的是需要有上节课已经准备好的 PolarDB-X 的实例，看张图，PolarDB-X 是一个分布式系统，有四个组件组成：CN，DM，CDC，GMS。CN 是分布式的计算层，GMS 是源数据中心，DN 是存储层，这里可以简单地把它理解为 Mysql，CDC 是全局日志的组件，看一下如何从左边的应用到右边的 CN，DN，建立一个连接。
演示的内容包括这三个方面：第一个是 Spring Boot 官方教程，与 PXD 进行简单的对接，让 Spring 库的官方教程里的实例能运行起来；第二个是用 WorldPress 来跟 PXD 进行一个简单的搭建，最后有时间在讲下在 PolarDB-X 里面的应用的连接池，涉及一个最佳实践。
二、Spring Boot
为什么使用 spring 库来讲呢，简单来说因为我想让自己的受众里有更强的体感。更多的受众看的是开发者的语言，简单地说从目前语言流行度的排行榜来看，第一是 python，第二是 C，然后是 Java，这个排行榜在国内有个修正，Java 很大可能排在第一，所以我们这里面就选择了 Java，Java 里最流行的是 script,这就是我选 script 的原因。为什么选 WorldPress 呢，WorldPress 是推广了世界 43%的网站系统，一小半的网站都是通过 WorldPress 来推广的，也就是说它的账户还是非常广的，所以我们选择了这两个系统进行演示，背景知识讲完，我们来进行实操。
首先我们打开 script 的官网，这里有一个官方的教程叫做 Guides,还有往下有许多教程的页面
往下会有一个 MysQl 的教程，接下来就按照这个教程一步步进行操作，希望在教程结束的时候能将里面的实例完全的运行下来，也就是我现在演示的是直接用 PXD 来其换掉里面的 MysQl,然后在 spring 库连接的时候还算是会把它当作 MysQl,如果我的实例能很好地跑下来的话，说明在 MysQl 的兼容性上还是做的可以的，第一步是前提的准备工作，是把工程样例的代码下载下来，这里会有一些样例的代码
也可以直接跳到创建的这一步，首先登陆系统，创建一个账号，可以看到这里是已经准备好的 PolarDB-X 的一个实例
我们登录上它去建一个库，库名叫 DBexample，然后再创建一个 script 的一个账号，把账号创建好了，最后给这个账号授一下权，然后就做好了。接下来就是把连串的信息创建到工程的库里，我们对这里的连接串进行编辑，把档口改成 6121：
到这里连接串已经创建好了，我们接下来进行 model 的创建。同样地再创建一个仓库。然后第三个去创建 contral:
然后再创建一个应用的类，本来已经有了，现在需要增加修改，这样就是 Java 需要的几个基础的类就创建好了。
接下来直接在本地进行启动，现在应该启动好了，我们来试一下，进行简单的测试：增加一个记录，返回 safe 就说明成功了，接下来我们来做个查询，可以看到已经将我们为你刚才写进去的用户已经查出来了：
可以看到就是在这个过程当中，我刚才直接将 spring 库中的 MySQL 进行了一个替换，去跑了一遍 spring 官方教程的过程，然后也能顺利地把实例完成，所以就是说你把 polardb-x 当作 MySQL 来完成是没有问题的，还有就是门槛相对来说比较低。
我们在来做个验证，看数据是否真的写到库里。
三、world press
world press 它自己目前往 sus 方向去研究，所以它不像 spring boot 一样提供一个非常好的一步一步去搭建这样的教程。我为了方便直接在 Docker harbour 上找了对应的镜像，镜像的页面会给你一个说明书，关于如何 World press，现在直接来用它。
第一部直接把镜像下载到本地，因为我之前已经下载过了，所以它很快就可以完成，接下来我们在本地跑一个 world press 的容器。复制一个在本地监听 8080 窗口的 world press，容器的名字叫 sum world press。
在它跑起来以后就可以通过官方的浏览器访问到本地的 world press，档口是 8080。
接下来做个配置，这里选中文继续，现在到了配置数据库的环节，因为 world press 默认的是跟 MySQL 的搭配，所以它这里数据库就是 MySQL，我们这里也进行设置，首先它需要一个数据库叫做 world press，共享是可以创建的。用户名直接用 PXD 或者 polardb-x root，档口是 6121。我们来试一下能否成功，结果是出错了。
我们换一个 IP 再试一下，现在 world press 进行了一个初步得到数据库的连接，连接成功后继续起个用户名，输入之前创建账号时的密码，现在进行安装，现在可以看到 world press 已经初始化完成。
我们来登陆一下，成功了，刚才那个过程首先 polardb-x 直接连接了 MySQL，然后在本地跑了一个官方镜像对应的容器，有通过浏览器通往 8080 网站的窗口，就会发现已经有了一个打点好的 polardb-x 的 world press 的网站，我们现在默认的写点东西，我们可以直接对 book 进行编辑，复制一段话，然后保存。可以看到现在页面的内容已经变了，说明功能是好的。
接下来我们做下一件事，world press 有非常多的插件，我选择了一个能对 world press 站点包括数据库进行压测的插件，我们先来找到这个插件，我们来看一下它的解释，第一个是它会做一些数据计算，比如做十万遍，然后会有几个测试。
第一个是测 MySQL 的链接，连接完之后会循环在里面做一百万次的链接码，第二个是它会连上你的数据库之后做一些基本操作，相当于模拟在站点大量写一些 book 的内容，这些 MySQL 可能会稍微有些复杂，如果是 PXD 也可以在执行过程中不出错的话，说明和 MySQL 之间的兼容度做的也是可以的，所以我们来体验一些插件，看它能否跑出那个结果。现在安装好了，我们取一下，取完之后在左边的工具菜单里都会有这个插件的页面，每个页面很简单。
运行完了，我们来看一下结果
第一个它会给一些计算结果、时间，这些我们不是很关注，关注一下跟数据库相关的内容，这里需要说明的是给出的一些结果就是我连结一次，我一次需要多少时间，但能出这个结果的前提是 MySQL 已经正常的执行了，所以说在兼容性上面还是可以的。
刚才我们做了几件事，首先我们完成了一个 MySQL 来用，用来从 world press 的官方的镜像下载到本地，然后根据官方的教程在本地起了一个 book 站点，然后用 polardb-x 做了一个底库，无脑的取占 MySQL，然后这个站点时可以顺利搭建完的，上面的一些内容也可以正常的进行，同时选择了一些会对 world press 的数据库进行压缩的工具，它也可以正确的分离执行。
最后我们再来讲一个知识点，因为分布式库说到底还是跟单机有很大的不同的，但是由于我们做的是 MySQL 的生态，所以从单机到分布式切换的这个门槛得想办法降低，但是降低之后一旦开始使用，我们还是最好了解一些分布式的特点，这样有助于在后面把它用得越来越好。所以我们今天利用一点时间来讲一下在 polardb-x 里面应用测连接池应该如何来配置。
首先我这里打开了一个文档，是我们开源的产品官方的一个文档，它的地址是 docker.polardb-x.com，它的页面是在下面有一个最佳实践，最佳时间里的第一个是如何使用应用案例连接池。
现在我简单的做一下介绍，首先来简单介绍一下两个概念，第一个是前端连接和后端连接，polardb-x 的计算和存储是分离的，应用端首先是跟 CN 进行连接，CN 和 DN 之间也存在一个连接，我们称之为后端连接，这里讨论的都是应用跟 polardb-x 的连接，然后系统内部的连接大家不用关心。
然后再讲如何选一个连接池之前，我们再来讲几个概念，一个是 QPS，或者是 RT，通常一个请求的 RT，我们会用毫秒来作为单位。如果它的 RT 是 15 个支，那么这单个连接已经达到 QPS 上限，也就是 1000/RT，1000 就是 1 秒转化成毫秒之后就是 1000 毫秒，这就是单为连接的 QPS。
第二个点是如果一个应用连上一个 CN，单个 CN 所能够处理的 QPS 是多少呢，如果一个连接是前面的 RT 的话，那么有多少个连接。也就是说单个连接的 QPS 乘以连接数就是一个 CN 所能处理的 QPS 的上限。再举例子来说，现在 RT 是毫秒，那么单个连接的 QPS 的上限是两百，假设预估的 QPS 是 5000，那就至少需要 25 个连接。
在了解清楚 QPS 和 RT 这两个定义之后，我们再继续往下看，当一个应用跟 CN 建立一个连接之后，它会发送查询请求过来，请求过来之后，给后面的线程，让线程去处理里面的请求，一个好的方式就是我们能够将编在连接里面的请求和线程值对应起来，所以这里又继续做了个计算，我们来算一下应用访问单个 CN 的时候 QPS 的上限。因为一个 CN 里面会默认连一个 1024 大小的一个线程值。也就是你来了一个请求，我会在 1024 个线程池里面选择一个线程来处理你的请求。这样一个 CN 所能处理的 QPS 的上限就多了一个条件，需要在单个连接的 QPS 的上限再乘以一个连接数和线程池的一个小的值，也就是说如果在单个 CN 上面配置了长连接的数量，就会使 1024 乘以单个连接的上限，因为这里多了一个限制点，也就是单个 CN 里面 1024 个线程。如果访问整个 polardb-x，它有多个 CN，应该就是它在前面的基础上乘以 CN 的数量，这就是应用目前所能够获取的访问 polardb-x 所能访问 QPS 的上限，在这个文档里有两个例子，前面的计算过程。
如果用的是 Java 的应用的话，我们推荐使用阿里云里面开源的连接池，它的版本要用 1.11 以上，因为 1.11 以上的版本给两个参数，这两个参数对分布式的系统比较友好，通常一个分布式的系统或者数据库在前端会有一个负载均衡，这样一个组件来负责对应用层的接入，但是负载均衡的一些算法可能对后面的多个 CN 节点并不是非常的友好，比如我说两个场景，一个是你的应用在一瞬间创建了大量的连接，这种状态应用刚刚启动或者是重启这个过程，现有的负载均衡的一些算法，里面很多会导致负载均衡跟后面的 CN 连接之间的数量非常不均匀，一种极端的情况就是有四个 CN，应用发起了一百个链接，可能一百个连接都打在了一个 CN 上。
第二个问题是负载均衡探活异常导致分布不均，比如说四个 CN 里面有一个是正常的，但是由于一些原因导致负载均衡在跟 CN 的网络连接是否可达的时候误判了，就会导致 CN 白白的浪费在里面。
Druid 里面有两个参数可以很好地处理两个问题，TCB 连接异常的话要有一个超时的机制，即使它一直正常的在用，但是要把它断掉重新连接，另一个策略是一个 TCB 连接能够处理的数量是这个上限，比如说处理了一万次 Druid，我就强制把它断开。有了这两个特性之后，就会使的负载均衡和后面的 CN 之间的 TCB 的长连接不会永远的被占用，总有一个达到一定的时间，一定的量后会自动地断开来进行一个再次的连接，如果出现了刚才所说的连接一开始被连接到一个 CN 的这种情况，因为在这个参数机制下面，它会有个断开再重新连的过程，下次连的时候就很有可能分配到其他的 CN 上面了。这样总体来看，会使得负载均衡跟后面多个 CN 之间的连接数量保持一个相对的均衡，以上就是应用端的连接池如何设计的讲解，更详细的过程可以去看官方的文档。
最后做一个小广告，这是我们 github 版的一个仓库，大家可以在上面搜索 polardb-x，这个仓库，我今天加了一个新的脚本，叫做 makefile
我们上节课讲的编译还是很容易出错的，所以对现有的编译过程进行了一个梳理，这里有一个脚本，可以一键从源码编译到把 polardb-x 给跑起来，把 polardb-x 这个工程克隆下来，也就是在里面执行 make，完了以后跑这个脚本，再开始一下，就可以了。
后面会更深入地讲一些，一旦开始用 polardb-x 之后可能会遇到的一些问题，比如说从 MySQL 把数据迁出来，或者有其他数据进行大规模的导入，或者你的系统到瓶底了进行扩缩容，这些是后续讲的内容。
