287854442 写道
bobotc 写道
确切的说银行项目是没有使用到事务的。。
不使用事务，那使用什么来保证安全性和可靠性呢？
确切地说，应该是不用分布式事务（如XA事务)，尤其是局域网络之外的分布式事务。
分布式事务相对本地事务来说，虽然都是事务，有相同的或类似的结果预期，但实现方式及其效率、稳定性、可靠性差别巨大。具体细节分别可以写成两本厚厚的书了，抱歉我本人也没看全。
但是这种差别的存在应该被知道，分布式事务是基于网络交互的，网络的相对不稳定性和相对低效，分布式事务一样也避免不了。可以简单的理解分布式事务使用了一系列的交互机制/规则来保证数据状态的一致性，但这些规则细节对应用是透明的、不可控的，同时在此过程中产生的同步等待及资源竞争也是相对巨大的、不可控的，实际应用上是不能接受的。
针对具体的应用需求，我们完全可以设计完整的业务逻辑规则来保证可靠性和一致性。
数据库事务要求的OCID,和实际业务需求要求的可靠性、一致性以及所谓的资金安全是不一样的，OCID事务要求高得多，而且在数据状态完全一致之前对应用是透明的，在交易系统里可以不用这样严格。比如对资金安全来说，资金冻结在前，之后才允许交易，最后再同步交易状态（还有各阶段异常的补偿措施），这些阶段是分开的，在不同位置单独完成的，只要保证顺序，是不需要在一个数据库事务里完成的，也不需要都用实时、同步的方式完成。这种机制对系统的要求及其效率表现要比OCID事务机制高很多。当然，对应用系统的设计和开发的要求也要高一些。
实际应用还有一些其他约束也是分布式事务无法满足的，比如双方是独立的系统，甚至不是一个金融实体，要把双方的数据库纳入到一个分布式事务里是不可能的。很多介绍分布式事务的文章里会讲到资金转账的案例，即从A账户转账到另外一个系统的B账户，实际当中是否使用分布式事务来实现此功能，我对此表示相当的怀疑。
还有一个不能使用分布式事务的重要的因素，上面多次提到了透明和不可控。一旦发生异常，金融系统在业务规则上有它一套完整的补偿措施和干预手段，而且会涉及人工干预和不同金融实体的交涉。这些问题靠分布式事务是根本做不到的。
实际生活中，我们在跨行或异地存款、转账时，作为个人在完成转账后，经常还要过一段时间才能到账(当然也有很多提供实时到账服务的，不过这同样跟分布式事务无关)，这已经是我们普遍接受的习惯性的事情，而且我们也不需要在到账之前一直在银行等待。
本质上来说，数据库的事务交易和金融交易完全不是一回事儿，是不同层面、不同领域的概念，只不过从技术实现角度上它们存在着一些必要的、习惯性的联系，所以容易在某些地方容易被混淆。我曾经在对一篇关于“Base 一种Acid的替代方案”的评论当中提到过，并非原作者的本意，但实际传播和读者理解过程中存在着把金融交易（商业交易）和数据库事务交易混淆的问题（尤其是所谓‘最终一致性'的概念)，可惜并没有人认同，大概是做金融业务的人关心技术实现的不多，同时做技术研发实现的人关心金融业务的也同样不多吧。