传统性事务为刚需事务,需要确保数据的绝对安全一致。
随着跨系统,跨网络时,刚需的事务变的力不从心。于是就有了妥协性的柔性事务,在确保数据最终一致性的前提下,牺牲部分时间的一致性。
柔性事务 主要有三种实现:
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 。