cmu440(8) Distributed Concurrenc
2018-02-10 本文已影响0人
lqsss
Distributed Transactions
- 与以前类似的想法，但是：
- 状态遍布服务器（甚至可能是WAN）
- 希望启用单个事务来读取和更新全局状态，同时保持ACID属性
- 总体思路：
- 客户端启动事务。利用“协调员”
- 所有其他相关的服务器作为“参与者”
- 协调员分配唯一的交易ID（TID）
2-Phase commit
- 准备和投票
- 参与者找出所有状态变化
- 每个决定是否可以完成交易
- 与协调员沟通
- 提交
- 协调员向参与者进行广播：COMMIT / ABORT
- 如果COMMIT，参与者进行相应的状态更改
实现
- 作为一组消息来实现
- 协调员和参与者之间
- 消息在第一阶段
- A：协调员向参与者发送“CanCommit？”
- B：参与者回应：“投票提交”或“投票弃权”
- 消息在第二阶段
- A： 如果任何参与者“VoteAbort”交易中止。 协调员向所有人发送“DoAbort”=>释放锁定
- B：否则，向所有人发送“DoCommit”=>完成交易
Example for 2PC
- 服务器A处银行的帐户“i”，服务器B处的“j”。
Server A would implement transaction
iServer B would implement transaction
服务器B可以假设“i”的账户有足够的钱，否则整个交易将中止
怎么锁定？ 个人参与者锁
- 在准备过程开始时获取锁定，在提交/中止释放
Deadlocks and Livelocks
- 分布式的死锁
- 跨服务器的事务对锁的循环依赖性
- 在2PC中，如果参与者不能响应投票请求（例如仍在等待其本地资源上的锁）
- 处理超时。 参与者超时，然后投票中止。 再次重试交易。
- 解决死锁问题
- 但是，LIVELOCK的危险 - 不断尝试！
总结
- 分布式一致性管理
- ACID属性可取
- 单个服务器的情况：使用锁，在使用两阶段锁定（严格的2PL，严格的2PL严格）的情况下，对锁的事务性支持
- 多服务器分布式情况：使用分阶段事务的两阶段提交。 需要协调员来管理来自参与者的消息。
Two-Phase Commit (1)
The finite state machine
(a) The finite state machine for the coordinator in 2PC.
(b) The finite state machine for a participant.
Coordinator/Participant can be blocked in 3 states:
- Participant: Waiting in INIT state for VOTE_REQUEST
- Coordinator: Blocked in WAIT state, listening for votes
- Participant: blocked in READY state, waiting for global vote
Two-Phase Commit (2)
- 如果“READY”参与者没有收到全局提交呢？ 不能中止=>找出协调员可能发送了什么消息。
- 方法：询问其他参与者
- 对任何参与者的回应采取行动
-
例如。 P处于READY状态，询问其他“Q”参与者
image.png
-
- 对任何参与者的回应采取行动
如果每个人都处于“ready”状态，则协议模块用于协调员（例如，如果协调员没有响应或已经崩溃！）。
Two-Phase Commit (3)
- 为了恢复，必须将状态保存到永久存储器（例如日志），以在故障之后重新启动/恢复。
- 参与者（INIT）：安全到当地中止，通知协调员
- 参与者（READY）：联系其他人
- 协调器（WAIT）：重新发送VOTE_REQ
- 协调员（等待/决定）：重新传送VOTE_COMMIT
协调员必须小心跟踪两个状态：
如果它记录了进入等待状态并且没有回来所有的响应，它可以重新发送VOTE_REQ
如果它已经恢复已经在第二阶段做出决定，那么这个决定必须被记录下来并且被重新发送。
2PC: Actions by Coordinator
iActions by Coordinator
Actions by Participant
Handling Decision Request
Handling Decision Request
请注意，参与者只有在达成全球决定并将其付诸日志时才能帮助他人。
如果每个人都收到VOTE_REQ，协调员崩溃怎么办？
