发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 3 4 下一页 Go 4

关于EventSourcing事务的问题

                   
2013-11-19 10:20
赞助商链接

关于EventSourcing事务的问题,还是有点不太明白。
在事件驱动编程中,数据持久化是异步,那如果持久化失败,我如何在业务流程中得知并处理,如果要等到数据持久化成功才进行下一步操作,不是又变成同步模型了么
@banq 老师,心中疑惑,百思不得其解
[该贴被tecentIDA8F53于2013-11-19 10:32修改过]

4
2013-11-19 11:17

2013-11-19 10:20 "@tecentIDA8F53"的内容
那如果持久化失败,我如何在业务流程中得知并处理 ...


这是可靠性问题,持久化成功与否的结果不构成影响业务流程,业务事务不必依赖持久化来完成,持久化也不是构成业务事务的一个环节。

要做到持久化成功,可以采取重试方式,如果重试超过一定次数,呼唤人工介入。

EventStore实际是一种Domain 日志,我们平常看到的是网站访问日志,EventStore也是一种日志。用日志角度看EventSourcing就比较释然。

2013-11-19 11:23

@banq 您的意思是,持久化只是可靠性的保证,业务的事务与持久化无关,可靠性的保证是:比如数据库宕机,在故障恢复后,之前未能持久化成功的数据能写回库内?
[该贴被tecentIDA8F53于2013-11-19 11:24修改过]
[该贴被tecentIDA8F53于2013-11-19 11:24修改过]

2013-11-19 11:33

能具体点么,比如我们业务中的一个场景,
一个订单比如,4中状态,下单,处理中,结果(成功失败)
其中处理是依赖N个三方系统(使用长链接通信),第三方的系统并不能马上处理返回结果,也是需要等待。
常规的做法是
1.用户下单,写库(记录数据和状态),发送jms
2.接收到jms,从库中读取数据,开始处理,调用三方系统,等待处理完成,更新库中的状态,发送结果jms
3.接受结果jms,从库中读取数据,给客户发送结果
如果第一步持久化失败,后面的就无法继续了。

要根据DDD的思想改造,使用事件驱动,该如何改造呢,订单domain总不能一直存在内存中吧,如果持久化失败,服务器也宕机,那等于就算订单数据丢失了

[该贴被tecentIDA8F53于2013-11-19 11:42修改过]
[该贴被tecentIDA8F53于2013-11-19 11:43修改过]
[该贴被tecentIDA8F53于2013-11-19 11:43修改过]

2013-11-19 13:48

2013-11-19 11:33 "@tecentIDA8F53"的内容
使用事件驱动,该如何改造呢,订单domain总不能一直存在内存中吧,如果持久化失败,服务器也宕机,那等于就算订单数据丢失了 ...


可能你思路还没有从传统请求思路切换到事件驱动上来。
建议看看:http://www.jdon.com/eda.html

注意到D-EDA,通过领域模型内部发出的领域事件来作为消息的来源。

领域事件发出的事件作为日志保存然后作为回放,称为Event Sourcing。这个回放过程实际类似JTA等同步事务的回滚一样。

JTA的同步事务都是在内存中有一个监视锁,如果同步事务工作期间,掉电怎么办?所以,我们假设比较的前提要一致。

掉电等可以使用备份冗余来,内存中有一个订单,通过复制策略复制到备份服务器上,掉电了可恢复,这些技术在分布式技术中相当成熟,已经被用在大数据实时分析中。
见分布式系统:
http://www.jdon.com/DistributedSystems.html

下面回答如果持久化失败怎么办?我之前已经回答了,持久化失败后自动重试,多试验几次,因为是日志追加,不存在写操作争夺的因素,这种成功概率要高于平时数据库读写操作。

只有日志追加成功,这个数据才会从消息队列中删除,否则一直留着,重试次数大于10了,呼叫人工干预即可。消息队列也是有备份冗余的。具体可见LMAX架构:http://www.jdon.com/42452

最后重申一下,在新的架构中,至少有两个逻辑层:业务领域模型和底层仓储,也就是持久化。低层次的问题不会反映到高层次上,因此,底层仓储出现问题,不会打扰领域模型之间的业务流程。持久化失败如同日志写失败,这个靠容错性等措施完全可以保证,不必去干扰正常的业务,打个比喻,法庭上有笔录,笔录人员不会说,你们辩论停停,我笔坏了,等我找支新笔或换台新计算机,你们再继续辩论。当场晕倒。

你举的这个案例,实际是将这两层合并在一个平面上。按照DDD和事件驱动应该是:
1.用户下单。(异步后台持久化写库)
2.返回客户 http结果 200,这是REST的标准响应。
3.用户再次发出REST的get请求,对刚才下单的订单查询。
4.返回内存中订单。(一般这样一个来回,第一步异步持久化的订单也正常完成了,可以在此步做个检查)。

4Go 1 2 3 4 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com