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

SOA并不能解决高并发事务

                   
2013-09-17 11:19
赞助商链接

前面我指出传统SOA架构其实无法面对高并发事务,我以国内淘宝网的两个PPT为案例,分析一下,其中一篇是面向生产环境的SOA系统设计 by 程立

在三十页,使用悲观锁实现服务对资源的并发控制,这种方式最容易发生我在首贴里提到的死锁:




PPT也认为这种方式不适合热点资源,也就是高并发场合。

乐观锁如何呢?



虽然乐观锁短,但是容易产生脏数据。

该PPT虽然否定了乐观和悲观锁的解决方案,但是思路还是在锁的方向,没有可加锁的资源,那么我们人为制造一个锁,以操作实例也就是操作的对象的ID为锁标识,这其实是将整个对象在内存中锁起来,会发生多线程变单线程,一个马桶只能蹲一个人的现象,我在首贴中的画图中描述过这个办法。




当然,以上资料根据2009年淘宝网支付宝公布的文档,不代表他们现在没有更新升级。


1
2013-09-17 11:34

你的SOA已经使用了EDA和CQRS吗?

SOA是以服务这个方式对外提供功能,我们很显然喜欢在Service中加上JTA等事务,比如EJB的无态Bean或Spring的@Transaction标注都是激活这样的功能,这种方式实际是一种悲观事务,容易引起死锁,特别是在高并发情况下。

我们需要重新思考的是:将事务加在服务这样处理过程上,这个思路是不是有问题?因为服务只是对外提供一个统一接口,不代表对内其就是一个统一的处理过程,是一个process,这是很多人对服务的误解之处。

新的EDA+reactor思路是:服务通过发送消息给一个聚合根实体,也就是Actors模型,聚合根实体是通过消息与外面交互,其内部状态一致性操作由其自己完成。

准确说,DDD+ CQRS +EDA+reactor + Actor才是高并发事务SOA的终极解决方案。

参考:http://www.jdon.com/45738


[该贴被banq于2013-09-17 11:38修改过]

2013-09-18 09:09

2013-09-17 11:34 "@banq
"的内容
准确说,DDD+ CQRS +EDA+reactor + Actor才是高并发事务SOA的终极解决方案。 ...


这种架构虽然提高了吞吐量,但是只能做到最终一致性。如果要求强一致性,在遇到一次修改涉及多个聚合根的时候,就需要事务了。上次你提到的关于利用事件的方式来实现转账的方法(有一个帖子)实际上也没有做到转账的强一致性。

2013-09-18 09:15

2013-09-18 09:09 "@tangxuehua
"的内容
在遇到一次修改涉及多个聚合根的时候,就需要事务了 ...


你可能还没有理解我之前“数据喂机器”的理论,你这段话的逻辑实际上将聚合根和事务过程并列了,或者说,认为事务不属于聚合根范畴,甚至是凌驾于聚合根之上,这其实是“数据喂机器”导致。

实际上,高一致性事务等同于逻辑一致性,是被聚合根(也就是Actors模型)管理的,属于聚合根的上下文边界的。如果你不习惯这样的思维,那么我们可以说,凡是你认为需要使用高一致性强事务的地方就是一个有界的上下文,可以用聚合来表达。

不要将聚合根实体看成没有行为守护的抽象数据类型,看成被动的数据,聚合根是有强一致性保证的富对象。
http://www.jdon.com/45736

[该贴被banq于2013-09-18 09:17修改过]

2013-09-18 10:00

2013-09-18 09:15 "@banq
"的内容
高一致性事务等同于逻辑一致性,是被聚合根(也就是Actors模型)管理的,属于聚合根的上下文边界的 ...


意思是,只要是需要强一致性的地方都应该由聚合根来实现?那银行转账呢?你不是跨聚合根要实现强一致性吗?你上次翻译的通过设计一个转账聚合根来在代码层面实现2pc的方法,本质上也没有实现强一致性。因为当转账聚合根在第二阶段要求源账号和目标账号分别去扣钱和加钱时,这两个操作的扣钱和加钱动作并不是在一个事务内,也就是不是同时发生。详见我之前对那个帖子的回复。

4Go 1 2 3 4 下一页

赞助商链接

赞助商链接

返回顶部

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