柔性事务

来源：互联网发布：中国税务网络大学ipad 编辑：程序博客网时间：2024/04/29 19:35

在支付宝架构与技术中对柔性事务有大致的描述：

可以看出，柔性事务（遵循BASE理论）是指相对于ACID刚性事务而言的。
支付宝所说的柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型几种。
由于支付宝整个架构是SOA架构，因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要，以上几种事务类似就是针对分布式环境下业务需要设定的。
其中：
1、两阶段型：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。
这是分布式环境下事务处理的典型模式。

2、补偿型：
TCC型事务（Try/Confirm/Cancel）可以归为补偿型。
补偿型的例子，在一个长事务（ long-running ）中，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。
WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。还是上面的例子，服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。这样的SAGA事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性。
例子来源：OASIS的WS-BusinessActivity文档

3、异步确保型
将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用，典型例子是热点账户异步记账、批量记账的处理。

4、最大努力型
PPT中提到的例子交易的消息通知（例如商户交易结果通知重试、补单重试）

如果有技术背景，可以参考另外一个文档大规模SOA系统中的分布事务处事，对支付宝分布式事务处理机制有较为详细描述。

更详细的也可以参考OASIS的相关资料。

============================

　　支付宝系统架构概况

　　典型处理默认

　　资金处理平台

　　财务会计

　　支付清算

　　核算中心

　　交易

　　柔性事务

　　支付宝的开源分布式消息中间件--Metamorphosis(MetaQ)

　　Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件，类似于LinkedIn的Kafka，具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，在淘宝和支付宝有着广泛的应用，现已开源。

　　Metamorphosis是淘宝开源的一个Java消息中间件。关于消息中间件，你应该听说过JMS规范，以及一些开源实现，如ActiveMQ和HornetQ等。Metamorphosis也是其中之一。

　　Metamorphosis的起源是我从对linkedin的开源MQ--现在转移到apache的kafka的学习开始的，这是一个设计很独特的MQ系统，它采用pull机制，而不是一般MQ的push模型，它大量利用了zookeeper做服务发现和offset存储，它的设计理念我非常欣赏并赞同，强烈建议你阅读一下它的设计文档，总体上说metamorphosis的设计跟它是完全一致的。但是为什么还需要meta呢？

　　简单概括下我重新写出meta的原因：

　　Kafka是scala写，我对scala不熟悉，并且kafka整个社区的发展太缓慢了。

　　有一些功能是kakfa没有实现，但是我们却需要：事务、多种offset存储、高可用方案(HA)等

　　Meta相对于kafka特有的一些功能：

　　文本协议设计，非常透明，支持类似memcached stats的协议来监控broker

　　纯Java实现，从通讯到存储，从client到server都是重新实现。

　　提供事务支持，包括本地事务和XA分布式事务

　　支持HA复制，包括异步复制和同步复制，保证消息的可靠性

　　支持异步发送消息

　　消费消息失败，支持本地恢复

　　多种offset存储支持，数据库、磁盘、zookeeper，可自定义实现

　　支持group commit，提升数据可靠性和吞吐量。