分布式数据库架构和原理

分布式数据库简介

分布式数据库定义为一群分布在计算机网络上、逻辑上相互关联的数据库。分布式数据库管理系统(分布式DBMS)则是支持管理分布式数据库的软件系统，它使得分布对于用户变得透明。有时，分布式数据库系统(Distributed Database System,DDBS)用于表示分布式数据库和分布式DBMS这两者。

分布式数据库架构及原理

1.CAP理论

首先，分布式数据库是基于单点关系数据库的基本特性的继承，主要涉及事务的ACID特性、事务日志的容灾恢复性、数据冗余的高可用性几个要点。

其次，分布式数据设计必须遵循CAP定理：分布式系统不能同时满足 一致性(Consistency) 、可用性(Availability) 、分区容忍性(Partition tolerance) 这三个基本需求，最多满足其中的两项， 由于分区容错性是绝对不能抛弃的，因此需要考虑业务情况在可用性和一致性之间做出权衡。

CAP三个特性描述如下 ：

一致性(Consistency)：确保分布式群集中的每个节点都必须返回相同的 、最近更新的数据 。一致性是指每个客户端具有相同的数据视图。有多种类型的一致性模型 ， CAP中的一致性是指线性化或顺序一致性，是强一致性。

可用性(Availability)：每个非失败节点在合理的时间内返回所有读取和写入请求的响应。为了可用，网络分区两侧的每个节点必须能够在合理的时间内做出响应。

分区容忍性(Partition tolerance)：尽管存在网络分区，系统仍可继续运行并 保证 一致性。网络分区已成事实。保证分区容忍度的分布式系统可以在分区修复后从分区进行适当的恢复。

根据实际业务情况， 分布式系统会根据业务对一致性和可用性需求的重要等级提供最佳解决方案，但通常一致性等级会更高，也是最有挑战的 。

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 / 3PC 协议用于保证属于多个数据分片上操作的原子性。

这些数据分片可能分布在不同的服务器上，2PC / 3PC 协议保证多台服务器上的操作要么全部成功，要么全部失败。

二阶段提交2PC (Two-Phase Commit )： 用来保证分布式系统数据的一致性的一致性协议，大部分基于关系型数据库的分布式事务处理都是采用二阶段提交协议来完成。其优点是原理简单且实现方便，缺点是同步阻塞、单点问题、数据不一致、太过保守。

2PC主要包括以下两个阶段：

第一阶段：提交事务请求(投票阶段)

第二阶段：执行事务提交(执行阶段)

为了避免在通知所有参与者提交事务时，其中一个参与者 crash 不一致时，就出现了三阶段提交的方式。

三阶段提交 3PC(Three- Phase Commi )：包括 CanCommit、PreCommit、doCommit 三个阶段。显而易见，三阶段提交是在两阶段提交的基础上增加了一个 preCommit 的过程，当所有参与者收到 preCommit 后，并不执行动作，直到收到 commit 或超过一定时间后才完成操作。

其优点是降低参与者阻塞范围，并能够在出现单点故障后继续达成一致;缺点是引入preCommit 阶段，在这个阶段如果出现网络分区，协调者无法与参与者正常通信，参与者依然会进行事务提交，造成数据不一致。

Paxos 、 Raft 算法用于保证同一个数据分片的多个副本之间的数据一致性 。以下是两种种算法的描述 :

Paxos (强一致性)算法属于多数派算法，主要目的是解决数据分片的单点问题， 通过该算法可以让整个集群的节点对某个值的变更达成一致。任何一个节点都可以提出要修改某个数据的提案，是否通过这个提案取决于这个集群中是否有超过半数的节点同意，因此Paxos算法需要集群中的节点必须是单数 。

Raft算法是简化版的Paxos， 定义了三种角色 Leader、Follower、Candidate：最初都是Follower，当Follower监听不到Leader，就自动成为Candidate，然后发起投票选出新的Leader 。因此，Raft 划分成三个子问题：

Leader Election
Log Replication
Safety

其有两个基本过程：

① Leader选举：每个 Candidate随机经过一定时间都会提出选举方案，最近阶段中得票最多者被选为Leader;

② 同步log：Leader会找到系统中log(各种事件的发生记录)最新的记录，并强制所有的follow来刷新到这个记录。

Raft一致性算法是通过选出一个leader来简化日志副本的管理，例如，日志项(log entry)只允许从leader流向follower。

以上就是动力节点小编介绍的"分布式数据库架构和原理"，希望对大家有帮助，想了解更多可查看Java分布式应用教程。动力节点在线学习教程，针对没有任何Java基础的读者学习,让你从入门到精通,主要介绍了一些Java基础的核心知识，让同学们更好更方便的学习和了解Java编程，感兴趣的同学可以关注一下。