Mysql 2PC提交

1.什么是2PC

2PC,二阶段提交协议，事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段

阶段1：准备阶段　
1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。　　
2、各参与者执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。　　
3、如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。

阶段2：提交阶段 　　
此阶段分两种情况：所有参与者均反馈YES、或任何一个参与者反馈NO。　　
所有参与者均反馈YES时，即提交事务。　　
任何一个参与者反馈NO时，即中断事务。

这也是一种思想，自己去实现分布式事务等或者在一些特殊情况下的程序涉及都可能涉及到。

2.MySQL 2PC

如何保证binlog和redo log的一致性。因为binlog是Master-Slave的桥梁，如果顺序不一致，意味着Master-Slave可能不一致.

第一种情况，如果先写了redo log 后写binlog :如果redo 写完了，但是再写binlog的时候cash了。这时候如果需要重备份中恢复，这样使用binlog恢复会少了会后一次事务的值
第二种情况，如果先写binlog ，后写redo：如果binlog写完了，写redo cash 了。这样原库里面会多了一个事务。其实应用这笔是认为没有成功。

MYSQL通过两阶段提交很好地解决了这一问题。Prepare阶段，innodb写redo log，并将回滚段设置为Prepared状态，返回ok commit阶段 写binlog,这边的理解是写到binlog buffer,再执行刷盘 ，然后江redo设置提交状态 刷盘。

如果在Prepare阶段 cash ，则去对比binlog中如果存在提交，如果binlog不存在则回滚，这样保证了主从的一致性。

影响刷盘的参数

sync_log：

sync_binlog=0 的时候，表示每次提交事务都只 write，不 fsync；

sync_binlog=1 的时候，表示每次提交事务都会执行 fsync；

sync_binlog=N(N>1) 的时候，表示每次提交事务都 write，但累积 N 个事务后才 fsync。

innodb_flush_log_at_trx_commit说明

1是最安全的，每次事物提交的时候都会把redo log 直接持久化到磁盘

2每次事物commit的时候只是吧redo log wirte即写入到page cache ，但是持久化到磁盘是每一秒一次。

0日志是每秒执行一次，commit时没有及时写入磁盘。