1. 背景:
初时提出,是为解决分布式数据库的事务问题。单机数据库事务可靠日志技术,MVCC技术实现。分布式情况下,就需要额外的手段来保证,这才出现了二阶段提交。
2. 流程:
从角色上,二阶段提交分为两种角色:协调者(coordinate),参与者(participant)。流程思路上很简单:
1. 协调者询问询问所有参与者,能否提交;参与者返回是否能提交的结果;
2. 协调者根据参与者的返回结果决定是否提交事务,并通知参与者执行。
但实际上,二阶段提交需要考虑不少异常场景:
对照上图:
1 宕机类:
协调者宕机:起来后,看本地日志。
如果在begin_commit,则发送prepare。即使参与者已经发送过了响应,也不影响。流程正常。
如果在global_commit或global_abort,则重新发送global-commit或global-abort。(如果参与者已经提交过,怎么办)。
如果协调者起不来,起新的协调者,向参与者取状态。如有commit的,则继续commit,否则abort。
参与者宕机:起来后,看本地日志。
如果在init,则等prepare。如果协调者已经发过,会超时,见下。
如果在ready日志,则按流程发送vote-commit继续往下走。
如果在abort或commit日志处,则什么都不干,等协调者重发。
2 等待响应超时类
大体来说,一阶段超时直接退出流程,二阶段超时持续重试。
协调者超时:
等待参与者对prepare响应超时(已收到全为vote-commit,但仍有未响应的参与者)。这时,直接放弃,发送global_abort。
等待global-commit或global-abort的响应超时。这时,无他法,只有不断重试。这可能会引起参与者重复提交。
参与者超时:
init后,在prepare等待处超时。直接进入abort。后面即使收到prepare,流程仍然正确。
确认可以提交后,在等待协调者二阶段命令时超时。说明已经发过vote_commit,由于不知道流程状态,只能不断重发vote_commit。
二阶段协议应用较少,理论价值大于实践价值。