作者｜漫话编程
本文经授权转载自漫话编程（ID：mhcoding）
周末晚上，正在家里边看综艺节目，忽然女朋友跑过来找我打《王者荣耀》。
打了几把游戏，总算能够休憩一会了，预备持续看我的综艺，可是女朋友过来找我给他讲讲究竟什么是二阶段提交。
分布式共同性
还好咱们之前专门给女朋友介绍过什么是分布式，要不然这个论题说来就话长了。
在之前介绍分布式的时分，咱们以饭馆的后厨为例，今日持续之前的比方来说说什么是分布式共同性。
跟着饭馆的开展，渐渐的从只要一个厨师演变成有多个厨师，从而演变成有洗菜工、配菜师、厨师等多个职位。
当有了多种分工之后，就势必需求和谐这些人之间的协作。
比方餐厅客人点了一份西红柿炒蛋，然后后厨开端预备起来，洗菜工开端洗西红柿，配菜师开端预备鸡蛋，厨师开端向锅内加油预备炒菜。这是一种很正常的状况。
可是，假如音讯传达的不到位，或许洗菜师傅暂时不在厨房等，就会导致有的人现已开端预备起来，可是有的人并没有预备。
这就像是一个分布式体系相同的，当咱们在电商网站下单的时分，需求有多个分布式服务一同服务，如付出体系进行付出、红包体系进行红包扣减、库存体系扣减库存、物流体系更新物流信息等。
可是，假如其间某一个体系在履行进程中失利了，或许由于网络原因没有收到恳求，那么，整个体系或许就有不共同的现象了，即：付了钱，扣了红包，可是库存没有扣减。
这便是所谓的分布式体系的数据共同性问题。
二阶段提交
之所以刚刚的比方中会呈现共同性问题，便是由于每一个职工都只重视自己所做的作业，无法重视到其他人，那么，要想确保全体的共同性，就需求在后厨中引进一个新的人物，担任统筹，这个人物来进行和谐和分配一切人。
那么，引进一个和谐者担任和谐一切参加者的作业，这个在分布式体系中其实便是X/Open安排界说的分布式业务处理模型，而二阶段提交便是依据这一模型衍生出来的。
举个比方，五个人相约打王者荣耀，想要一同玩需求以下几个进程：
有一个人想要五黑玩王者荣耀，所以他开端联络自己的小伙伴们。
安排者：小A，咱们预备玩王者荣耀，你要是能够来参加的话，现在你就登录游戏，然后在游戏老友上给我回复个音讯。
小A登录自己的游戏账号，然后奉告安排者：小A已就位。
安排者：小B、小C、小D，咱们预备玩王者荣耀，你要是能够来参加的话，现在你就登录游戏，然后在游戏老友上给我回复个音讯。
小B、小C、小D别离登录自己的游戏账号，然后奉告安排者：小B、小C、小D已就位。
安排者发现一切人都就位了，所以在游戏上逐个告知我们，
安排者：小A，我约请你了，你进来吧。
小A承受约请
安排者：小B、小C、小D，我约请你了，你进来吧。
小小B、小C、小D接纳约请
所以，5个人在王者峡谷愉快的游玩了起来。
关于五个人开黑这个业务操作，在开端预备前五个人都是闲暇状况，忙着自己的作业。在安排者和谐过之后，我们也要达到一个共同的状况，即以下两种状况之一：
1、五个人愉快的开端一同玩游戏
2、五个人都退出游戏，仍是去忙自己的作业。
假如终究有一部分人在游戏里一向等，其他一部分并没有进入游戏，那么便是数据不共同了。
以上进程，便是一个典型的二阶段提交（2PC）的进程，在分布式体系中，也有相同的问题，而且能够选用相同的处理办法。
在分布式体系中，每个节点尽管能够知晓自己的操作时成功或许失利，却无法知道其他节点的操作的成功或失利（只知道自己有时间能够玩王者荣耀，不知道其他人有没有）。
当一个业务跨过多个节点时，为了坚持业务的ACID特性，需求引进一个作为和谐者的组件来一致掌控一切参加者的操作成果并终究指示这些节点是否要把操作成果进行真实的提交（安排者告知各位参加者一同进入游戏房间）。
因而，二阶段提交的算法思路能够归纳为：参加者将操作胜败告知和谐者，再由和谐者依据一切参加者的反应情报决议各参加者是否要提交操作仍是间断操作。
所谓的两个阶段是指：榜首阶段：预备阶段(投票阶段)和第二阶段：提交阶段（履行阶段）
预备阶段
业务和谐者给每个参加者发送Prepare音讯，每个参加者要么直接回来失利（奉告安排者自己没时间，不能一同玩游戏），要么在本地履行业务（登录王者荣耀），但不提交（先不开端游戏）。
能够进一步将预备阶段分为以下三个进程：
1）和谐者节点向一切参加者节点问询是否能够履行提交操作，并开端等候各参加者节点的呼应。（问询是否能够一同玩游戏）
2）参加者节点履行问询建议停止的一切业务操作，并将Undo信息和Redo信息写入日志。（登录王者荣耀游戏）
3）各参加者节点呼应和谐者节点建议的问询。假如参加者节点的业务操作实践履行成功，则它回来一个”赞同”音讯；（奉告安排者自己现已登录成功）假如参加者节点的业务操作实践履行失利，则它回来一个”间断”音讯。（奉告安排者自己暂时无法一同玩游戏，如自己的账号被约束无法打排位）
提交阶段
假如和谐者收到了参加者的失利音讯或许超时（有人不能一同玩游戏，或许一向没有回复），直接给每个参加者发送回滚音讯（奉告其他人，暂时撤销游戏）；不然，发送提交音讯（约请我们进入游戏房间）；参加者依据和谐者的指令履行提交或许回滚操作（进入房间一同玩游戏或许退出游戏去做其他作业）。
接下来分两种状况别离评论提交阶段的进程。
当和谐者节点从一切参加者节点取得的相应音讯都为”赞同”时:
1）和谐者节点向一切参加者节点宣布”正式提交”的恳求（要求一切已登录的朋友参加游戏房间）。
2）参加者节点正式完结操作，并释放在整个业务期间内占用的资源（承受约请，进入房间）。
3）参加者节点向和谐者节点发送”完结”音讯（点击"预备"，进入预备状况）。
4）和谐者节点遭到一切参加者节点反应的”完结”音讯后，完结业务（进入王者峡谷）。
假如任一参加者节点在榜首阶段回来的呼应音讯为”间断”，或许 和谐者节点在榜首阶段的问询超时之前无法获取一切参加者节点的呼应音讯时：
1）和谐者节点向一切参加者节点宣布”回滚操作”的恳求（奉告一切人撤销游戏）。
2）参加者节点使用之前写入的Undo信息履行回滚，并释放在整个业务期间内占用的资源（退出游戏，去做自己的作业）。
3）参加者节点向和谐者节点发送”回滚完结”音讯（奉告安排者自己知道了，后边有时机再玩）。
4）和谐者节点遭到一切参加者节点反应的”回滚完结”音讯后，撤销业务（撤销本次游戏活动）。
2PC的缺陷
以上进程其实是有一些缺陷的，如
1、当参加者收到安排者的音讯之后，需求登录游戏，在游戏中等候安排者的再次约请，这个进程比较浪费时间。
2、假如在这个进程中，安排者忽然有什么作业被打断了，那么那些现已进入游戏的参加者就或许一向等下去。
3、在一切人都登录游戏之后，安排者经过约请要求一切人参加他的房间，这时分假如有一些网络反常、或许参加者没在手机前面等状况，或许会有一部分用户参加了房间，有一部分没参加。
4、假如安排者在游戏中开端约请一切参加者的时分，他约请了榜首个人之后，他和这个被他约请的人都掉线了。这时分其他三个人就不知道究竟应该怎样办了。
以上问题，分布式体系的2PC阶段相同存在，别离对应以下问题：
1、同步堵塞问题。履行进程中，一切参加节点都是业务堵塞型的。当参加者占有公共资源时，其他第三方节点拜访公共资源不得不处于堵塞状况。
2、单点毛病。由于和谐者的重要性，一旦和谐者发作毛病。参加者会一向堵塞下去。尤其在第二阶段，和谐者发作毛病，那么一切的参加者还都处于确定业务资源的状况中，而无法持续完结业务操作。（假如是和谐者挂掉，能够从头推举一个和谐者，可是无法处理由于和谐者宕机导致的参加者处于堵塞状况的问题）
3、数据不共同。在二阶段提交的阶段二中，当和谐者向参加者发送commit恳求之后，发作了部分网络反常或许在发送commit恳求进程中和谐者发作了毛病，这回导致只要一部分参加者承遭到了commit恳求。而在这部分参加者接到commit恳求之后就会履行commit操作。可是其他部分未接到commit恳求的机器则无法履行业务提交。所以整个分布式体系便呈现了数据部共同性的现象。
4、二阶段无法处理的问题：和谐者再宣布commit音讯之后宕机，而仅有接纳到这条音讯的参加者一同也宕机了。那么即便和谐者经过推举协议产生了新的和谐者，这条业务的状况也是不确定的，没人知道业务是否被现已提交。
总结一下，便是说2PC并不是完美的，他存在着同步堵塞问题、单点毛病问题、无法100%确保数据共同性等问题。
【END】
热 文推 荐
