2. MySQL高可用版
MySQL高可用版则是针对企业级用户提供的高可用数据库版本，提供99.95%的SLA保障。采用Active-Standby的高可用架构，主节点和备节点之间通过MySQL Binlog进行数据的Replication。当主节点发生故障，备节点接管服务。同时还支持多个只读节点，支持负载均衡的数据读写分离的访问方式。采用Shared-Nothing架构，计算和数据位于同一个节点，最大程度保障性能的同时又通过数据的多副本带来可靠性。
3. MySQL金融版
MySQL金融版可以说是针对金融行业等高端用户设计的高可用、高可靠云服务产品，采用分布式Raft协议来保证数据的强一致性，拥有更加优异的故障恢复时间，更加满足数据容灾备份等业务场景的需求。
PolarDB的进化
PolarDB采用存储与计算分离的技术架构，同时可以支持更多的只读节点。主节点和只读节点之间是Active-Active的Failover方式，计算节点资源得到充分利用，由于使用共享存储，共享同一份数据，进一步降低了用户的使用成本。下一节我们将进一步从细节上描述PolarDB的关键特性。
PolarDB的设计思想有几个大的革新。一是通过重新设计特定的文件系统来存取Redo log这种特定的WAL I/O数据，二是通过高速网络和高效协议将数据库文件和Redo log文件放在共享存储设备上，避免了多次长路径I/O的重复操作，相比较Binlog这种方式更加巧妙。另外在DB Server设计上，采用MySQL完全兼容的思路，完全拥抱开源生态，从SQL的编译、性能优化器和执行计划等等都保留了传统关系型数据库的特色。并且针对Redolog的I/O路径，专门设计了多副本共享存储块设备。
我们知道，分布式数据库一直是数据库领域的热点，具有非常大的实现难度。不管是遵循CAP理论，还是BASE思想，通用的分布式关系型数据库基本上很难做到技术和商用的完美平衡。与SQL标准以及主流数据库兼容，OLTP ACID事务100%支持，99.99%的高可用，高性能低延迟并发处理能力，弹性Scale Up，Scale out可扩展性，备份容灾和低成本迁移等等，能够完美兼顾所有这些特点的商用关系型数据库还没有出现。
阿里云PolarDB和Amazon Aurora的一个共同设计哲学就是，放弃了通用分布式数据库OLTP多路并发写的支持，采用一写多读的架构设计，简化了分布式系统难以兼顾的理论模型，又能满足绝大多数OLTP的应用场景和性能要求。总之，100% MySQL的兼容性，加上专用的文件系统和共享存储块设备设计，以及在下文中提到的多项高级技术的应用，使得新一代关系型数据库PoalrDB在云时代必将大放异彩。
5. PolarDB产品关键技术点剖析
在讲述了阿里云RDS的不同产品形态之后，我们再从整体上看一看PolarDB的产品架构。下图勾画了PolarDB产品的主要模块，包括数据库服务器，文件系统，共享块存储等。
PoalrDB产品架构
阿里云关系型数据库PoalrDB集群
如图所示，PolarDB产品是一个分布式集群架构的设计。它集众多高级的技术实现于一身，使得数据库OLTP处理性能有了质的飞跃。PoalrDB采用了存储与计算分离的设计理念，满足公有云计算环境下用户业务弹性扩展的刚性需求。数据库计算节点和存储节点之间采用高速网络互联，并通过RDMA协议进行数据传输，使得I/O性能不在成为瓶颈。
数据库节点采用和MySQL完全兼容的设计。主节点和只读节点之间采用Active-Active的Failover方式，提供DB的高可用服务。DB的数据文件、redolog等通过User-Space用户态文件系统，经过块设备数据管理路由，依靠高速网络和RDMA协议传输到远端的Chunk Server。同时DB Server之间仅需同步Redo log相关的元数据信息。Chunk Server的数据采用多副本确保数据的可靠性，并通过Parallel-Raft协议保证数据的一致性。
在描述了PolarDB的产品架构之后，我们再分别从分布式架构，数据库高可用，网络协议，存储块设备，文件系统和虚拟化等方面逐一介绍下PolarDB使用的关键技术点。
Shared Disk架构
分布式系统的精髓就在于分分合合，有时候为了并发性能进行数据切分，而有时候为了数据状态的一致性而不得不合，或者由于分布式锁而不得不同步等待。
PolarDB采用Shared Disk架构，其根本原因是上述的计算与存储分离的需要。逻辑上DB数据都放在所有DB server都能够共享访问的数据chunk存储服务器上。而在存储服务内部，实际上数据被切块成chunk来达到通过多个服务器并发访问I/O的目的。
物理Replication
我们知道，MySQL Binlog记录的是Tuple行级别的数据变更。而在InnoDB引擎层，需要支持事务ACID，也维持了一份Redo日志，存储的是基于文件物理页面的修改。这样MySQL的一个事务处理默认至少需要调用两次fsync()进行日志的持久化操作，这对事务处理的系统响应时间和吞吐性能造成了直接的影响。尽管MySQL采用了Group Commit的机制来提升高并发下的吞吐量，但并不能完全消除I/O瓶颈。
此外，由于单个数据库实例的计算和网络带宽有限，一种典型的做法是通过搭建多个只读实例分担读负载来实现Scale out。PolarDB通过将数据库文件以及Redolog等存放在共享存储设备上，非常讨巧的解决了只读节点和主节点的数据Replication问题。由于数据共享，只读节点的增加无需再进行数据的完全复制，共用一份全量数据和Redo log，只需要同步元数据信息，支持基本的MVCC，保证数据读取的一致性即可。这使得系统在主节点发生故障进行Failover时候，切换到只读节点的故障恢复时间能缩短到30秒以内。系统的高可用能力进一步得到增强。而且，只读节点和主节点之间的数据延迟也可以降低到毫秒级别。
从并发的角度来看，使用Binlog复制现在只能按照表级别并行复制，而物理复制只按照数据页维度，粒度更细，并行效率更加高。
最后一点，引入Redolog来实现Replication的好处是，Binlog是可以关闭来减少对性能的影响，除非需要Binlog来用于逻辑上的容灾备份或者数据迁移。
总之，在I/O路径中，通常越往底层做，越容易和上层的业务逻辑和状态解耦而降低系统复杂度。而且这种WAL Redo log大文件读写的I/O方式也非常适用于分布式文件系统的并发机制，为PolarDB带来并发读性能的提高。
高速网络下的RDMA协议
RDMA之前是在HPC领域被使用多年的技术手段，现在开始被使用到云计算领域，也证实我的一个判断。云计算2.0时代，将重建人们对于云计算的认识，云端也能够创造超越传统IT技术的计算力，这将是一个越来越严谨的工业实现。
RDMA通常是需要有支持高速网络连接的网络设备（如交换机，NIC等），通过特定的编程接口，来和NIC Driver进行通讯，然后通常以Zero-Copy的技术以达到数据在NIC和远端应用内存之间高效率低延迟传递，而不用通过中断CPU的方式来进行数据从内核态到应用态的拷贝，极大的降低了性能的抖动，提高了整体系统的处理能力。
Snapshot物理备份
Snapshot是一种流行的基于存储块设备的备份方案。其本质是采用Copy-On-Write的机制，通过记录块设备的元数据变化，对于发生写操作的块设备进行写时复制，将写操作内容改动到新复制出的块设备上，来实现恢复到快照时间点的数据的目的。Snapshot是一个典型的基于时间以及写负载模型的后置处理机制。也就是说创建Snapshot时，并没有备份数据，而是把备份数据的负载均分到创建Snapshot之后的实际数据写发生的时间窗口，以此实现备份、恢复的快速响应。PolarDB提供基于Snapshot以及Redo log的机制，在按时间点恢复用户数据的功能上，比传统的全量数据结合Binlog增量数据的恢复方式更加高效。
Parallel-Raft算法
谈到分布式数据库的事务一致性，我们很容易想到2PC（2 Phases Commit），3PC（3 Phases Commit）协议。而论数据状态一致性，我们就不得不提到Leslie Lamport发明的Paxos协议，在Paxos为Google等互联网厂商所广泛应用到多个分布式系统实现之后，Paxos成为了最受关注的数据状态一致性算法之一。可是由于Paxos算法论文的理论和实现过于复杂，导致难以被快速应用到工程技术上。Paxos解决的问题之一是，在多个机器的集合中，集合中初始状态相同的任何机器能否通过相同的命令序列到达同样相同的状态点，形成一个一致的收敛的状态机。另一个问题是，作为集群中的一员，通过微观的时间串行通讯方式，需要找到一个始终有效的协议，当一个机器的某个数据状态需要改变时，需要和整个集群（包括其他机器）靠通讯和协议达成相同的认知，一起认同这个机器上的某个状态的改变。
基于这两点，基本上就解决了分布式集群架构中，不同角色的机器，达成一致性状态机的问题。也就可以进一步设计出绝大多数分布式系统的框架。Paxos可以堪称是P2P（Peer to Peer）的对等设计，更加抽象和通用，也更难以理解。而Raft则是选举出Leader，再经由Leader发起对其他角色进行状态一致性更新的实现，更容易理解。而协议本身的实现流程和Paxos有相似之处。
Parallel-Raft是在Raft协议的基础上，针对PolarDB chunk Server的I/O模型，进行改良的一致性算法。Raft协议基于Log是连续的，log#n没有提交的话，后面的Log不允许提交。而PolarDB实现的Parallel-Raft允许并行的提交，打破了Raft的log是连续的假设，提高并发度，通过额外的限制来确保一致性。
Docker
容器虚拟化技术最早的出现是Linux内核为了解决进程在操作系统之间，或者在进程运行过程当中做迁移，通过进程和操作系统之间的解耦，来达到进程运行时的上下文和状态能够保存，复制和恢复的目的。可是LXC的实现，却促成了曾红极一时的Docker的诞生。
从原理上讲，容器虚拟化的实现相对于KVM等虚拟化技术而言，更加轻量级。如果用户不需要感知整个操作系统的功能，那么用容器虚拟化技术理论上应该能够获得更好的计算能效比。其实LXC加上Cgroup这种进程虚拟和资源隔离的方式已经被使用很多年，在HPC领域就常被应用到MPI超级任务的checkpoint和restart恢复上。PolarDB采用Docker环境来运行DB计算节点，用更轻量的虚拟化方式，解决了资源的隔离和性能的隔离，也节省了系统资源。
User-Space文件系统
谈到文件系统，就不得不提一下IEEE发明的POSIX语义（POSIX.1已经被ISO所接受），就像说到数据库要谈到SQL标准。通用分布式文件系统实现的最大挑战就是在完全兼容POSIX标准的基础上提供强劲的并发文件读写性能。可是POSIX的兼容势必会牺牲一部分性能来获得对于标准的完全支持，同时系统实现的复杂度也极大的增加。说到底是通用设计和专有设计的取舍和区别，也是易用性和性能之间的平衡，这是个经典问题。分布式文件系统是IT行业最经久不衰的技术，从HPC时代，云计算时代，互联网时代，大数据时代一直在推陈出新，其实更严格的说应该是针对不同应用I/O场景涌现出很多定制化的实现，再说白点，就是不去支持POSIX标准。
这一点上，只能说知难而退，不过只服务于专门的I/O场景时，不适用POSIX也不是什么问题。这一点，和从SQL到NoSQL的发展如出一辙。支持POSIX的文件系统，需要实现兼容标准的文件读写操作的系统调用接口，这样对于用户而言，就无需修改POSIX接口实现的文件操作应用程序。这样一来就要求通过Linux VFS层来铆接具体的文件系统内核实现。这也是导致文件系统工程实现难度加大的原因之一。
对于分布式文件系统而言，内核模块还必须和用户态的Daemon进行数据交换，以达到数据分片以及通过Daemon进程传送到其他机器上的目的。而User-Space文件系统提供用户使用的专用API，不用完全兼容POSIX标准，也无需在操作系统内核进行系统调用的1:1mapping对接，直接在用户态实现文件系统的元数据管理和数据读写访问支持即可，实现难度大大降低，并且更加有利于分布式系统的进程间通讯。
小结：通过以上的介绍，我们不难发现，PolarDB采用了从计算虚拟化，高速网络互联，存储块设备，分布式文件系统，数据库物理Replication等全方位的技术手段，可以说是众多热点技术的集大成。正式这些关键技术的整合创新，才使得PolarDB的性能有了质的飞跃。
写在最后
阿里云PolarDB是云计算2.0时代产品进化的关键里程碑之一，也是开源数据库生态的积极推动力。PolarDB将于2017年9月底推出的公测版本，会和MySQL完全兼容。接下来，我们也会启动兼容PostgreSQL数据库引擎的研发。
