第九讲软件服务质量保障技术.pptVIP

加锁：Locking 进程在访问共享的资源之前，必须获得所有的锁 在访问共享的资源之后，必须释放所有的锁 2PL: 进程一旦开始释放锁，它再不能获取其它的锁 一个典型的 2PL 加锁过程为： 锁的兼容性 进程是否能够获得锁取决于所请求的锁是否与资源目前的锁状态（其它进程已请求的锁）兼容 兼容性由锁兼容性矩阵决定 最小的锁兼容性矩阵: 锁冲突 如果所请求的锁与资源的锁状态不兼容，则不能获得所请求的锁 这被称为“锁冲突” 处理锁冲突的方法有： 强迫请求进程等待，直到冲突的锁被释放 告诉请求进程，无法获得所请求的锁 死锁 2PL 可能导致死锁状态 在该状态下，多个进程分别获取部分所需的资源，并互相等待其它进程释放资源 死锁必须通过终止一个或多个相关的进程才能得到解决 这需要被终止的进程放弃它们已经进行的所有操作 解决死锁的核心在于避免死锁 锁粒度 2PL适用于任意粒度的资源 并发程度高的进程将需要小粒度的锁机制 小粒度的锁机制将导致需要较大数目的锁实现 这将导致系统开销的增加 因此，在实现具体系统时，需要在并发度与锁开销之间进行权衡 层次锁是其中的一种折中方案 层次锁 用于内部包含其它内容的资源 例如： 文件 (包含多条记录) 集合或序列 (包含对象) 锁状态增加了 intention read (IR) 与 intention write (IW) 用于标识资源祖先的状态 锁的兼容性: 锁的透明性 谁请求锁？ 并发控制基础设施 构件的实现体 构件的客户 第一种情形很好，但不易实现: 基础设施必须管理所有资源 基础设施必须掌握所有对资源的访问 最后一种情形是不期望的、需要避免的! 3）乐观并发控制 2PL的复杂度与被访问资源的数目呈线性关系 如果冲突发生的概率较小时，开销偏大 乐观并发控制的思路是： 进程首先修改资源状态的（逻辑）副本 验证并发进程之间的冲突 如果没有冲突：写回副本 否则：取消所有修改并重新开始 4）比较 共性： 都保证可串行化 需要一个取消过程 两阶段锁: 锁开销较大 可能出现死锁 在易于冲突时工作得好 乐观控制: 冲突概率小时开销小 不会出现死锁 在分布式系统中冲突集合的计算复杂 时间同步开销较大 事务性客户 仅通过协调器获取与事务相关的具体操作内容 通过访问协调器 进行 事务的启动与提交动作 事务的实现 对于事务性客户是透明的 对于事务性客户而言，一个服务器是否是事务性的是透明的 事务性服务器 每个事务性服务器在事务协调器的控制下 访问、修改 资源 事务性服务器必须能随时访问协调器 事务性服务器必须在事务启动时向协调器注册 以便于协调器进行控制 事务性服务器必须实现事务协议（两阶段提交协议） 协调器 实现分布式事务的关键部件 分布式事务协调者负责处理事务的 “开始”、“提交”以及“终止”操作 分布式事务协调器需要定位事务标识 不同的事务可以拥有不同的分布式事务协调器 Phase one: 投票（Voting） Phase two: 完成（Completion） Phase One 投票阶段 协调器询问各服务器 —是否能够（愿意）进行提交操作？ 各个服务器回应： —Yes: 表明可以根据指令进行提交 但尚不知道是否真的将执行提交动作 —No: 表明终止当前的操作 因此： 服务器可以 单方面地终止一个事务 但不能单方面地提交一个事务 Phase Two 完成阶段 协调器收集投票，并决策： 如果每个服务器皆投 ‘Yes’，则进行提交 如果任何一个服务器投 ‘No’，则进行终止 所有投 ‘Yes’ 的服务器将接受到： ‘DoCommit’ 命令，如果事务将被提交 ‘Abort’命令，如果事务不能被提交 各服务器提交自己包含的事务操作 并对“DoCommit ”命令给予回复(HaveCommitted) 服务器的不确定时期 服务器在投“Yes”票后，处于能够提交，但不清楚是否必须提交的状态 该时间段被称为server uncertainty期 通常该时间段很短 协调器从接受到处理各投票的时间段 仍然可能存在故障（小概率事件），导致系统发生错误 两阶段提交的恢复 2PC启动（各服务器开始投票）之前发生的任何故障将导致“终止” 协调器在“提交决策”之前发生错误将导致“终止” 在该时刻之后（进行“提交决策”）发生故障，协调器将重启动（该过程中协调器保存了事务参与者的信息），然后，重新对所有提交消息进行决策 如果在投票之后、提交之前发生故障，服务器将在重新启动后，通知协调器重新计算投票结果 如果提交之后、回复之前发生故障，服务器将在重新启动后，向协调