一、提交代码写到一起
例如:
C# code
?
这样Commit阶段都是简单地信号,之前都已经更改了数据库事务日志数据,只是还没有提交而已,同时失败的可能性会比较小。这种方案不是正规解决方案,只是说失败的可能性减小了。
二:设计“自动撤回、冲销”流程,并且为每一个分事务动做都写一个额外的“确认”步骤。
当执行确认时,校验当前进程随机会话编号,如果事务发生会话的编号跟确认会话编号一致则记录确认成功,如果不一致(例如进程失败而重启了)则执行冲销流程。
这种方案是正规的“最终一致性”解决方案。最终一致性是业务方案,业务就是这么明确的——任何业务都需要异步确认一遍,确认时判断当前进程会话编号跟业务发生时的进程会话编号是否一致。
在比较现代的高性能系统中,实际上讲究的通常是“最终一致性”而不是纯技术的一致性。所以纠结数据库事务保护,可以看作是性能杀手,是不了解大数据平台编程设计的,流程设计倾向于高并发电信级处理理念,跟那种入门者喜好“数据库事务技术”是根本相反的算法选择!!所以在程序上是负载均衡、真正分布式的。干某件事情的进程负责异步地确认任务,否则假设进程失败了、或者事务超时了(例如5秒钟还没有完成事务),不得不由其它进程事后处理,就开启业务数据冲销动做了。
评论