今天天气不错，挺风和日丽的，趁着下午没有课，让我们研究一下怎么结婚吧，万一以后用得着呢？
作为一个架构师，你也许听说过两阶段提交（2PC），但你可能没听说过两阶段结婚，因为这词是我刚刚才造的。
1 抓狂的司仪
司仪：『尊敬的各位读者，今天是正月初十，让我们一起来见证眼前这对新人是如何从结婚到崩溃的。』
司仪：『Prepare：请问新狼和新娘是否愿意结为夫妻？』
『桥豆麻袋，我需要先准备一下』，只见新狼拿出一个小本本迅速写下『等会要说我愿意』，然后握紧拳头，鼓足勇气对司仪说：『我愿意』
『不好意思，我也准备一下』，说完新娘也拿出一个小本本，迅速写下『我会说我愿意』，然后抬起头直视司仪：『我愿意』
司仪：『好， 我已经收到两位新人答复了，现在。。。』，只见司仪拿出一个小本本，迅速写下『这俩二傻子都愿意了，这次提成稳了』，很开心的说『Commit：我宣布，你俩正式成为合法夫妻』
新狼茫然地看着司仪，台下没有掌声。。。
过了好一会儿，司仪发现已经timeout一分钟了，新狼还没反应，于是再次微笑地对着两人说『我宣布，你俩正式成为合法夫妻』
新狼依然很茫然地看着司仪
司仪抬手看表，发现又timeout一分钟了，大吼『我宣布，你俩正式成为合法夫妻』
。。。。。。。
司仪休克了
幸亏现场有医生，并且带了速效救心丸，经过抢救，司仪苏醒过来
战战兢兢的打开自己的小本本，司仪心想『幸亏刚刚我把想说的话记到了小本本上，否则现在都不记得该说啥了』，接着开始读『我宣布，你俩正式成功合法夫妻』
『啊，终于收到了这个好消息~』，新狼开心的说：『感谢司仪，是你的不懈努力让我们终于结婚成功。感谢读者大大，是你们的支持让我们有了结婚的动力』
司仪抽搐不止，口吐白沫：『回去后一定要记得点赞，然后关注公众号吹牛拍码啊』
司仪由于长期996，抢救无效，永远的活在了我们的心中。新狼新娘铭记司仪的嘱托，在新婚之夜关注了公众号吹牛拍码
2 茫然的新狼
当新狼新娘表示『愿意』之后，他们需要等待司仪的『确认』。新狼由于迟迟没有收到『确认』，非常茫然，不知道做什么，或都说根本做不了事情，这称为『未决状态』。
刚刚的结婚仪式过程中，幸亏司仪从休克中苏醒了过来。这样虽然中间耽搁了一段时间，好歹婚礼还可以继续下去。但如果司仪在仪式中间去世了，将会非常影响婚礼的进行，因为没人知道司仪的小本本上写了啥。
所以说，在不确定司仪身体是否健康的情况下，找一个备份司仪也是很重要的。
在2PC中，各参与者在回复yes之后，它们各自DB中对应的数据处于locked状态，这会阻止其它事务修改甚至读取数据，即使DB重启也不解决问题。
如果协调者有bug，或者协调者直接crash掉再也起不了，这会非常影响2PC事务的执行。
手动恢复非常消耗精力，管理员需要仔细检查所有参与者的执行情况，然后决定是提交还是回滚整个事务。特别是在大促期间，时间短，任务重，需要背负巨大的心理压力。
因为协调者本质也是一个DB，因此做备库等高可用方案有助于缓解该问题。
3 两条不归路
结过婚的人先自行感悟
两条不归路：人在江湖，讲究的是一个『信』字，承诺一旦做出了，就不能失信于人，要勇于执行，要披荆斩棘，要至死不渝：
新狼新娘需要写小本本，是因为他们一旦承诺愿意（或拒绝）结婚，那就再也没有机会反悔了。哪怕是一激动休克过去再醒来，小本本也会提醒他/她要做什么。
司仪需要写小本本，是因为他一旦决定了要宣布的消息，就再也没有退路。接下来司仪需要做的，是努力把决定传达给新狼和新娘。只要还没有收到新狼或新娘的响应，就要一直不断的『宣布。。。宣布。。。』。如果司仪牺牲在岗位上，即使换一个备份司仪，也要秉承精神，一贯到底。
4 补充阅读
协调者故障可能导致无限阻塞，因此2PC也被称为阻塞式原子提交协议。为了缓解该问题人们提出了3PC，更多讨论可以参考《分布式事务之3PC：一场程序员与产品经理斗智斗勇的旷世大战》
由于无限网络延迟和进程暂停等NPC问题，3PC无法保证原子性。NPC相关问题可移步《13.看似忠良的分布式锁》
5 结婚有风险
但点赞和扫码关注没有风险啊，要不要试一下？
