支付宝DTS架构

最近，在忙着做一个任务，很奇怪发现后台的业务，付款和销账并不是在一个同一个事务里。

按照我的理论，付款和销账这些属于数据库的业务，显然应该是在一个事务里，才能保证数据的一致性。

与后台的负责人交流以后，告诉我付款和销账确实是两个过程。作为软件厂商，自己只能负责自己的事务一致性，但不能保证别的厂商提供的软件服务的一致性。

这番陈述，似乎说服了我，但貌似并不是最好的解决方案。

理论上，以上事务属于分布式事务。分布式事务，一般采用两阶段（2PC）；即第一段提交完成，再进行第二段提交。但这种方式，会造成所有阶段的都处在阻塞阶段，造成整个计算机出问题。

后来发现支付宝有分布式事务机制，值得学习。

分布式事务服务（Distributed Transaction Service，简称 DTS）是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 Jar 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。

也就是说，DTS的特征为：

1）最终一致：在事务处理过程中，会有短暂不一致，但通过恢复系统，达到最终一致。

2）协议简单：定义了类似2PC的标准两阶段接口，可使用DTS事务功能。

3）与RPC服务协议无关：把DB操作定义为service，与底层协议无关。

4）与底层事务实现无关： DTS 是一个抽象的基于 Service 层的概念，与底层事务实现无关，也就是说在 DTS 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列存数据库 HBase，只要将对其的操作包装成 DTS 的参与者，就可以接入到 DTS 事务范围内。

确切讲，DTS是一种柔性事务，即追求最后的一致性。

有关DTS的文档，请看这个资料：https://github.com/nyankosama/slidesShare/blob/master/%E5%A4%A7%E8%A7%84%E6%A8%A1SOA%E7%B3%BB%E7%BB%9F%E4%B8%AD%E7%9A%84%E5%88%86%E5%B8%83%E4%BA%8B%E5%8A%A1%E5%A4%84%E4%BA%8B_%E7%A8%8B%E7%AB%8B.pdf