定义
满足分布式、逻辑相关性、场地透明性、场地自治性的数据库系统称为完全分布式数据库系统。
-
分布式：
- 定义：分布式数据库是指数据存储在计算机网络中的不同计算机上。这些计算机通过网络互相连接，共同组成一个数据库系统，使得数据在物理上分散，但在逻辑上是一个统一的整体。
- 特点：数据的分布性是分布式数据库的核心特征，它允许数据跨多个节点存储和处理。
-
逻辑相关性：
- 定义：逻辑相关性指的是数据库中的数据在逻辑上保持一定的关系，即使这些数据物理上分布在不同的节点上。这种逻辑关系通常通过数据库的模式（schema）来定义。
- 特点：逻辑相关性保证了分布式数据库在逻辑上的完整性和一致性，使得用户可以透明地访问分布在各个节点上的数据。
-
场地透明性（Location Transparency）：
- 定义：场地透明性是指用户或应用程序在访问分布式数据库时，不需要知道数据具体存储在哪个物理位置。系统自动处理数据的分布和位置信息。
- 特点：场地透明性使得数据库的使用者可以忽略数据的物理分布，像访问集中式数据库一样访问分布式数据库。
-
场地自治性（Site Autonomy）：
- 定义：场地自治性是指分布式数据库中的每个节点（场地）具有一定的独立性，能够独立处理本地数据的存储和管理，同时也能参与全局应用。
- 特点：每个节点可以自主执行局部事务处理，同时也能通过网络与其他节点协同工作，完成全局事务。
特点
- 共享性。不同结点的数据共享
- 自治性。每个结点对本地数据都能独立管理
- 可用性。某一个场地故障时，可以使用其他场地上的副本而不至于整个系统瘫痪
- 分布性。数据分布在不同场地上的存储
分布式数据库体系结构
分布式数据库架构分为全局外模式、全局概念模式、分片模式、分布模式、局部概念模式、局部内模式
- 全局外模式。全局外模式是全局应用的用户视图，是全局概念模式的子集，该层直接与用户交互
- 全局概念模式。全局概念模式定义分布式数据库中数据的整体逻辑结构，数据就如同根本没有分布一样，可用传统的集中式数据库所采用的方法进行定义
- 分片模式。将一个关系模式分解成为几个数据片
- 分布模式。分布式数据库的本质特性就是数据分布在不同的物理位置。分布模式的主要职责就是定义数据片段（即分片模式的处理结果）的存放节点
- 局部概念模式。局部概念模式是局部数据库的概念模式
- 局部内模式。局部内模式是局部数据库的内模式
分布式数据库优点：
- 坚固性好：由于分布式数据库是由多个位置上的多台计算机构成的，在个别节点或个别通信链路发生故障时，它仍然可以降低级别继续工作，如果采用冗余技术，还可以获得一定的容错能力。因此系统坚固性好，可靠性和可用性高。
- 可扩充性好：可根据发展的需要增减结点，或对系统重新配置，这比用一个更大的系统替代一个已有集中式数据库要容易的多。
- 可改善性能：在分布式数据库中可按就近分布，合理地冗余的原则来分布各结点上的数据，构造分布式数据库，使大部分数据可以就近访问，避免了集中式数据库中的瓶颈问题，减少了系统的响应时间，提高了系统的效率，而且也降低了通信费用。
- 自治性好：数据可以分散管理，统一协调，即系统中各结点的数据操纵和相互作用是高度自治的，不存在主从控制，因此，分布式数据库较好地满足了一个单位中各部门希望拥有自己的数据，管理自己的数据，同时又想共享其他部门有关数据的要求。
分布透明性
分布式数据库的分布透明性分为分片透明性、位置透明性、逻辑透明性、复制透明
- 分片透明性。 是分布透明性的最高层次。用户或应用程序只对全局关系进行操作而不必考虑数据的分片
- 位置透明性 。用户或应用程序应当了解分片的情况，但不必了解分片的存储场地
- 局部数据模型（逻辑透明性）。了解分片即各片段的的存储场地，但不必了解局部场地上使用的是何种数据模型。
- 复制透明。是指采用复制技术的分布方法，用户不需要知道数据是复制到哪些节点以及如何复制的。
分布式事务
分布式事务的挑战
- 传统的事务主要是单机数据库的ACID 特性。分布式事务指事务的发起者，资源，及资源管理器，事务协调者分别位于不同的分布式系统的不同节点之上。
- 分布式事务包括
- 跨库事务问题
- 微服务化事务问题
- 消息事务问题
分布式事务解决方案
二阶段提交
两阶段提交是一种最常用的分布式事务协议，它分为两个阶段：准备阶段（表决阶段）和提交阶段（执行阶段）
- 准备阶段：协调者（Coordinator）向所有参与者（Participants）发送准备请求。参与者收到请求后，执行事务但不提交，然后向协调者反馈是否可以提交。
- 提交阶段：如果所有参与者都同意提交，协调者向所有参与者发送提交请求，参与者正式提交事务；如果有任何一个参与者不同意，协调者向所有参与者发送回滚请求，参与者回滚事务。
XA 方案
- 最早解决跨库事务问题的方法，它基于资源层(数据库层)
- 通过二阶段提交的方式，满足分布式事务
- 优势： 接口标准化 ，门槛较低，强一致性
-
缺点：
-
同步阻塞，所有的节点的事务都是阻塞的，只有全部提交之后才能释放所有占有的资源
-
数据不一致，第二阶段提交的协调者向参与者发送请求后，部分参与者由于网络异常导致没有接收到commit请求，这样会导致部分参与者已经提交，另一部分没有提交出现数据不一致的现象
- 高并发下性能不理想，很难满足互联网大并发需求
- 没办法解决微服务事务问题
-
流程
- AP 向TM 创建全局事务，TM 向AP 返回全局事务ID
- AP 使用全局事务ID，访问RM资源，RM 向TM 注册，TM 返回分支事务ID
- AP 向TM 发出全局事务提交请求，TM 与RM 通信后，RM 提交事务，全部完成后向AP提交
TCC 补偿方案
- TCC主要采用的补偿机制，针对每一个操作搜需要注册一个确认和补偿操作，tcc分为三个阶段：
- try：主要的业务流程
- commit：业务系统确认提交
- cancel：执行错误之后，回滚业务
- 基于应用层，符合业务需求。
- 要求每个方案实现一个反向的回滚接口
- 缺点：
- 业务代码侵入型太强，需要写补偿代码
- 对开发者要求高，实现复杂，各种异常情况难于处理
- 运维成本高，扩展一致性不理想
可靠性消息投递方案
- 这种方案通常用于基于消息队列的分布式系统，例如使用Apache Kafka或RabbitMQ
- 基于应用层，要求业务实现幂等
- 优点：降低业务系统的耦合
- 缺点
- 要求应用与消息系统紧耦合，增加并发成本
- 最终一致性，适用场景受限，不太适应一致性要求非常高的场景
流程：
- 消费者向MQ发送消息，出入prepare阶段
- 消费者执行本地事务逻辑
- 本地事务执行成功后，向MQ返送commit/rollback操作
- MQ收到commit/rollback后决定消息是否投递
- 消费者消费消息执行本地事务
Saga
- Saga是一种用于处理分布式事务的长期运行的事务模式，它将长事务分解为一系列的短事务，每个短事务都是一个补偿事务。
- 正向操作：每个子事务执行所需操作。
- 补偿操作：如果某个子事务失败，则执行一系列补偿事务来回滚之前的事务。
流程：
- TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
- XID 在微服务调用链路的上下文中传播。
- RM 向 TC 注册分支事务，接着执行这个分支事务并提交（重点：RM在第一阶段就已经执行了本地事务的提交/回滚），最后将执行结果汇报给TC。
- TM 根据 TC 中所有的分支事务的执行情况，发起全局提交或回滚决议。
- TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。
AT 模式
- AT模式是一种分布式事务处理模式，它由Seata框架提出。AT模式的目标是让分布式事务的提交和回滚像本地事务一样简单和高效，无需开发者编写额外的补偿逻辑。
- 在AT模式下，分布式事务的处理主要分为两个阶段：
- try：在这个阶段，Seata会拦截业务SQL，解析SQL的业务含义，生成对应的反向SQL（即回滚SQL），然后将业务SQL和反向SQL在同一个本地事务中一起提交到数据库。在这个过程中，Seata还会记录业务SQL操作的数据在事务前后的快照，并将这些快照信息保存到Undo Log（回滚日志）中。
- confirm/cancel：在尝试阶段成功完成后，分布式事务将进入确认或回滚阶段，这取决于全局事务的最终状态。
- 确认阶段（Confirm）：如果全局事务成功，则Seata会提交全局事务。在AT模式下，由于业务SQL已经在尝试阶段提交，所以确认阶段实际上不需要执行任何操作。
- 回滚阶段（Cancel）：如果全局事务失败，Seata会根据之前记录的Undo Log执行回滚SQL，将数据恢复到事务开始前的状态。
- 优点：
- 对业务无侵入：业务代码无需编写额外的回滚逻辑。
- 性能较好：相比TCC模式，AT模式在正常情况下只需一次数据库交互，性能开销较小。
- 易用性：简化了分布式事务的处理，让开发者能够像处理本地事务一样处理分布式事务。
- 缺点：
- 数据一致性问题：在极端情况下，如果业务SQL执行后数据被外部修改，回滚操作可能无法完全恢复到事务前的状态。
- 数据库支持：AT模式依赖于数据库的特定功能（如全局锁、多版本并发控制MVCC等），因此可能不是所有数据库都支持。