分布式数据库.pptVIP

Copyright: Silberschatz, Korth and Sudarhan 第19章: 分布式数据库 分布式数据库系统 同质分布式数据库 在同质的分布式数据库系统中 所有站点都有相同的软件 所有站点相互知晓并可以合作处理用户请求 每个站点因不能改变模式和软件而丧失部分自治性 在用户看来是单个系统 在异质的分布式数据库系统中 不同站点可用不同模式和软件 模式差异是查询处理中的主要问题 软件差异是事务处理中的主要问题 站点可能相互不知晓，并且在事务处理中只能提供有限的合作手段 分布式数据存储 数据复制 数据复制 (续) 数据分片 account 关系的水平分片 employee-info 关系的垂直分片 分片的优点 数据透明性 数据项的命名 – 准则 集中式方案 – 名字服务器 使用别名 分布式事务 分布式事务 事务系统结构 系统故障方式 提交协议 两阶段提交协议(2PC) 阶段1: 形成决定 阶段2: 记录该决定 故障处理 – 场地故障 故障处理 – 协调者故障 故障处理 – 网络分割 恢复与并发控制 三阶段提交(3PC) 事务处理的其他模型 跨多站点的单个事务之概念对许多应用来说不合适 例如跨越组织边界的事务 没有组织会允许外部事务阻塞本地事务一个不确定的时间段 一个替换模型通过发送消息来执行事务 处理消息的代码必须小心设计以确保更新的原子性和持久性性质 隔离性不能保证, 因为中间阶段可见, 但代码必须确保不会因并发而导致不一致状态 持久消息系统是对消息提供事务性质的系统 能确保消息仅发送一次 稍后讨论实现技术 替换模型(续) 促动例: 两家银行间的资金转帐 两阶段提交具有阻塞对资金转帐中涉及的帐户的更新的潜在可能 替换解决方案: 将来自源帐户的款项记入借方并发送一个消息给其他站点 站点接受消息并记入目标帐户的贷方 消息机制早就用于分布式事务(甚至在计算机发明以前!) 原子性问题 一旦发送消息的事务提交, 该消息必须确保能被送到 只要目标站点活着并可达就要确保, 还必须有处理不可送达消息的代码 例如将款项记回源帐户的贷方. 如果发送事务夭折, 消息就不能发送 持久消息机制的错误条件 处理消息的代码必须考虑各种故障情形 例如如果目标帐户不存在, 失败消息必须送回到源站点 当从目标站点接收到失败消息, 或者目标站点本身不存在, 款项必须存回源帐户 如果源帐户关闭又有问题 需要人来处理问题 利用2PC执行事务处理的用户代码不必处理这种故障 在很多场合下, 付出额外努力进行错误处理换来消除阻塞的好处是值得的 例如跨组织的事务 持久消息与工作流 工作流提供一个涉及多站点以及可能需要人工处理某些步骤的事务处理的一般模型 例如当银行接收一个贷款申请, 它可能需要 联系外部信用检查机构 获得一个或多个经理的批准 然后才能对贷款申请作出反应 我们在第24章讨论工作流 持久消息机制形成了分布式环境中工作流的基础结构 持久消息机制的实现 发送站点协议 发送事务写消息到一特殊关系messages-to-send. 该消息获得一个唯一标识符. 写此关系处理为与任何其他更新相同, 若事务夭折则取消. 该消息上的锁保持到发送事务提交 消息传送进程监控关系messages-to-send 当发现有新消息, 该消息被送往其目的地 当从目的地收到确认, 该消息从messages-to-send 中删除 如果经过一段时间还没有收到确认, 重发该消息 重复此过程直至收到确认而删除该消息, 或者系统在尝试很长时间后确定该消息不可投送 重复发送保证了该消息的投送 只要目的地存在并且在合理时间内可到达 持久消息机制的实现 接受站点协议 当收到一条消息时 写到关系received-messages 中, 如果还不存在的话(利用消息id做此检查). 执行写的事务提交 发送确认(连同消息id)给发送站点. 在有重复消息时消息投送可能有很长延迟 如果不小心可导致处理副本消息! 选择1: 消息永远不从received-messages中删除 选择2: 消息带有时间戳 比给定截止点更老的消息从received-messages中删除 接受到的消息如果比截止点更老则丢弃 分布式数据库的并发控制 并发控制 单个锁管理器的方法 单个锁管理器方法(续) 分布式锁管理器 在这种方法中, 锁的功能由每个场地上的锁管理器实现 锁管理器控制对本地数据项的存取 但对副本可使用特殊协议 优点: 工作被分布, 对故障鲁棒 缺点: 死锁检测更复杂 锁管理器合作进行死锁检测 稍后详及 此方法的若干变种 主副本 多数协议 偏见协议 法定数一致 主副本 多数协议 多数协议 (续) 偏见协议 法定数一致协议 是对多数协议和偏见协议的一般化 赋予各场地一个权值. 令S为所有场地的权值总和