异构系统分布式事务、安全、性能

其实这是一个三方的对账，原来做的一个项目里有遇到。但是不是你所说的这三方（银行，支付平台，运营平台），而是用户，银行，SP。

从钱的角度来分析，用户和银行实际上可以看成一体，因为用户手里的钱最直接的体现就是银行账户上的数字。来看看会出几种情况：

1.用户钱被银行扣了，SP钱没有增加（可能是SP内部系统异常）。
2.用户钱被银行扣了，SP钱增加。（正常）
3.用户钱没有扣，SP钱没有增加。（正常）
4.用户钱没有扣，SP钱增加。（这种情况基本不存在）

一般来说，无论是支付平台还是银行的接口（WS,HTTP）内部都有很完善的事务系统，你都不需要关心，你关心的就是发的请求和响应，钱是否扣得成功。其次，在执行本身SP支付系统之前都会检查银行返回的是否成功（这就是为什么第四种情况不存在）。成功，调用本地支付接口，如果调用失败，会产生第一种情况。

我们采取的解决办法：

1.银行及支付平台接口调用，记录详细日志（包括时间，流水，钱，返回串等）。
2.本地支付系统客户端调用日志。
3.本地支付系统服务端执行日志。

日志系统通过事先约定的协议对账，达到平帐。

楼上专业。

比较要注意的是不要向银行重发请求，可能会造成扣款多次。可能的状况是请求发出去了，自己的数据库更新前应用挂了。下次系统起来可能认为这笔请求还没发，再发一次。

支付平台和银行的接口有不同的地方，但是流水号作为唯一标示，是不会出现重复缴费的情况。其实在我之前描述的银行端日志记录又可细分为两种，在生成流水号记一次，缴费成功或失败，更新刚才的那条记录，作为缴费日志。同时，还有一张表来记录接口调用情况，记录出入参成功与否等，作为调用日志。这样基本就可以确保不会出现重发缴费请求，流水对不上，系统崩溃造成的异常等等

总结下：
性能依靠异步机制实现，达到快速响应。
分布式事务基本上采用应用设计层面来达到事务的最终同步。中间状态不一致，通过应用层设计来达到最终的事务一致。

还有没有更好的设计，主要是事务。。

我认为对于事务的处理，应该由支付平台来做处理，运营平台最好是发起WEB SERVICE请求，支付平台如果在运行过程中如果出错的话，可以执行一个冲正流程，根据这笔订单的流水号，进行回滚操作
运营平台只接收平台返回的消息

如果平台不能提供复杂业务流程，那只能在运营平台与其他各平台之间专门增加一个业务层
或者如果条件允许的话，我感觉还是采用比较专业的EAI工具（如：TIBCO）来做更合适

可以参考 《程立：面向生产环境的SOA系统设计》里面的一些设计原则
对于这些异构系统，使用事务是个不可能的任务，只要最终达到一致性即可。

   楼主有个很大的误区，也就是想在不同的系统间实现所谓的分布式事务。除非有底层的事务服务支持，比如ORB事务，否则的话是不可能实现的。
   那么我们又如何在实际的业务应用场景中来实现这样的情况呢？其实有个很清楚的概念，补偿事务。准确讲补偿事务并不是我们传统意义上的事务，而是通过补偿性行为来实现事务的原子特性。
    在楼主提出的应用场景中，有两个问题很关键，一个是事务锁实现，这个锁其实也就是一种预扣，避免查询与购买时费用合适，而付款时却出现费用被另外的交易处理而出现不够的失败情况。另外一个就是补偿性事务处理机制，也就是在事务处理失败后的恢复机制，因为涉及银行系统（银行系统有基础性事务支持），所以必须想清楚如何处理补偿。

谢谢回复！
以前就是想是不是有种在异构系统中以普通的xa协议方式实现分布式事务的可能性。
现在看来，没有传统方式实现的可能性，只有在应用层设计上考虑才可能达到数据的一致性。
如消息中间件等做。
好象tuxedo专门做这个的。

你的问题，楼上 “凤舞凰扬”已经给与不错的回答了

对于这么多异构系统来说，如果要做成一个事务内控制，基本不可能实现。

1 性能：各位已经说得非常不错，如果需要有快速响应，就只能异步了。如果是同步的话，速度会很慢，对前端的web app带来很大的压力。
如果能够异步的话，最好采用异步消息机制，比如JMS之内的，速度非常快，稳定可靠

2 安全：关于安全的问题，目前有非常成熟标准的东西了，无论是jdk自带的api，还是其他第三方开源产品都非常成熟。但是无非离不了 DES加密，RSA签名...等算法。 自己调用JDK自动的lib已经可以做到非常安全。

3 事务： 这么多异构系统，不太可能做到同步事务，只能是采用 “补偿” 机制来实现。最简单的方法，就是 类似银行的 当日对账 ，比如可以采用一台服务器每隔几十秒提取各子系统的交易记录进行比对，根据业务逻辑判断是否完整，如果是异常，再进行相应的补偿操作。