stay_sun
发表于 2016-04-14 11:38
回复 10# cjfeii
我觉得你进入了误区 我们的数据库是为了业务服务的 根据你的想法 a 给b 转账 1000 我干嘛要 回滚
我只要保证 a 减去1000 b 加上1000 即可
cjfeii
发表于 2016-04-14 11:45
是存在这种情况的,这是两个数据库操作,如果第一个操作成功(A-1000),第二个操作失败(B+1000),不就需要回滚了吗?
回复 20# stay_sun
cjfeii
发表于 2016-04-14 11:47
如何保证(a-1000,b+1000)都成功
回复 20# stay_sun
yehuafeilang
发表于 2016-04-15 09:41
我想关系型数据库在以后很长一段时间还是中小数据量需求的主流吧,特别是针对频繁读写的。
yehuafeilang
发表于 2016-04-15 09:41
我想关系型数据库在以后很长一段时间还是中小数据量需求的主流吧,特别是针对频繁读写的。
lyhabc
发表于 2016-04-17 17:51
不结合业务的架构,就是耍流氓。
stay_sun
发表于 2016-04-18 09:48
回复 22# cjfeii
队列啊
cjfeii
发表于 2016-04-18 11:55
例子说:A账户-1000,B账户+1000
我认为会存在一种情况是:前一个操作成功(A+1000),后一种操作(B+1000)永远不会成功
比如,在A+1000执行的同时B账户销户了,这种情况怎么办?难道这种情况已经执行成功的A+1000的操作不需要回滚吗?
队列如何解决这个问题,将第二个操作一直保存着队列中,等待用户重新创建B账户(重新创建的B账户就是之前的B账户)?
你可能说在执行这个事务之前,做了事务准备工作:锁定A、B账户不允许销户、不允许等等操作
这里先不说这种做法是否合理(怎么可能不允许我销户...因为可能有人给你打钱...so...等着吧...我的天哪...万一有人准备从我账号偷钱咋办...不让我销户损失谁负责...)
如果说在事务之前,锁定了A、B账户,难道就不存在B+1000失败的情况了吗?程序员误操作永久删除B账户、贪污账号冻结B账户、bug、地震导致B账户出问题。。。
综上,我觉得事务是需要回滚的,一定成功的事务(最终一致)可能不是我常规理解的事务。
回复 27# stay_sun
睡罗
发表于 2016-04-22 00:14
这个就不好说了。
linuxforlive
发表于 2016-04-22 14:34
留个先从硬件方面改良然后再从数据库方面设计