分布式数据库产品

商业数据库的许可费用高 应用层和服务层的业务逻辑变化很快，对于扩 展性要求较高
8
分布式数据库--数据拆分
水平拆分，拆分数据
垂直拆分，拆分业务 把一个表结构拆分为两个表结构 例如：把下表拆分为账户表和用户信息表
账 户 密 码 区 域 状 态 用户 姓名 手 机 家庭 电话 联系地 址 邮箱 性别 ……
由查询发起的数据库进行数据收集，其他节点的数据库把相关的数据传输到发 起数据库后，进行查询处理； 目标：一个好的分布式查询，应该使数据的传输量和通信 次数最少，这样才能使查询所花费的数据传输和通信时间 最少，从而减少查询的总代价；
16
16
分布式数据库--跨库Join查询
查看用户名User1的购买的订单中产品类型为“电子类”的金额总数； 产品表（Pid，Pname，type，price） 用户表（Uid，Uname） 订单表（Oid，Uid，TotalPrices） 订单明细表（id，Oid，Pid，amount，prices） SELECT 用户表.Uname，产品表.type，count(订单明细表.Pries) AS 购买金额总数
5
存 款 操 作
2
取 款 操 作
中间 状态 缓存
4 调用异地支行B中的存款服务，运行存款服务业务；
5 为某账户存款100元，该账户余额增加100元； 6 7 8
通知支行A的取款服务，汇款操作完成，并通知事务中间状态缓存，修改存款 操作的状态为成功，解锁支行A冻结的账户，并通知用户；
如果第六步存款操作不成功，事务中间状态缓存会持续调用支行B存款服务， 直到存款操作成功完成； 如果多次调用存款服务，存款操作没有成功执行，事务中间状态缓存会回滚 该汇款转账分布式事务，回滚支行A中的取款操作（根据取款操作的逆向 操作）； 正向操作和逆向操作都有可能会出现多次调用；
两阶段提交协议的问题： 性能瓶颈，数据库在提交 请求阶段应答后对很多资 源处于锁定状态，要等到 事务管理器收集齐所有数 据库的应答后，才能发 commit或者rollback消息 结束这种锁定；（锁定时 间的长度是由最慢的一个 数据库制约） 分布式系统中节点越多， 存在缓慢网络或者故障节 点的概率也就越大，资源 被长时间锁定的概率指数 上升； 从业务功能划分的角度上 ，尽量避免使用分布式事 务两阶段提交； 12
FROM 产品表，用户表，订单表，订单明细表
Where 用户表.Uname =‘User1’ AND 产品表.type = ‘电子类’ AND 用户表.Uid = 订单表.Uid AND 订单表.Oid = 订单明细表.Oid AND 产品表.Pid = 订单明细表.Pid
用户名 User1
产品类型 电子类
分布式事务--两阶段提交
分布式事务处理（ Distributed Transaction Processing ， DTP ）涉及多个分布在不同地方的数据库 ，但对数据库的操作必须全部被提交或者回滚。只要任一数据库操作时失败，所有参与事务的数据库都需 要回滚。使用两阶段提交协议2PC。
第 一 阶 段 ： 准 备 阶 段 第 一 阶 段 ： 准 备 阶 段
4
并行数据库
并行数据库系统（Parallel Database System）是新一代高性能的数据库系统，是在 MPP和集群并行计算环境的基础上建立的数据库系统。
并行数据库系统的目标是高性能（High Performance）和高可用性（High Availability），通过多个处理节点并行执行数据库任务，提高整个数据库系统的 性能和可用性。并行数据库系统基于多处理节点的物理结构，将数据库管理技术与 并行处理技术有机结合，来实现系统的高性能。并行数据库分为：
6
分布式数据库--透明性
分布式数据库系统的用户不需要知道数据的物理位置，也不需要知道如何访问某 个数据库节点的数据；
切片透明性：用户不需要知道数据是如何进行切 片的； 复制透明性：用户不需要关心数据或者切片的如 何复制的，也不需要关心副本存放的位置； 位置透明性：用户不需要关心数据的物理位置， 也不需要关心如何找到数据；
事务补偿分为两种机制，事务补偿机制和基于消息的最终一致性机制： • • 事务补偿机制，基本可以是做到准实时的事务补偿（实时性较好） ，但需要大量的代码研发工作来保障事务的完整性； 基于消息的最终一致性机制，对于实时性要求不高，可使用BASE策 略中的基于消息的最终一致性是比较好的解决方案。这种方案真正 实现一个事务的两个服务的真正解耦，解耦的关键就是异步消息和 消息持久化机制。
产品表 订单明细表 数据库A
查询库
用户表 订单表 数据库B
策略4：在Application层，对SQL查询进行分解查询，在Application层的内存中进行数据的合 并统计，并产生最终查询结果，对数据库的性能和网络带宽开销很小，但会增加应用层的性能 开销，不适合中间结果数据较大的查询； 策略5：需要跨库查询的关系表，四个表复制到一个查询库，由查询库提供分布式查询；
预备（Prepare）
事务 管理 器
提交（Commit）
DB2
就绪（Ready） 预备（Prepare）
事务 管理 器
DB1
已提交确认 提交（Commit）
DB2
就绪（Ready）
DB1
已提交确认 回滚（Rollback）
DB2 事务 管理 器 DB1
第 二 阶 段 ： 提 交 阶 段 第 二 阶 段 ： 回 滚 阶 段
切分策略、节点路由、全局主键生成 、跨节点排序/分组/表关联、多数据 源事务处理和数据库扩容等。
10
分布式数据库--分库分表
通过切片对集中式数据库进行分库分表，把一个数据库的业务数据分成多个物理数据库。
数据量小，增 量缓慢，则不 需要再划分
目标：一次数据库业务数据的操作（查询、更改数据） ，在一个数据库中完成。
购买金额总数 16800元
Application
Proxy
策略1：把用户表和产品表的数据传输到数据库A中进行查询，性能很差，浪费网络带宽； 策略2：把数据库A的数据传输到数据库B中进行查询，性能很差，浪费网络带宽； 策略3：在Proxy中进行SQL拆分，例如在数据库B中，先查询 用户“User1”的所有订单编号 ，把该用户的订单编号传输到数据库A中执行进一步数据查询，性能快，网络带宽开销很小；
取款服务 存款服务
7 1
取 款 操 作 取款 回滚
2
发送 存款 消息
调 用
3 6
再 次 调 用
消息 中间 件
结 果 通 知
5
4
存 款 操 作
实时性较差，但对 系统性能开销很小
7
取款 回滚
DB1
DB2
支行A
支行B
15
15
分布式数据库--跨库Join查询
分布式查询处理，从应用层或者服务层的角度，应用业务功能划分的越清晰，越 能避免在分布式数据库环境中出现跨库Join查询的情况。 由应用层或者服务层进行跨库Join的分布式查询的SQL分解，并在内存中保存中 间数据结果并做最终的数据查询的结果合并；
8
取款 回滚
DB1
DB2
支行A
准实时性，会增加分 布式系统的复杂度
支行B
14
14
分布式事务--基于消息最终一致性机制
对于转账操作，原有的两个服务调用变化为第一步调用本地的取款服务，第二步发送异地取款的异步消息到消息中间件。消 息中间件得到消息后对消息解析，然后调用异地银行提供的存款服务进行存款，如果服务调用失败则进行重试以保证事务的 最终一致性。只要两个操作都成功即可以返回客户成功。 在本地取款到异地存款两个服务调用之间，会存在一个真空期，这段时间相关现金不在任何一个账户，而只是在一个事务的 中间状态，但是客户并不关心这个，只要在约定的时间保证事务最终的一致性即可。
调 用
Hale Waihona Puke 4 6结 果 通 知
取款服务
7 1
登 记
存款服务
1
汇款转账分布式事务登记，开始一个分布式事务，生成分布式事务每一个操 作的逆向操作和运行状态；
3
修改 状态
6
再 次 调 用
2 从支行A的某账户中取款100元，账户余额减去100元，并冻结账户；
3 通知事务中间状态缓存，取款事务操作提交完成，修改取款操作的状态；
2.
避免跨库操 作。如需要 ，在应用层 协调解决此 问题。
数据量大，增量 迅速，则需要再 进行水平拆分
最后拆分到五个数据库中
对数据库进行分库分表(Sharding)前，需要开发人员充分了解系统业务逻辑和数据库结构：
建议是绘制一张数据库ER图或领域模型图，如果项目使用数据驱动的开发方式，团队以数据库ER图作为业务交流的基 础，则自然会选择数据库ER图 如果项目使用的是领域驱动的开发方式，并通过OR-Mapping构建了一个良好的领域模型，那么领域模型图无疑是最 好的选择。更加倾向使用领域模型图，因为进行切分时更多的是以业务为依据进行分析判断，领域模型无疑更加清晰和 11 直观。
集中式数据库系统：运行在一台计算机上，不与其他计算机 系统交互的数据库系统；
客户-服务器数据库系统：计算机的的联网使的任务可以分别 划分在服务器和客户端上执行； 并行数据库系统：通过网络连接多个CPU和磁盘来提高处理 速度和I/O速度；
分布式数据库系统：分布式数据库系统用来处理地理上或者 管理上分布在多个数据库系统中的数据；
13
分布式事务--事务补偿机制
在应用层或者服务层中，任何一个分布事务的正向操作都必须生成一个符合回滚规则的可逆向操作。 例如：一个用户跨银行的转账，该事务涉及到调用两个Service服务，一个是本地提供的取款服务，一个 是异地目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。