分布式数据库原理及PostgreSQL分布式解读

    分布式数据库原理及PostgreSQL分布式解读    一、 什么是分布式数据库分布式系统数据库系统原理（第三版）中的描述：“我们把分布式数据库定义为一群分布在计算机网络上、逻辑上相互关联的数据库。分布式数据库管理系统（分布式DBMS）则是支持管理分布式数据库的软件系统，它使得分布对于用户变得透明。有时，分布式数据库系统（Distributed Database System,DDBS）用于表示分布式数据库和分布式DBMS这两者。”在以上表述中，一群分布在网络上、逻辑上相互关联是其要义。在物理上一群逻辑上相互关联的数据库可以分布式在一个或多个物理节点上。当然，主要还是应用在多个物理节点。这一方面是X86服务器性价比的提升有关，另一方面是因为互联网的发展带来了高并发和海量数据处理的需求，原来的单物理服务器节点不足以满足这个需求。分布式不只是体现在数据库领域，也与分布式存储、分布式中间件、分布式网络有着很多关联。最终目的都是为了更好的服务于业务需求的变更。从哲学意义上理解是一种生产力的提升。二、 分布式数据库理论基础1 CAP理论首先，分布式数据库的技术理论是基于单节点关系数据库的基本特性的继承，主要涉及事务的ACID特性、事务日志的容灾恢复性、数据冗余的高可用性几个要点。其次，分布式数据的设计要遵循CAP定理，即： 一个分布式系统不可能同时满足 一致性（ Consistency ） 、可用性 （ Availability ） 、分区容 忍 性 （ Partition tolerance ） 这三个基本需求，最 多只能同时满足其中的两项， 分区容错性 是不能放弃的，因此架构师通常是在可用性和一致性之间权衡。 这里的权衡不是简单的完全抛弃，而是考虑业务情况作出的牺牲，或者用互联网的一个术语“降级”来描述。针对CAP理论，查阅了国外的相关文档表述，CAP理论来源于2002年麻省理工学院的Seth Gilbert和Nancy Lynch发表的关于Brewer猜想的正式证明。CAP 三个特性 描述如下 ：一致性 确保分布式群集中的每个节点都返回相同的 、 最近 更新的数据 。一致性是指每个客户端具有相同的数据视图。有多种类型的一致性模型 ， CAP中的一致性是指线性化或顺序一致性，是强一致性。可用性每个非失败节点在合理的时间内返回所有读取和写入请求的响应。为了可用，网络分区两侧的每个节点必须能够在合理的时间内做出响应。分区容忍 性 尽管存在网络分区，系统仍可继续运行并 保证 一致性。网络分区已成事实。保证分区容忍度的分布式系统可以在分区修复后从分区进行适当的恢复。原文主要观点有在强调CAP理论不能简单的理解为三选二。在 分布式数据库管理 系统中，分区 容忍性 是必须的。网络分区和丢弃的消息已成事实，必须进行适当的处理。因此，系统设计人员必须在一致性和可用性之间进行 权衡 。简单地说，网络分区迫使设计人员选择完美的一致性或完美的可用性。在给定情况下， 优秀 的 分布式 系统会 根据业务对一致性和可用性需求的重要等级 提供最佳的答案 ，但通常一致性需求等级会更高，也是最有挑战的 。2 BASE理论基于CAP定理的权衡，演进出了 BASE理论 ，BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。BA：Basically Available 基本可用，分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。S：Soft State 软状态，允许系统存在中间状态，而该中间状态不会影响系统整体可用性。E：Consistency 最终一致性，系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。BASE 理论本质上是对 CAP 理论的延伸，是对 CAP 中 AP 方案的一个补充。这里补充说明一下什么是强一致性：Strict Consistency （ 强一致性 ） 也称为Atomic Consistency （ 原子一致性） 或 Linearizable Consistency（线性一致性） ，必须满足以下 两个要求：1) 任何一次读都能读到某个数据的最近一次写的数据。2) 系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。简言之，在任意时刻，所有节点中的数据是一样的。BASE 理论的最终一致性属于弱一致性。接下来介绍另一个分布式数据库重要的概念：分布式事务。浏览了几篇介绍分布式事务的文章，发现会有不同的描述，但 大致 含义是相同的。分布式事务首先是事务， 需 要满足事务的ACID的特性。主要 考虑 业务访问处理的数据分散在网络间的多节点上，对于分布式 数据库 系统而言， 在 保证数据一致性 的要求下，进行事务的分发、协同多节点完成业务请求。多节点能否正常、顺利的协同作业完成事务是关键，他直接决定了访问数据的一致性和对请求响应的及时性。从而就需要科学有效的一致性算法来支撑。3 一致性算法目前主要的 一致性算法 包括 ：2PC 、 3PC 、 Paxos 、 Raft 。2PC ： Two-Phase Commit （ 二阶段提交 ） 也被认为是一种一致性协议，用来保证分布式系统数据的一致性。绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理。主要包括以下两个阶段：第一阶段：提交事务请求（投票阶段）第二阶段：执行事务提交（执行阶段）优点：原理简单、实现方便缺点：同步阻塞、单点问题、数据不一致、太过保守3PC ：Three- Phase Commi （ 三阶段提交 ）包括 CanCommit、PreCommit、doCommit 三个阶段。为了避免在通知所有参与者提交事务时，其中一个参与者 crash 不一致时，就出现了三阶段提交的方式。三阶段提交在两阶段提交的基础上增加了一个 preCommit 的过程，当所有参与者收到 preCommit 后，并不执行动作，直到收到 commit 或超过一定时间后才完成操作。优点：降低参与者阻塞范围，并能够在出现单点故障后继续达成一致 缺点：引入 preCommit 阶段，在这个阶段如果出现网络分区，协调者无法与参与者正常通信，参与者依然会进行事务提交，造成数据不一致。2PC / 3PC 协议用于保证属于多个数据分片上操作的原子性。这些数据分片可能分布在不同的服务器上，2PC / 3PC 协议保证多台服务器上的操作要么全部成功，要么全部失败。Paxos 、 Raft 、 Zab 算法 用于保证同一个数据分片的多个副本之间的数据一致性 。以下是三种算法的概要描述 。Paxos 算法主要 解决 数据分片的 单点问题 ， 目的是让整个集群的结点对某个值的变更达成一致。Paxos （ 强一致性 ） 属于多数派 算法 。任何一个点都可以提出要修改某个数据的提案，是否通过这个提案取决于这个集群中是否有超过半数的结点同意 ， 所以 Paxos 算法需要集群中的结点是单数 。Raft 算法 是简化版的Paxos ， Raft 划分成三个子问题：一是Leader Election；二是 Log Replication；三是Safety。Raft 定义了三种角色 Leader、Follower、Candidate，最开始大家都是Follower，当Follower监听不到Leader，就可以自己成为Candidate，发起投票 ，选出新的leader 。其有两个基本过程： Leader选举：每个 C andidate随机经过一定时间都会提出选举方案，最近阶段中 得 票最多者被选为 L eader。 同步log： L eader会找到系统中log（各种事件的发生记录）最新的记录，并强制所有的follow来刷新到这个记录。Raft一致性算法是通过选出一个leader来简化日志副本的管理，例如，日志项（log entry）只允许从leader流向follower。 ZAB基本与 raft 相同。三、 PostgreSQL分布式架构一览PostgreSQL发展时间线及分支图1 基于内核分布式方案Postgres-XL（1） 什么是Postgres-XLPostgres-XL是一款开源的PG集群软件，XL代表eXtensible Lattice，即可扩展的PG“格子”之意，以下简称PGXL。官方称其既适合写操作压力较大的OLTP应用，又适合读操作为主的大数据应用。它的前身是Postgres-XC（简称PGXC），PGXC是在PG的基础上加入了集群功能，主要适用于OLTP应用。PGXL是在PGXC的基础上的升级产品，加入了一些适用于OLAP应用的特性，如 Massively Parallel Processing (MPP) 特性。通俗的说PGXL的代码是包含PG代码，使用PGXL安装PG集群并不需要单独安装PG。这样带来的一个问题是无法随意选择任意版本的PG，好在PGXL跟进PG较及时，目前最新版本Postgres-XL 10R1，基于PG 10。社区发展史20042008 年， NTT Data 构建了模型 Rita-DB2009 年， NTT Data 与 EnterpriseDB 合作进行社区化开发2012 年， Postgres-XC 1.0 正式发布2012 年， StormDB 在 XC 基础上增加 MPP 功能 .2013 年， XC 1.1 发布 ； TransLattice 收购 StormDB2014 年， XC 1.2 发布 ；StormDB 开源为 Postgres-XL.2015 年，两个社区合并为 Postgres-X22016 年 2 月， Postgres-XL 9.5 R12017年7月 ， Postgres-XL 9.5 R1.62018年10月 ， Postgres-XL 10R1201 9 年 2 月 ， 宣布推出Postgres-XL 10R1 .1PostgreSQL与PGXC对比图（浙江移动谭峰分享）（2） 技术架构架构图1架构图2从上图可以看出Coordinator和datanode节点可以配置为多个，并且可以位于不同的主机上。只有Coordinator节点直接对应用服务，Coordinator节点将数据分配存储在多个数据节点datanode上。Postgres-XC主要组件有gtm（Global Transaction Manager） ， gtm_standby ， gtm_proxy, Coordinator 和Datanode。全局事务节点 ( GTM )， 是Postgres-XC的核心组件，用于全局事务控制以及tuple的可见性控制。gtm 为分配GXID和管理PGXC MVCC的模块 ， 在一个CLUSTER中只能有一台主的gtm。gtm_standby 为gtm的备机 。主要作用： 生成全局唯一的事务ID 全局的事务的状态 序列等全局信息gtm_proxy为降低gtm压力而诞生的, 用于对coordinator节点提交的任务进行分组等操作. 机器中可以存在多个gtm_proxy。协调节点 (Coordinator) 是数据节点 (Datanode) 与应用之间的接口， 负责接收用户请求、生成并执行分布式查询、 把 SQL 语句发给