1.什么是分布式数据库？物理上和逻辑上相互关联的数据库。分布式数据库管理系统（distributedDBMS）是一种支持分布式数据库管理的软件系统，它使分布对用户透明。有时，分布式数据库系统（DistributedDatabaseSystem，DDBS）被用来同时表示分布式数据库和分布式DBMS。”在上面的说法中，“一个群体分布在网络上并且在逻辑上相互关联”是其本质。物理上，一组逻辑上相互关联的数据库可以分布在一个或多个物理节点上，当然主要是应用于多个物理节点，一方面这与X86服务器性价比的提升有关，另一方面另一方面，互联网的发展带来了高并发和海量数据处理的需求，原来单一的物理服务器节点已经不足以满足这种需求，分布式不仅仅体现在数据库领域，与分布式存储、分布式中间件、分布式网络，最终目的是为了更好的服务于业务需求的变化，哲学意义上的理解是一种生产力的提高。二、分布式数据库的理论基础1、CAP理论首先，分布式数据库的技术理论是在继承单节点关系型数据库基本特性的基础上，主要涉及事务的ACID特性、事务日志的容灾、数据的容灾等。冗余。高可用的几个关键点。其次，分布式数据的设计必须遵循CAP定理，即分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错（Partitiontolerance）三个基本要求.满足其中两个，分区容错就不能放弃，所以架构师通常会在可用性和一致性之间做一个权衡。这里的权衡不是简单的放弃，而是考虑业务情况的牺牲，或者用一个互联网术语“降级”来形容。对于CAP理论，我查阅了国外的相关文献。CAP理论来源于麻省理工学院的SethGilbert和NancyLynch于2002年发表的布鲁尔猜想的形式化证明。CAP的三个特征描述如下：一致性：确保分布式集群中的每个节点返回同样，最近更新的数据。一致性意味着每个客户端都具有相同的数据视图。有许多类型的一致性模型。CAP中的一致性指的是线性化或者顺序一致性，也就是强一致性。可用性：每个非故障节点在合理的时间内返回对所有读写请求的响应。为了可用，网络分区两侧的每个节点都必须能够在合理的时间内做出响应。分区容忍：系统在网络分区的情况下继续运行并保证一致性。网络分区是事实。保证分区容错性的分布式系统可以在分区被修复后适当地恢复。原文的重点是强调CAP理论不能简单理解为三选二。在分布式数据库管理系统中，分区容忍度是必须的。网络分区和丢失的消息是一个现实，必须妥善处理。因此，系统设计者必须在一致性和可用性之间做出权衡。简而言之，网络分区迫使设计人员选择完美的一致性或完美的可用性。在给定的情况下，一个好的分布式系统将根据业务对一致性和可用性需求的重要性级别提供最佳答案，但通常一致性需求级别会更高且最具挑战性。2.BASE理论基于CAP定理的权衡，BASE理论得到了发展。BASE是BasicallyAvailable（基本可用）、Softstate（软状态）和Eventuallyconsistent（最终一致性）这三个词组的缩写。BASE理论的核心思想是：即使无法实现强一致性，各个应用也可以根据自己的业务特点采用合适的方法使系统达到最终一致性。BA：BasicallyAvailable基本可用。当分布式系统发生故障时，允许其失去部分可用性，即保证核心可用。s：softState软状态，允许系统有一个中间状态，中间状态不会影响系统整体的可用性。E：Consistencyfinalconsistency，系统中的所有数据副本经过一定时间后最终可以达到一致的状态。BASE理论本质上是CAP理论的延伸，是CAP中AP方案的补充。这里补充一下什么是强一致性：StrictConsistency（强一致性），也称为AtomicConsistency（原子一致性）或LinearizableConsistency（线性一致性），必须满足以下两个要求：1.任何读都可以读到最后一个某个数据的写入数据。2、对于系统中的所有进程，看到的操作顺序与全局时钟下的顺序是一致的。对于关系型数据库，要求更新后的数据能被后续访问看到，即强一致性。总之，在任何时刻，所有节点中的数据都是相同的。BASE理论的最终一致性是弱一致性。接下来介绍分布式数据库的另一个重要概念：分布式事务。浏览了几篇介绍分布式事务的文章，发现会有不同的描述，但大体意思是一样的。分布式事务首先是事务，需要满足事务的ACID特性。主要考虑是业务访问处理的数据分散在网络中的多个节点上。对于分布式数据库系统，在保证数据一致性的要求下，进行事务的分布式处理，协调多个节点完成业务请求。多个节点能否正常协同工作，顺利完成交易是关键，直接决定访问数据的一致性和响应请求的及时性。因此，需要一个科学有效的共识算法来支撑。3.共识算法目前主要的共识算法有：2PC、3pc、paxos、Raft。2PC：两阶段提交（Two-PhaseCommit）也被认为是一种保证分布式系统数据一致性的共识协议。大多数关系数据库使用两阶段提交协议来完成分布式事务处理。主要包括以下两个阶段：第一阶段：提交交易请求（投票阶段）第二阶段：执行交易提交（执行阶段）优点：原理简单，实现方便缺点：同步阻塞，单点问题，数据不一致，太muchConservative3PC:Three-PhaseCommi（三阶段提交）包括三个阶段：CanCommit、PreCommit和doCommit。为了避免在通知所有参与者提交事务时，当其中一个参与者不一致崩溃时，出现了三阶段提交方法。三阶段提交在两阶段提交的基础上增加了preCommit流程。当所有参与者都收到preCommit后，直到收到commit或者一定时间后操作完成后，他们才会执行操作。优点：减少参与者的阻塞范围，单点故障后可以继续达成共识。缺点：引入preCommit阶段。如果这个阶段出现网络分区，协调者无法与参与者正常通信，参与者仍然会提交事务。导致数据不一致。2PC/3PC协议用于保证对多个数据分片操作的原子性。这些数据分片可能分布在不同的服务器上，2PC/3PC协议保证了在多台服务器上的操作要么全部成功，要么全部失败。Paxos、Raft、Zab算法用于保证同一个数据分片的多个副本之间的数据一致性。以下是对三种算法的简要描述。Paxos算法主要解决数据分片的单点问题，目的是让整个集群的节点对某个值的变化达成一致。Paxos（强一致性）属于多数算法。任何节点都可以提出修改某个数据的提案。该提案是否通过取决于集群中是否有超过一半的节点同意。因此，Paxos算法要求集群中的节点数为奇数。Raft算法是Paxos的简化版。Raft分为三个子问题：一个是LeaderElection；另一个是日志复制；三是安全。Raft定义了三种角色：Leader、Follower和Candidate。一开始，每个人都是Follower。当Follower无法监控Leader时，可以自己成为Candidate，发起投票，选举出新的Leader。Ithastwobasicprocesses:①Leaderelection:Eachcandidatewillproposeanelectionplanrandomlyafteracertainperiodoftime,andthepersonwiththemostvotesinthemostrecentstagewillbeelectedastheleader.②同步日志：Leader会在系统的日志（各种事件发生的记录）中查找最新的记录，并强制所有的follower刷新到这条记录。Raft共识算法通过选择领导者来简化日志副本的管理。例如，日志条目只允许从领导者流向追随者。ZAB和raft基本一样。三、PostgreSQL分布式架构概述PostgreSQL发展时间线及分支图1.基于内核的分布式解决方案Postgres-XL（一）什么是Postgres-XLPostgres-XL是一款开源的PG集群软件，XL代表eXtensibleLattice，即扩展的PG“格”的意思，以下简称PGXL。按照官方的说法，它不仅适用于写操作压力大的OLTP应用，也适用于以读操作为主的大数据应用。它的前身是Postgres-XC（简称PGXC）。PGXC在PG的基础上增加了集群功能，主要适用于OLTP应用。PGXL是在PGXC的基础上升级的产品，增加了一些适合OLAP应用的特性，比如大规模并行处理（MPP）特性。通俗地说，PGXL的代码中包含PG代码，使用PGXL安装PG集群不需要单独安装PG。这样带来的一个问题就是不能随意选择任何版本的PG。好在PGXL及时跟进PG。最新版本Postgres-XL10R1，基于PG10。社区发展历程：2004年至2008年，NTTData构建模型Rita-DB。2009年，NTTData与EnterpriseDB合作进行基于社区的开发。2012年，Postgres-XC1.0正式发布。2012年，StormDB在XC的基础上增加了MPP功能。20132014XC1.2发布；StormDB作为Postgres-XL开源。2015年，这两个社区合并为Postgres-X2。2016年2月，Postgres-XL9.5R12017年7月，Postgres-XL9.5R1.62018年10月，Postgres-XL10R12019年2月，Postgres-XL10R1发布。1PostgreSQL与PGXC对比图（浙江移动谭峰分享）（二）技术架构图1从上图中我们可以看出，Coordinator和PGXC可以配置多个datanode节点，可以位于不同的主机上。只有Coordinator节点直接为应用服务，Coordinator节点在多个数据节点datanodes上分配和存储数据。Postgres-XC的主要组件有gtm（GlobalTransactionManager）、gtm_standby、gtm_proxy、Coordinator和Datanode。全局事务节点（GTM）是Postgres-XC的核心组件，用于全局事务控制和元组可见性控制。gtm是分配GXID和管理PGXCMVCC的模块。一个CLUSTER中只能有一个主gtm。gtm_standby是gtm的备用机器。主要功能：–生成一个全局唯一的事务ID–全局事务状态–序列gtm_proxy等全局信息的诞生是为了减轻gtm的压力，用于对coordinator节点提交的任务进行分组等操作。机器中可以有多个gtm_proxy。Coordinator是数据节点和应用程序之间的接口，负责接收用户请求，生成并执行分布式查询，将SQL语句发送到相应的数据节点。Coordinator节点不物理存储表数据，表数据以分片或复制的形式分布存储，表数据存储在数据节点上。当应用发起SQL时，会先到达Coordinator节点，然后Coordinator节点将SQL分发到各个数据节点，汇总数据。该系统进程由GXID和全局快照控制。数据节点（datanode）在物理上存储表数据，表数据存储方式分为分布式和复制两种。数据节点只存储本地数据。数据分布?replicatedtablecopytable–tablereplicatedonmultiplenodes?distributedtable分布式表–Hash–Roundrobin注意：Roundrobin轮转放置是最简单的划分方式：即每个元组会依次放置在下一个节点，如下图所示，以这种方式循环。(3)主站点https://www.postgres-xl.org/overview/https://wiki.postgresql.org/wiki/Postgres-XC2。扩展分布式解决方案Citus（一）什么是CitusCitus是PostgreSQL的一个开源分布式数据库，自动继承了PostgreSQL强大的SQL支持能力和应用生态（不仅是客户端协议的兼容，还有服务器扩展和管理工具的全面兼容）。Citus是PostgreSQL的扩展（不是分支）。它采用无共享架构。节点之间没有共享数据。数据库集群由协调器节点和工作节点组成。专注于高性能HTAP分布式数据库。与单机版PostgreSQL相比，Citus可以使用更多的CPU核心、更多的内存、保存更多的数据。通过向集群添加节点可以轻松扩展数据库。与其他类似的基于PostgreSQL的分布式解决方案，如GreenPlum和PostgreSQL-XL相比，Citus最大的不同在于它是PostgreSQL的扩展，而不是一个独立的代码分支。Citus可以以较小的成本和更快的速度跟上PostgreSQL版本的演进；同时可以最大程度保证数据库的稳定性和兼容性。Citus支持较新版本的PostgreSQL的功能，并与现有工具保持兼容。Citus使用分片和复制在多台机器上水平扩展PostgreSQL。它的查询引擎将在这些服务器上执行SQL，以并行查询大型数据集上的实时（亚秒级）响应。Citus目前分为以下几个版本：Citus社区版Citus商业版Cloud[AWS,cituscloud]此截图参考苏宁陈华君2020年3月Citus实践分享（二）技术架构此截图参考苏宁陈华军2020年3月华军Citus实践分享Citus集群由一个中心协调节点（CN）和若干个工作节点（Worker）组成。CN只存储与数据分发相关的元数据，将实际的表数据分成M个分片分发给N个Worker。这样的表称为“分片表”，可以为“分片表”的每个分片创建多份副本，以实现高可用和负载均衡。架构图1（参考苏宁Citus2019年实践分享）Citus官方文档推荐使用PostgreSQL原生流复制做HA，multi-replica-basedHA可能只适用于append-onlyshards。应用程序将查询发送到协调器节点，协调器处理它并将其发送到工作节点。对于每个查询，协调器将其路由到单个工作节点，或并行执行，具体取决于数据是在单个节点上还是跨多个节点。CitusMX模式允许直接访问工作节点以实现更快的读写速度。架构图2（参考苏宁Citus2019年实践分享）Citus有三种表分片表（最常用的）引用表本地表分片表主要解决大表水平扩展的问题，数据量不大特别大而且经常需要和分片表join的维表可以采用特殊的分片策略，只分一个slice，每个worker上部署一份。这样的表称为“参考表”。除了分片表和引用表之外，还有一张未分片的PostgreSQL原生表，称为“本地表”。“本地表”适用于一些特殊场景，比如高并发的小表查询。这张截图参考了苏宁陈华君Citus在2020年3月的做法，在共享客户端应用访问数据时，只与CN节点进行交互。CN收到SQL请求后，生成分布式执行计划，将各个子任务发送到对应的Worker节点，收集Worker结果，处理后返回最终结果给客户端。本截图引用苏宁陈华君2020年3月Citus实践分享（三）主站http://citusdb.cn/https://docs.citusdata.com/en/v8.2/4.总结大额处理方法数据、高并发混合业务数据访问、数据管理需要分布式数据库架构的有效支持，下面总结几个主要关键词：1.业务集成——TP/AP业务自动识别、功能调度计算节点；实时流处理；关系和非关系数据访问和转换；2、节点协作——多个计算节点协同工作；数据的多个副本；同城异地多次活动；3、冷热分离——定时定时统计，自动标记冷热数据，根据存储速度存储不同冷热程度的数据；4、架构解耦——微服务、计算和存储分离；5、弹性伸缩——在线伸缩；数据自动平衡；6、智能运维——自动调优；自动升降水平；运行可视化，自动报警。参考资料：分布式数据库概念：《分布式系统数据库系统原理》（第三版）CAP理论：《Understanding the CAP Theorem》/AkhilMehra《CAP和BASE理论》/~belief~Yin~基础理论：《终于有人把“分布式事务”说清楚了!》/陈明宇·《强一致性、顺序一致性、弱一致性和共识》/chao2016共识算法：·《分布式理论系列(二)一致性算法：2PC 到 3PC 到 Paxos 到 Raft 到 Zab》/binarylei·《Paxos和Raft快速理解》/建怀PGXL·《初识Postgres-XL》/joyeuCitus·博客《小乔河西》·《PostgreSQL中的分库分表解决方案》/唐成
