锁定老帖子 主题:异构系统分布式事务、安全、性能
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2009-11-09
现有一项目,业务场景如下:
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-11-09
1. 业务处理速度基本取决于银行和支付系统,你再快也没用
2. 各环节都加密吧 3. 全局事务就别想了,那素不可能的。就算勉强实现了,也会慢得要死。 |
|
返回顶楼 | |
发表时间:2009-11-09
速度方面可以尝试使用MQ,用异步处理以提高用户体验。告知其已经提交,处理完发短信确认就是。
安全一般使用证书加密验证。 事务方面最麻烦。分布式系统的事务恐怕只能通过BASE和CAP策略解决。不过如何实现这两种策略我不清楚。 |
|
返回顶楼 | |
发表时间:2009-11-10
跟银行和支付平台的接口基本上不是你能决定的吧。如果是JMS的还有可能跟你的java平台统一事物。如果是文件什么的不能控制分布式事务的方式就本着宁可漏发,不要重发的原则做吧。
|
|
返回顶楼 | |
发表时间:2009-11-10
得SOA吧,用些产品容易些
|
|
返回顶楼 | |
发表时间:2009-11-10
整个应用最难的就是事务,如果银行、支付平台、运营平台数据不一致的话,我想这用户可能是无法接受的。
|
|
返回顶楼 | |
发表时间:2009-11-10
最后修改:2009-11-10
从用户扣费的时效要求有多高?如果不高,可以考虑用异步的方式,模仿企业向银行送盘的方式从移动运营商或者银行扣款。这既可提升用户的体验,还可以避开使用全局事务带来的一系列恐怖问题。
另外,异常总是不可避免的,要考虑到扣款成功,但被告知失败(反之亦然)的处理方案。这种事故发生的几率很小,但不可不考虑。 |
|
返回顶楼 | |
发表时间:2009-11-10
zhxp791008 写道 整个应用最难的就是事务,如果银行、支付平台、运营平台数据不一致的话,我想这用户可能是无法接受的。
保持数据的一致性是目的,使用事务是其中的一种手段。涉及金额的数据不一致,无论问题出在哪一方都无法接受。如我上面所说,可以考虑使用异步的方式。 |
|
返回顶楼 | |
发表时间:2009-11-10
接口的两端两两保证数据一致,从而保证整个流程下来数据一致,不知道行不行?
另外数据不要求实时吧?比如新进了一笔钱,允许过一段时间才能查到记录。这样可以用缓存或临时表啥的来提高性能 没做过跟钱相关的系统,胡言乱语的,希望大虾指正。 |
|
返回顶楼 | |
发表时间:2009-11-10
异步肯定是必然的,同步就见了鬼了.楼主的系统不说.单是银行内转笔钱就可能去人行转了一圈才回来.
|
|
返回顶楼 | |