POLARDB架构简介
PolarDB是阿里云ApsaraDB数据库团队研发的基于云计算架构的下一代关系型数据库(暂时仅支持MySQL，PostgreSQL正在紧锣密鼓的开发中)，其最大的特色是计算节点(主要做SQL解析以及存储引擎计算的服务器)与存储节点(主要做数据块存储，数据库快照的服务器)分离，其次，与传统的云数据库一个实例一份数据拷贝不同，同一个实例的所有节点(包括读写节点和只读节点)都访问存储节点上的同一份数据，最后，借助优秀的RDMA网络以及最新的块存储技术，PolarDB的数据备份耗时可以做到秒级别(备份时间与底层数据量无关)，这三点相结合，我们可以推断出PolarDB不但满足了公有云计算环境下用户业务快速弹性扩展的刚性需求(只读实例扩展时间与底层数据量无关)，同时也满足了互联网环境下用户对数据库服务器高可用的需求(服务器宕机后无需搬运数据重启进程即可服务)。
DB Server: 即数据库进程(Polar DataBase, 简称PolarDB)。PolarDB数据库内核区分实例角色，目前包括三种角色，Primary，Standby和Replica。Primary即为拥有读写权限的读写库，Replica即为只读实例，仅仅拥有读取数据的权限(后台线程也不能修改数据)，Primary和Replica采用Shared Everything架构，即底层共享同一份数据文件和日志文件。StandBy节点拥有一份独立的数据和日志文件(如图2所示)，虽然用户线程依然只有读取数据的权限，但是后台线程可以更新数据，例如通过物理复制的方式从Primary节点更新增量数据。StandBy节点主要用来机房级别的容灾以及创建跨可用区的只读实例，公测阶段暂时不开放。由于只读实例的扩展不需要拷贝数据，创建新的只读实例不但速度快，而且很便宜，用户只需要支付相应计算节点的成本即可。我们称StandBy和Replica节点为Slave节点，Primary节点也可称为Master节点。
User Space File System: 即用户态文件系统(Polar File Sytem, 简称PolarFS)。由于多个主机的数据库实例需要访问块存储上的同一份数据，常用的Ext4等文件系统不支持多点挂载，PolarDB数据库团队自行研发了专用的用户态文件系统，提供常见的文件读写查看接口，便于MySQL和相关的外围运维工具使用文件系统支持类似O_DIRECT的非缓存方式读写数据，还支持数据页原子写，IO优先级等优秀的特性，为上层数据库的高性能提供了结实的保障。传统的文件系统，由于嵌入在操作系统内核中，每次系统文件读写操作都需要先陷入内核态，完成后再返回用户态，造成效率低下。PolarFS以函数库形式编译在MySQL中，因此都运行在用户态，从而减少了操作系统切换的开销。
Data Router & Cache: 即块存储系统客户端(Polar Store Client, 别名PolarSwitch)。PolarFS收到读写请求后，会通过共享内存的方式把数据发送给PolarSwitch，PolarSwith是一个计算节点主机维度的后台守护进程，接收主机上所有实例以及工具发来的读写块存储的请求。PolarSwith做简单的聚合，统计后分发给相应的存储节点上的守护进程。由此可见PolarSwitch是一个重资源的进程，如果处理不好，对计算节点上的数据库实例有很大的影响，因此我们的管控程序对其使用了CPU绑定，内存预分配，资源隔离等一些手段，并且同时部署了高效可靠的监控系统，保证其稳定运行。
Data Chunk Server: 即块存储系统服务器端(Polar Store Server, 别名ChunkSever)。上述三个部件都运行在计算节点上，这个部件则运行在存储节点上。主要负责相应数据块的读取。数据块的大小目前为10GB，每个数据块都有三个副本(位于三台不同的存储节点上)，两个副本写成功，才给客户端返回成功。支持数据块维度的高可用，即如果一个数据块发生不可用，可以在上层无感知的情况下秒级恢复。此外，PolarStore使用了类似Copy On Write技术，支持秒级快照，即对数据库来说，不管底层数据有多大，都能快速完成全量数据备份，因此PolarDB支持高达100T的磁盘规格。
计算节点和存储节点之间通过25G RDMA网络连接，保证数据的传输瓶颈不会出现在网络上。
此外，PolarDB还有一套完善的基于docker的管控系统，处理用户下发的创建实例，删除实例，创建账号等任务，还包括完善详细的监控，以及可靠的高可用切换。管控系统还维护了一套元数据库，用以记录各个数据块的位置信息，提供给PolarSwitch，便于其转发。
可以说，PolarDB整个项目用了很多很多的新技术黑科技，给用户直接的感受是，又快(性能是官方MySQL6倍)又大(磁盘规格支持高达100T)又便宜(价格只有商业数据库的1/10)。
实践内容
POLARDB数据库准备
进入云数据库阿里云POLARDB控制台进行配置：2核4GB（独享配置）
创建后会发现有两个实例，一个主实例，一个只写实例。
测试过程
本次场景使用HyperPacer PRO 2016版进行数据库压测。
配置如下：
1.进行工程配置：
初始化JDBC配置和JDBC请求：
这里各个编辑控件和下拉控件的使用及每个选项的说明，只要在HyperPacer的工具栏上点击帮助就可以看到。在绑定变量赋值的编辑区域里，我们看到在前两个变量赋值这里做了参数化。
这里需要注意的是：此处绑定变量赋值的顺序和个数需要和存储过程中定义的参数保持完全一致。
在绑定变量类型的编辑区域，这里的类型只可以是在java.sql.Types中定义的类型，并且要保证和我们调用的存储过程中的参数类型保持一致。
我们这里说的类型保持一致要分为两方面来看：一方面要保证用于传参的变量类型保持一致，即这里写的JDBC类型要和SQL类型保持一致，关于保持类型一致的转换映射关系可以查看JDK的官方文档。
2.如下图进行压力数据测试配置:
参数详解
基准用户数：系统过载前允许的最大用户数
最大用户数：系统过载后允许的最大用户数
基准用户加压策略：固定时间内加载固定数量的基准用户进入系统
过载用户加压策略：固定时间内加载固定数量的过载用户进入系统
持续总时长：系统过载后持续保持过载运行的时间
用户退出策略：测试结束前多少时间内退出全部用户
压力阀配置：配置测算系统过载的依据，如平均CPU利用率达到99%等。
