最新评论

终于找到一篇靠谱点的文章了，可以发一份Demo给我吗？ threemiles@163.com 谢谢

1.垄断企业的外包产品，社会因素大于技术因素 2.类似问题换个角度看，这样又可以增加几个就业了。 3.技术上，干这行，倒是应该追求精益求精，做不做，又是另外回事了。 ps：同样问题，遇到过好几次了！呵呵~

移动应该有很多烂帐

移动让银行回滚，还是银行让移动回滚？这是两系统 让谁滚都不行。 营业厅充值也会遇到这样的问题。

银行的系统确实存在很多问题！他们大多购买国外的系统，然后自己活着委托第三方进行二次开发，而且大多采用的是中间件的问题，有一些领导根本不懂，所以在系统整体架构的设计上有很多问题！

银行扣款回滚没那么容易吧

高手一出手就知有没有！

比较同意Ocean,如果银行没有提供相应回滚的接口，就是分布式事务也没有辙，我觉得我们业务系统要做就是银行扣钱后，我们业务系统在做续操作导致系统崩溃后我做友好的救措施，不能就这么不清不楚，能退回钱给客户，我想大多数用户是能接受，就怕不清不楚钱没了，这才叫人郁闷，我觉得如果可以在我们必须放在同一个原子操作的几个操作步骤前，先产生一个流水操作号，然后记录每一步的操作日志，出现系统崩溃后客户可以拿着流水操作号去找人工客服，做后续处理操作，我想这样也是可以接受的，必尽没有绝对的可靠

@ocean 有理，但出错了要给用户提示信息，事后返款。

分布式事务的另一个缺点是：深度耦合。 很可能最后的实现是：移动的程序，读/写移动的数据库；招商银行的程序，读/写招商银行的数据库，并且读/写移动的数据库。 这会有几个问题： 1. 数据库安全问题。如果移动与招商银行之间没有专线连接，通过互联网，则互联网上任何人都可以对移动的数据库进行攻击。数据库安全问题的最基本解决办法是，让互联网上的人，连不到自己的数据库。 2. 移动的数据库如果要更改表名，需要招商银行的配合。如果招商银行说，改什么改，现在挺好的，不改！那么移动公司连自己的数据库表名都改不了。这种设计，移动公司的人，怎么可以接受？ 3. 如果移动的数据库中，某个数据错了。原因可能是移动自己的程序改错了，也可能是招商银行的程序改错了。怎么进行问题定位？难！ 我们给同一个客户的两个IT系统做接口，都会劝用户用FTP/webservice，不要用直接读/写两个数据库。至于两个公司系统之间，更是如此。 上面分析漏掉了另一点，移动公司不仅要更改用户的移动帐号上名义金额，同时招商银行还要给移动的银行账号汇钱。Assion Yang 所说的"批文件"是对的。大客户之间的结算，并不是一小笔一小笔来核对，而是一个周期(月、周、日）对帐一次，传送一个对帐大文件(包含明细条目)，各自挑出疑问数据，先把无疑问数据由系统自动关联、关闭，有疑问数据人工逐一核对、纠正。 至于银行之间转帐，有的超过10工作日还未完成，那只是银行核对工作的安排不妥当。IT系统24小时运行，银行也可以安排人员24小时轮班核对差异数据。只不过我们的银行不愿意服务这么到位而已。

完全不用需要知道这块，因为很多时候移动的支付系统都是第三方开发，所以应该没有这么严谨的ACID的东西。

@ocean 同意你的观点。这个银行那边成功了，你自己这边失败了，是很难处理的。

感谢各位非常专业的回复，我收获不少。 其实在事务处理时，确实需要根据场景来权衡。两段式提交虽然在一定程度上保证了结果的一致性，但同时也制约了系统的水平扩展。针对第三方服务，如何来协调和通信，以尽量保证结果的一致，对设计来说，是一个挑战。我能想到的，除了分布式事务外，就是看是否能通过协调器，根据各个原子事务的结果标志来协调，并根据不同结果发出不同的通信，进行对应的处理。

这个是没在同一事务内的，银行对于移动来说也是个商户。提供接口进行实时充值的，有些业务甚至是跑批文件的形式。最终移动和商户会采用对帐文件进行定时对帐。是允许出现以上情况的。

学习楼主的研究精神。。 ocean和Jacklondon Chen的观点让我受益良多~

楼主的治学精神值得学习! 不过回复中有些人的实践经验和见解也很有价值!

补充一下，上面讲的出错例子，已经表明这里已经没有“数据库事务的原子性”了。 如果协调器通知第一个数据库，你commit 吧，第一个数据库照做；协调器通知第二个数据库，网络故障，通知发不过去。----结果第一个数据库的更改对其他用户可见，第二个数据库的更改，对其他用户不可见，这不是我们期望的吧？数据库事务的原子性完全被破坏！ 另，数据库表态：准备好 commit, 并不说明以后 commit 就一定能成功，也有可能失败。如果第一个数据库 commit 成功，第二个数据库 commit 失败，又如何？两阶段提交事务的逻辑上，并没有考虑到这一点。

专业！

顺便说一个，两阶段提交事务，逻辑上有缺陷，并不能保证100%成功。 两阶段提交事务，通常有一个协调器，所有参与事务的数据库，通知协调器，自己准备好了，协调器再次通知每个参与者，准备提交事务，每个参与者各自准备提交事务，向协调器报告OK.协调器判断是否所有参与者的回答,如果都是OK，则依次通知每个参与者，提交事务。 这里的问题在最后一步：“依次通知每个参与者，提交事务”，如果协调器通知第一个数据库，你commit 吧，第一个数据库照做；协调器通知第二个数据库，网络故障，通知发不过去。就完了。 两阶段提交事务是一个失败的技术，它依赖于网络，而任何一步，网络都可能故障。如果它每一步网络操作都需要防范，那就形成了无穷循环。

对于银行来说，分阶段提交是不可能的，银行总是先扣款，如果业务失败，进行退款操作这就等于事务补偿，实际上这种事务补偿出错的概率非常高，比如退款时因为线路原因而导致信号没有发送给银行，或者银行端出现问题，这时退款操作无法进行，你的业务仍然僵持在那里，所以类似这种事情，只能通过时候核算来进行退款，实时退款只能让系统更复杂，系统越复杂出错的概率就越高。 银行这边也一样，不可能搞一个复杂的支付给你，它不会考虑你的事务补偿问题，否则银行也会面临更多问题。

这种系统一般运营商是通过银联实现代扣的。通常这种系统是有多个子系统组成，比如自助终端系统，运营商的系统，银联系统，商业银行系统。所以无法应用事务。 系统间多采用socket自定义报文实现业务。一般情况下代缴费系统只会返回交易成功或者失败。楼上的明显是自助终端和银行方之间的交易超时，也就是自助终端系统不知道银行代扣是否成功，在这种情况下，一般的话会调用冲正交易取消代扣，实时返回金额，如果没有的话，就采用日终对账，隔日返回给客户，并中止后续的业务动作。 如张逸所说的应该是超时异常情况下，系统没有设计好良好的处理机制，超时了仍强行执行后续动作。至于系统崩溃，弹出对话框就更不应该了，估计代码没考虑异常机制。最后补充一下，这种系统一般都是关系户，所以系统好坏通常不重要

佩服博主认真专研的精神！

我的观点： 跨银行、跨机构的交易，不应该使用分布式事务。这是因为，一旦出错，看不出是银行还是电信的系统错误，也无法提示操作用户出了什么错，甚至不能提示后台程序员出了什么错。 博主所说的 case, 我觉得应该这样设计： 1. 招商银行生成跨机构交易单据z（招商银行帐户x向移动用户y冲值100元） 2. 招商银行对帐户x扣款100元。1、2 组成一个数据库事务 3. 跨机构交易单据通过某种方式传送到移动公司IT系统(FTP/webservice/MQ) 4. 移动公司IT系统对交易单据进行本地备份(文件落地) 5. 移动IT解析交易单据z，完成冲值 6. 移动IT生成电子回执，确认交易单据z已经完成 7. 以上5、6组成一个数据库事务。 8. 移动IT生成电子回执通过某种方式传送到招商银行IT系统 9. 招商银行解析电子回执，与交易单据z 进行关联。这一步独立作成一个事务。 10.招商银行 IT 系统定时扫描电子回执与交易单据，发现超时未完成匹配的，生成报警信息，由人工干预。 之所以要这么复杂，也是因为通常，一个机构的数据库，不能被另一个机构的IT系统进行读写。

尼玛，名侦探柯南出现了

银行两阶段提交事务没做好，而且系统是利己设计，即清算/差错平台出来的结果总是自己银行的钱是多出来的，不会少!另外，ATM与自助机一般用windows平台，容易崩溃。我一般都是去柜台做，不相信ATM机。

ocean说的有道理，银行一般只返回扣费是否成功

那该怎么和银行的支付系统进行分布式事务的集成呢？银行一般只提供支付和退款的接口。

[quote]段英杰：以前没有注意过，只是知道为了保持数据的ACID需要使用事务。在博主的这个例子中，什么是两端式提交呢？[/quote] 一端是银行收费，一端是移动收费。所以是2端。这种情况下，银行端会提供2个业务，一个是收费，一个是收费撤还。 针对楼主这个情况，首先进行的是银行收费，成功后才进行移动收费，当移动收费失败后，则需进行银行收费撤还，这样就能保证整个操作的事务一致。

楼主海涵 呵呵 没办法。急招啊，招不到我完蛋啊！！！！ [b]广告时间（明天就不放了 呵呵） 嘻嘻[/b] [img]http://pic002.cnblogs.com/images/2012/273897/2012020610531915.gif[/img] [b]杭州星软集团招人了！！如果你会SIlverlight或者WPF。来吧。薪水高噢亲！！公司好哦亲！！福利好哦亲！！ 来吧 来吧........ 想来加33471036这个QQ ...[/b]

最主要的原因在于银行扣款是无法使用事务的，也即银行只是返回扣款成功或者失败的消息给你，如果你后续的业务失败了，你是无法要求银行将上次的扣款也做失败，也即无法回滚，换句话说，一旦银行扣款成功了，那么无论如何都无法回滚了，唯一的可能就是清算的时候重做事务，或者退钱给你，但是退钱这个事情通常需要几个工作日的周期。 所以要把付款这个事情放在自己的事务里面并不可行，把自己的逻辑放在一个事务里面倒是必须的。 中间的失败则应该是一个隐藏的bug而导致的。

@楼主，问一下，Twist是为java平台开发的，你们是如何将Twist和.net结合起来的？

以前没有注意过，只是知道为了保持数据的ACID需要使用事务。在博主的这个例子中，什么是两端式提交呢？

banq说应该以book为聚合根的思想，那完全是另一种思维导向了。请老师给分析这两种结论的本质区别

我测试了，的确是可用的，调试模式下是不可用的，要生成后再调用就可以了，具体原因自己想吧 [url=http://www.mydll.org/]Dll大全[/url]

[url=http://www.cnblogs.com/52rs/archive/2012/01/04/2311628.html]Petshop5.0下载官网[/url]

@过客1 :)

有点疑惑，按照这个设计模式，用户在调用TaxOp时，还不是根据纳税的类型来判断是该传入PeronalTaxStrategy还是EnterpriseTaxStrategy？客户端的调用还是避免不了switch呀，这么一来，如果以后要增加多一种纳税类型，客户端的调用代码还是要修改的呀。

觉得还是PostSharp实现的方式牛叉

问下楼主，你有没有用EF4.1实现你的模型，并反向生成数据库。我初夏了个问题，关于Render,BorrowHository,LibaryCard.假如我把LibaryCard单独作为一个Entity,而不是Value Object。这里会出现数据报级联引用。我目前只能先写好数据库，不建立外键，去做配置。

@姜敏 应该是EA把

[quote]天外来客："面向接口的设计"这种说法有点过了 <br>数据访问层抽象出一系列接口，并使用工厂模式主要是为了能方便的在不同数据库之间迁移，业务逻辑层采用这种方法有什么意义呢？采用接口有利于封装变化，但是业务逻辑的变化必然导致界面的变化，这种封装又有什么意义？[/quote] 我也有这个困惑，业务逻辑层的接口设计就是为表示层而生的。

如果服务不在线或者Down了 那么获取元素据就抛异常了吧

你好！我想请教您一个问题，就是我的电脑装SQL SEVER 2008 时，我打开 windows communication foundation ……，出错，并且2008还装不上，请问是什么问题啊！？急

很牛的实例 取经了

@jiaxingseng MSDN订阅应该可以获得TFS，不过我不知道TFS有没有License限制，以及对服务器数量的限制。 其实这些工具基本都是客户来选择，我们提供推荐。即使要我们来推荐，自然还是Mingle+Go+Twist的好罗。

看来大家都比我厉害，哈哈。我确实没有仔细去想。不过这样也好，以后还可以改变硬盘大小。

羡慕楼主的 8G 内存。 :) 学习了，在虚拟机中扩展硬盘大小还是很有用的。 还好我对 Virtual Box 的 Dynamically expanding storage 的理解一开始就是正确的。 :)

@张逸 TFS貌似是只要有professional MSDN订阅就不需要额外的费用了？

哈哈,我没有看详细解说,我只看 [storeage details] Dynamically allocated fixed size 似乎没有看到Dynamically expanding storage,难道是旧版本?一直以来都是知道虚拟硬盘动态分配的都是有固定大小的,只是用到多少分配多少.并不是随意变更硬盘的大小.

@sunriseyuen 让我们看看Virtual Box的提示怎么写的。选项是这样的： Dynamically expanding storage。 这给我的错觉是它是可以自动扩展的。 UI的上方是对这个选项的说明。坦白说，每次创建Disk时，我其实并没有仔细看。为了回答你的疑问，我特地看了看，信息如下： A dynamically expanding storage initially occupies a very amount of space on your physical hard disk. It will grow dynamically(up to the size specified) as the Guest OS claim disk space. 关键还是括号中的内容(up to the size specified)。只有这里才说明了这里所谓的dynamically expanding是有限制的，就是你指定的容量为最大容量。 我在文章中并非是说Virtual Box有什么问题。事实上是自己没有看清楚。但不可否认的是，有很多人都产生了误解。可以在Google上搜到。或许是英文对于我们而言，太不醒目了。不过，我觉得这种关键信息，最好还是highlight的比较好。