Distributed Transaction --- 2PC and 3PC

Some pictures from the reference article, invasion deleted

Outline

       We talked about the CAP on a theory, partitions fault tolerance, consistency, availability of three can not exist, and partitions fault tolerance is an objective reality, then in order to ensure availability, we sacrificed consistency, although we can not guarantee strong consistency, but (Base theory) we can guarantee eventual consistency. And 2pc (two-phase commit) and 3pc (three-phase commit) are for coherency protocol, through these agreements to ensure consistency.

2pc

           2PC protocol has two stages: Propose and style Commit 2PC protocol process in the absence of error is this:

• Propose stages:
  • coordinator: "What are you going to perform."
  • voter1 / voter2 / voter3: "receive (written each node action to be performed)!"
• Commit stage
• coordinator: "OK execute"
• voter1 / voter2 / voter3: "Well da (actions performed landing)

        If one node Propose not ready, then coordinator of this execution to abort

       But 2pc there is a problem, for example in the preparation phase commit phase, coordinator and voter3 just have crash, then vote1 and vote2 embarrassing, and why? Because the situation is now following:

(1) upper and voter3 unanimously the first commit message received after the commit operation and a crash

(2) the last round against voter3 why it did not pass.

        So vote1 and vote2 do not know whether it will be in a dilemma commit or abort of. Meanwhile 2pc further provides the following advantages and disadvantages:

        Disadvantages:

• After synchronization blocked, the second phase of the implementation phase of the task, each node needs to block execution is complete, the coordinator was let go locked resources
• Single-point problem, coordinator if the second phase of the crash, part of the received word commit section is not received, it will cause data inconsistencies.

       advantage:

• Simple and easy to implement

        2pc belong in the CAP CA, so no way to solve the problem of fault tolerance partitions, but it found a balance in terms of performance and fault-tolerant partitions such that a relational database like to use 2pc to implement a distributed transaction.

3pc

       Simple to say, 3PC Commit phase of 2PC is to split into two phases PreCommit and Commit increase this by entering a PreCommit stage, voter voting results can be obtained Propose stage, but will not commit;. Commit to enter through the stage , voter can dish out every other voter also intend to commit, and thus can be assured commit.

        In other words, 3PC increase in the Commit phase of a 2PC's Barrier (which is equivalent to telling all the other voter, I received the results Propose friends). Before this barrier coordinator dropped, then the other voter can conclude that not every voter Propose Phase results are received, so give up or to elect a new coordinator; after this barrier coordinator dropped the case, each voter will be assured of commit, because they know that others are also doing the same voter program.

       The following is 3pc process.

      The following is a view on wiki:

   

     But there are some problems 3pc.

• When the network partition can not be restored

Network division (network partition)

        Refers to a division of the network can not communicate with each other node.

      Assuming all nodes PreCommit stage is divided into two, received preCommit message voter on one side, but did not receive the news on the other side. In this case, both sides may be made to elect a new coordinator different decision.

      As shown in the following scenario

fail-recover    

        fail-recover that after a while and then failed to recover.

      当coordinator收到preCommit的确认前crash, 于是其他某一个voter接替了原coordinator的任务而开始组织所有voter commit. 而与此同时原coordinator重启后又回到了网络中, 开始继续之前的回合---发送abort给各位voter因为它并没有收到preCommit. 此时有可能会出现原coordinator和继任的coordinator给不同节点发送相矛盾的commit和abort指令, 从而出现个节点的状态分歧.

总结     

        可以看到无论是 2pc 还是 3pc

补充

replication 和  partition

         我们运用分布式的时候时常会使用两种手段对数据进行处理。一种是 切分，一种是复制，这两种分别对应于 partition 和 replication . 两者的操作如下 ：

       先说复制吧，最常见的就是主从复制，优势很明显，可以很好地处理分区容错性，要是主挂了，从的马上就可以顶上。缺点数据的一致性，上面的二阶段提交和三阶段提交都是为了解决一致性的问题。而 partition 可以将多个任务分成一小块一小块，充分发挥并发计算，同时解决数据增长带来的冲击，因为每一块都分出去了，所以计算压力得到了平摊。但是也会存在例如分区之间跨区访问受限，数据增长速度不同等问题，还可能存在著名的 Byzantine_fault_tolerance （拜占庭问题）。

拜占庭问题

        拜占庭将军问题是一个协议问题，拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开来的，并且将军中存在叛徒。叛徒可以任意行动以达到以下目标：欺骗某些将军采取进攻行动；促成一个不是所有将军都同意的决定，如当将军们不希望进攻时促成进攻行动；或者迷惑某些将军，使他们无法做出决定。如果叛徒达到了这些目的之一，则任何攻击行动的结果都是注定要失败的，只有完全达成一致的努力才能获得胜利。来源 ；百度百科

         简单地来说就是协调者发出某个请求，要求各个节点达成共识，共同对外 ，但是内部出现奸细，出现返回来的信息使得大家达不到一致性。

Partition tolerant consensus algorithms

       最著名的 partition tolerant consensus 算法就是 Paxos 了，还有 Raft .

network partition

       以下的描述很好地解释了 network partition

A network partition is the failure of a network link to one or several nodes. The nodes themselves continue to stay active, and they may even be able to receive requests from clients on their side of the network partition. As we learned earlier

consistency（一致性分类）

Consistency models can be categorized into two types: strong and weak consistency models:

• Strong consistency models (capable of maintaining a single copy)
  • Linearizable consistency
  • Sequential consistency
• Weak consistency models (not strong)
  • Client-centric consistency models
  • Causal consistency: strongest model available
  • Eventual consistency models （最终一致性）

        其中强一致性包括 Linearizable consistency  和 Sequential consistency ，它们两者的差别在于 ：

• Linearizable consistency: Under linearizable consistency, all operations appear to have executed atomically in an order that is consistent with the global real-time ordering of operations. (Herlihy & Wing, 1991)
• Sequential consistency: Under sequential consistency, all operations appear to have executed atomically in some order that is consistent with the order seen at individual nodes and that is equal at all nodes. (Lamport, 1979)

Reference material

• Recommend a look
• https://www.the-paper-trail.org/post/2008-11-29-consensus-protocols-three-phase-commit/
• https://www.zhihu.com/question/23645117 (Distributed know almost on important information)
• https://courses.cs.washington.edu/courses/csep552/16wi/ （552）
• https://courses.cs.washington.edu/courses/cse552/13au/calendar/lecturelist.html （552）
• Rambling Distributed Systems consensus agreement: 2PC / 3PC articles
• http://book.mixu.net/distsys/intro.html (recommend a look)