在论文中作者提出了一种全新的解决分布式事务的方案Galvin。

它是一个分布式事务解决框架，不依赖存储层，只要满足CRUD的存储层均可。

作者的核心思路是对即将处理的事务进行预处理，事务执行之前在执行层面达成事务执行的共识，作者通过将事务记录写入日志，这样事务在日志中的顺序就是事务的执行顺序，这是一个全局的事务日志，从而保证事务执行在全局层面达成共识。

Calvin分成三层

sequencing layer：

这一层负责劫持和收集所有的事务请求，并将它们按照10ms的时间窗口batch提交到全局事务日志（排序），论文中说这一层不是单点，是分布式的，但是毕竟写日志一般很难多点写入，因此仍然存在单点瓶颈。

scheduling layer：

调度层负责按照顺序执行全局事务日志，如果严格的串行执行，性能肯定不足，因此这一层会尽力将那些并发执行无环的事务并发执行以提升性能。

storage layer：

存储层，只要满足CRUD接口即可。

由于事务共识在预处理的时候就已经达成了，后续执行事务的时候无需再次共识，只需要执行即可，因为故障恢复也比较简单，新的节点从事务日志的指定位置继续消费即可。

作者这论文中分析了传统的2PC提交的成本，作者分析认为在多个节点之间达成共识需要包含其中的网络通信开销，必要的日志存储开销，还有锁的开销，因为这些开销进而导致事务持有锁的时间变长了，出现事务冲突的概率就会增加。

总结

在论文中作者提供了一种比较新颖的事务处理方案，通过事务预处理提前达成共识，减少事务执行过程中临时达成共识带来的开销。不过作者的分布式事务解决框架存在一些弊端

• 全局事务排序存在单点写入瓶颈
• 这个框架不能解决交互式事务，只适用于确定的事务，即事务执行时提交的数据是一次性确定的。

cockroachDB在local range执行事务时参考了这种解决事务冲突的思路，即利用时间戳确定事务执行的先后顺序，这种共识是确定的，无需二次确认。

作者：贺大伟
链接：https://www.jianshu.com/p/67800b98a4b1
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

标签：事务,Partitioned,Transactions,Database,开销,作者,共识,日志,执行
来源： https://blog.csdn.net/u013288190/article/details/115696878