Paxos协议是用来解决分布式事务分歧的，以Mgr的多个节点为例，如果多个节点只有一个写节点(主)，是不存在分布式事务的；如果多个节点同时写入，就可能会有分歧，在同一时刻A节点要修改账户增加100块，B节点同时要修改账户增加200块，这个账户就会有疑惑，到底是听A的还是听B的，还是两个同时听还是干脆两个都不听，这里有矛盾了，因此Paxos分布式协议就可以完美的解决这个分歧。

先看看Paxos的原始定义：

1.Only a value that has been proposed may be chosen,只有被提出(Propose)的值才可能被最终选定(Chosen)

2.Only a single value is chosen, and 只有一个值会被选定

3.A process never learns that a value has been chosen unless it actually

has been. 进程只会获知到已经确认被选定(Chosen)的值

这一段晦涩难懂，在研读完Mysql Mgr源码之后，我来根据Mgr Xcom的协议把这段话翻译一下：Mgr多个节点初始状态是一致的，如果不一致可以通过clone插件重置为一致状态。

多写模式下，任何一个节点都可以提议修改状态机，既从一个一致状态转换到另一个一致状态。

如果要修改状态机，必须获得一个提议号，提议号单调递增，一致状态的推进严格遵循提议号，前一个提议的状态更改未完成，不能提前执行和应用下一个提议。

一个提议，根据多数派协议来获得批准，不同节点相同的提议号以票号大的提议为准，最终所有节点学习到的内容是票号最大的那份内容。

票数相同，票号大的取胜；票数和票号相同，节点号大的的取胜。

为了提高并发，可以同时发起多个提议，但是提议是有先后顺序，因此，状态机的更迭也是有先后顺序，不允许提前消费。

多个提议对于同一条数据修订需要进行certify校验，既全局冲突检查，防止多个节点提议号不同，但是修订同一条记录而破坏事务的一致性。

有了这些理论保障，我们看看之前提出的分布式事务是如何避免分歧的。

一句话概括MGR三个节点提议和执行顺序，提议号由(msgno,node)组成，提议执行顺序order by msgno,node，例如：(80,0) (79,1) (79,2)；0号节点提议号最大执行顺序最晚，1号节点提议号最小最先执行；如果同时提议，则按照提议顺序执行，期间会进行certify校验；如果只有一个节点提议，则小于这个提议号的提议都会忽略，并产生新的提议顺序。详细如下：

0号节点提议之后的表现：(81,0) (81,1) (81,2)

1号节点提议之后的表现：(80,0) (79,1) (79,2)

2号节点提议之后的表现：(80,0) (80,1) (79,2)

/*

Certify transaction.

*/

seq_number = //冲突检查，如果并为MGR产生GTID

cert_module->certify(tcle->get_snapshot_version(), tcle->get_write_set(),

!tcle->is_gtid_specified(), tcle->get_server_uuid(),

gle, local_transaction);

/**

Conflict detection is performed when:

1) group is on multi-master mode;

2) group is on single-primary mode and primary is applying relay logs with transactions from a previous primary.

*/

Certify()

…

if (conflict_detection_enable) {

for (std::list::iterator it = write_set->begin();

it != write_set->end(); ++it) {

Gtid_set *certified_write_set_snapshot_version =

get_certified_write_set_snapshot_version(*it); //找出写集在本节点的gtid，既从certification_info map中查找历史认证过的gtid

//it = certification_info.find(item_str); return it->second;

/*

If the previous certified transaction snapshot version is not

a subset of the incoming transaction snapshot version, the current

transaction was executed on top of outdated data, so it will be

negatively certified. Otherwise, this transaction is marked

certified and goes into applier.

Snapshot_version mysql_bin_log.get_gtid_executed(sid_map, snapshot_version)

*/

if (certified_write_set_snapshot_version != NULL &&

!certified_write_set_snapshot_version->is_subset(snapshot_version))// snapshot_version来源于TCLE，当组复制钩子函数group_replication_trans_before_commit被执行时，带入当时执行节点的gtid快照；如果写集GTID为空，表示全新的写集，则继续执行，如果写集GTID不为空，是snapshot_version的子集，表示历史认证过,则继续执行；如果不是snapshot_version子集，说明这个写集有冲突不能使用，本地对某条记录执行过存在gtid，远程快照中不包含这个gtid，却要求修改同一条数据，对于本地事务处理，此时回滚本地事务，保留远程事务；对于远程事务处理，直接抛弃掉，不写入apply log。

goto end;

}

result = get_group_next_available_gtid(member_uuid);//从group_gtid_executed获取gtid，group_gtid_executed是一个全局的统一的视图，所有member保持一致，所以mgr产生的gtid都是全局唯一的

/*

Add generated transaction GTID to transaction snapshot version.

*/

snapshot_version->_add_gtid(get_group_sidno(), result);//写入最新的GTID到snapshot_version

…

//typedef std::unordered_map<:string gtid_set_ref> Certification_info;

//将写集的gtid写入本地的认证的数据结构Certification_info中

for (std::list::iterator it = write_set->begin();

it != write_set->end(); ++it)

{

certification_info.insert(std::pair<:string gtid_set_ref>(key, snapshot_version))

}

…

实验环节：

实验1：节点0，节点1同时执行相同记录，写冲突

实验2：节点0，节点1同时执行不同记录，并发执行