笔记 事物（二）

前面有一篇关于事物对文章，里面提到了分布式系统的事物的处理的两种思想：一种是基于CPA的；一种是基于base。前面只是简单的说了这两种思想的概念。这里来往深入看看这两种思想，我们有那些可以实施方案。
CPA因为在系统中我们没法同事满足这三个条件，所以我们一般利用其中的PC两个，从一致性和容错率来入手，牺牲一定的可靠性，从而来达到系统的强一致性。在这个方式下，现在一般有三种烦死。第一种：2pc 两次提交方案。在这里我们首先要知道，为了保证（其实也不一定保证的了）分布式系统中每一个子系统的能够实现数据的一致性;第二种方案就是，3pc就是三次提交。还有就是tcc方案。

2pc(二次提交)的方案：从字面字面意思理解，就是说要提交两次，那么。我们就要想想，如何提交两次了。而且这两次是有什么区别。
首先，我们想想，有这么一个分布式的系统，里面有订单，积分，仓库等子系统。那么，一个订单到了订单系统之后，是不是我们还要到仓库系统去对库存进行操作，到积分系统里面去对客户的积分进行操作。而且在理想状态下，我们的每一笔的操作，在订单，积分，仓库这三个系统中，是不是都应该要么都成功，要么都失败。

而基础pc思想，我们要保证系统为了保证数据的强一致性（其实也不能够百分百保证数据的强一直性）。本来各个系统的事务是单独不影响彼此的。但是如果我们创建一个事务管理器来管理每一个子系统的事务，只有当每一个子系统的事务都能过成功的时候，我们就统一提交。如果有一个没有成功，那么我们回滚。这样是不是能够保证数据库的数据的一致性。

那么，第一次预提交；与第二次提交有什么区别，其实第一次预提交，就是相当于模拟一次事务的提交操作，从而来判断是否能够成功。而第二次提交，才是真正的把数据写入数据库。那么，在这其中，我们能够想想有什么不足了。
1.如果事务管理器出现故障，就会导致整个流程出错。
2.操作流程占用资源的时间长。
3.如果问题出现在第二次提交的时候出现故障，也会导致数据的一致性不成立。

针对第一个问题，人们提出了3pc的概念，其实就是引入时间机制，就是让每个子系统的事务也有相当于最大连接时间。这样，就可以避免因为事务管理器的故障，导致各个系统的连接没有断开的问题。而3pc就是把2pc的第一次提交的阶段给分为了can commit阶段：就是去判断是否能够进行提交操作；pre commit阶段，就是进行预提交阶段。但是他还是避免不了资源占用时间久，最后提交的失败导致的数据不一致的问题。

而tcc 这中方案，在我看来，就在一定程度是，解决了在占用资源时间久，最后一次提交有失败的风险的问题，但是他也有自己的问题。这个方案就在下个博客中，与大家说说