分布式事务 个人学习

传统性事务为刚需事务，需要确保数据的绝对安全一致。

随着跨系统，跨网络时，刚需的事务变的力不从心。于是就有了妥协性的柔性事务，在确保数据最终一致性的前提下，牺牲部分时间的一致性。

柔性事务 主要有三种实现：


1.可靠消息最终一致(异步确保型)
   业务处理服务在业务事务提交前，发送消息；消息服务只记录消息数据，不发送；业务服务在业务事务提交后，发送消息给消息服务确认发送之前的消息。
   消息服务在收到确认消息服务时，才会真的发送消息。（说白了，就是先发送个特定状态的消息，消息服务接收到后暂存不发生，等业务事务提交后发送确认消息后，消息服务在发送之前的消息）
   业务事务回滚，发送“取消发送”消息给消息服务。消息状态确认系统定期找到未确认或回滚消息，向业务询问消息状态，业务处理根据消息ID或消息内容确认消息是否有效(说白了，消息主服务只管存这些非立即发送的消息，没收到确认消息时前，不鸟这些消息，即使收到取消消息后，也不会鸟它们)

约束：
   所有被动方操作必须是幂等操作

成本：
   需要一个可靠的消息系统
   一次消息发送需要两次请求，业务需要实现状态回查接口(消息状态确认系统，要回查消息状态)

适用范围：
   可降低业务系统和消息系统耦合度
   对最终一致性时间铭感度较高，降低业务被动方实现成本

方案特定：
    兼容所有实现的JMS标准的MQ中间件
    确保业务数据可靠的前提下，实现业务员数据的最终一致(消息不堆积的情况下，准实时一致)


支付宝 eBay(BASE) 去哪儿






2. TCC (两阶段 补偿型)
适用范围：
   强隔离性，严格一致性的要求的业务活动
   适用于执行时间比较短的业务(比如处理账户，收费业务)


支付宝 XTS （蚂蚁金服 云的分布式事务服务DTS） 







3. 最大努力通知(定期校对)


对时间铭感度不高的场景

例如 银行通知，商户通知等(各大交易业务平台间的商户通知：多次通知，查询校对，对账文件)

总结： 在确保数据最终的一致性的前提下，通过部分牺牲时间的一致性来达到系统的可拓展性。当然随着系统的可扩展，实际上反过来降低了时间的一致性，最终达到满足业务的实际需要。

部分数据参考 http://www.roncoo.com 。

传统性事务为刚需事务，需要确保数据的绝对安全一致。

随着跨系统，跨网络时，刚需的事务变的力不从心。于是就有了妥协性的柔性事务，在确保数据最终一致性的前提下，牺牲部分时间的一致性。

柔性事务 主要有三种实现：


1.可靠消息最终一致(异步确保型)
   业务处理服务在业务事务提交前，发送消息；消息服务只记录消息数据，不发送；业务服务在业务事务提交后，发送消息给消息服务确认发送之前的消息。
   消息服务在收到确认消息服务时，才会真的发送消息。（说白了，就是先发送个特定状态的消息，消息服务接收到后暂存不发生，等业务事务提交后发送确认消息后，消息服务在发送之前的消息）
   业务事务回滚，发送“取消发送”消息给消息服务。消息状态确认系统定期找到未确认或回滚消息，向业务询问消息状态，业务处理根据消息ID或消息内容确认消息是否有效(说白了，消息主服务只管存这些非立即发送的消息，没收到确认消息时前，不鸟这些消息，即使收到取消消息后，也不会鸟它们)

约束：
   所有被动方操作必须是幂等操作

成本：
   需要一个可靠的消息系统
   一次消息发送需要两次请求，业务需要实现状态回查接口(消息状态确认系统，要回查消息状态)

适用范围：
   可降低业务系统和消息系统耦合度
   对最终一致性时间铭感度较高，降低业务被动方实现成本

方案特定：
    兼容所有实现的JMS标准的MQ中间件
    确保业务数据可靠的前提下，实现业务员数据的最终一致(消息不堆积的情况下，准实时一致)


支付宝 eBay(BASE) 去哪儿






2. TCC (两阶段 补偿型)
适用范围：
   强隔离性，严格一致性的要求的业务活动
   适用于执行时间比较短的业务(比如处理账户，收费业务)


支付宝 XTS （蚂蚁金服 云的分布式事务服务DTS） 







3. 最大努力通知(定期校对)


对时间铭感度不高的场景

例如 银行通知，商户通知等(各大交易业务平台间的商户通知：多次通知，查询校对，对账文件)

总结： 在确保数据最终的一致性的前提下，通过部分牺牲时间的一致性来达到系统的可拓展性。当然随着系统的可扩展，实际上反过来降低了时间的一致性，最终达到满足业务的实际需要。

部分数据参考 http://www.roncoo.com 。