分布式事务-(1)理论篇

一，分布式系统存在的问题

分布式系统经常出现的异常：机器宕机，网络异常，消息丢失，消息乱序，
数据错误，不可靠的TCP，存储数据丢失等问题。

二，CAP定理与BASE理论

1：CAP定理：

	CAP原则又称CAP定理，是分布式系统中：
		1）一致性（Consistency）:
			在分布式系统中的所有数据备份，在同一时刻是否同样的值（等同于所有节点访问同一份数据副本，强一致性）
		2）可用性（Availability）:
			在集群中一部分节点故障后，集群整体是否还能相应客户端的读写请求（对数据更新具有高可用性）
		3）分区容错性（Partition tolerance）
			大多数分布式系统都分布在多个子网络，每个子网络都叫做一个区，
			分区容错就是区间通信可能失败。
	CAP原则是指这三个要素最多只能满足其中两点，不可能三者兼顾。一般来说分区容错无法避免，因此可以认为CAP中的P总是成立的，也就是说剩下的C和A 无法同时做到。
分布式系统中实现一致性的算法：http://thesecretlivesofdata.com/raft/

2，面临的问题

对于多数大型互联网应用的场景，主机众多，部署分散，而且现在集群规模越来越大，
所以节点故障，网络故障是常态，所以要保证P和A 舍弃C。

3，BASE理论

是对CAP理论的延伸，思想是即使无法做到强一致性，但可以适当的采取弱一致性，
即：最终一致性
BASE是指：
	1）基本可用（Basically Available）
		是指分布式系统出现故障的时候，允许损失部分可用性（例如：响应时间，
		功能上的可用性），基本可用不等于系统不可用。
		响应时间损失：正常0.5秒，出现故障相应时间增加到了1.5秒。
		功能上的可用性：购物网站在购物高峰（如双十一），为了保证系统的可用性，
			部分消费者可能会被引到一个降级页面。
	2）软状态（Soft State）
		是指允许系统存在中间状态，该中间状态不会影响系统整体可用性，
		分布式存储一般一份数据会有多个备份，允许不同副本同步的延迟是软状态的体现
		（mysql replication的异步复制也是一种体现）。
	3）最终一致性（Eventual Consistency）	
		是指系统中的副本数据经过一段时间后，最终能达到一致的状态。
		弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

4，强一致性，弱一致性，最终一致性

	从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略。
	决定了不同的一致性，对于关系型数据库，要求更新过的数据能被后续的访问都能看到。这是强一致性。
	如果允许后续的部分后者全部访问不到，则是弱一致性。
	如果经过一段时间后能访问到更新后的数据，则是最终一致性。

三，分布式事务的几种解决方案

	1）2PC模式
		数据库支持的2pc(2 phase commit),又叫 XA Transactions.
		mysql从5.5版本开始，sql server2005开始支持，oracle7开始支持。
		其中XA是两阶提交协议，该协议分为以下两个阶段：
		第一节段：事务协调器要求每个涉及到事务的数据库预提交（precommit）此操作。并反映是否可以提交。
		第二阶段：事务协调器要求每个数据库提交数据。
	其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚他们此事务中的那部分信息。

	XA协议比较简单，而且一旦商业数据库实现的XA协议，使用分布式事务的成本也比较低。
	XA性能不理想。XA无法满足高并发场景。
	XA目前在商业数据库的支持比较理想，在mysql中支持的不太理想，mysql的XA实现
	没有记录prepare阶段的日志，主备切换会导致数据不一致。
	许多nosql也没有支持XA。
	也有3PC，引入了超时机制(无论协调者还是参与者，在向对方发送请求后，若长时间未收到回应则做出相应处理)

	2）柔性事务--TCC事务补偿性方案
		刚性事务：遵循ACID原则，强一致性。
		柔性事务：遵循BASE理论，最终一致性。
		与刚性事务不同，柔性事务允许一定时间内不同节点的数据不一致，但要求最终一致。
		
	3）柔性事务--最大努力通知型方案
		按规律进行通知，不保证数据一定能通知成功，但会提供可操作查询接口进行核对。
		这种方案主要用在与第三方系统通讯时，比如：调用微信，支付宝的支付结果通知，这种方案也是结合MQ进行实现。
	4）柔性事务--可靠消息+最终一致性方案(异步确保型)
		实现：业务处理服务在业务事务提交前，向实时消息服务请求发送消息，
		实时消息服务只记录消息数据，而不是真正的发送，业务处理服务在业务事务提交之后，向实时消息服务确认发送，只有在得到确认指令后，实时消息服务才会真正的发送。
		注意：一定要保证消息的可靠性，要考虑以下问题：
			1：消息丢失
				1）消息发送出去，由于网络原因没有到达服务器。
					①：做好容错(try-catch)发送消息可能网络失败，失败要有重试机制，
						可记录到数据库，采用定期扫描重发的方式。
					②：做好日志记录，每个消息的状态是否被服务器收到都要记录。
					③：做好定期重发，如果消息没有发送成功，定期扫描数据库未成功的消息进行重发。
				2）：消息到达队列，未持久化，宕机
					①：开启消息队列的确认回调机制。
				3）：自动确认状态下，消费者收到消息，但未消费，宕机
					①：开启手动ACK
			2：消息重复
				1）：消息被成功消费，但还未确认，宕机
					①：消费者的消费接口要设计为幂等性的。
			3）：消息积压
				1）：消费者宕机-积压
				2）：消费者消费能力不足-积压
				3）：发送者发送流量太大-积压
					①：上线更多的消费者，进行正常消费。
					②：上线专门的队列消费服务，将消息先批量取出来，
					   记录数据库，离线慢慢处理。