关于基于 Jdon+Disruptor 的 横向扩展

13-01-07 zhizhesky

您好各位大牛,最近在研究Jdon 框架,在看介绍时看到JF关键技术特点中的第2点:

事件驱动架构Event-driven Architecture(EDA) ,异步领域事件,并发策略, 懒惰加载,异步消息机制,结合JMS可实现大型分布式可伸缩的架构, 6.4整合入号称最快的并发框架Disruptor。

请问Disruptor 如何做扩展呢?加机器+轮询?

还有就是Jdon +Disruptor 如何去查看delivery history ?

要知道如果采用 akka + rabbitmq, 支持很好的扩展。

                   

2
zhizhesky
2013-01-07 17:09

还有就是 DDD 的 In-Memory cache 怎么横向扩展成分布式的?改成 memcached 或者 redis ? 还是说我说本就不应该扩展?

banq
2013-01-07 17:27

横向扩展也就是scalable可伸缩性关键是靠事件。

将Disruptor的消费者作为rabbitMQ的生产者即可。

Model--->Disruptor--->rabbitMQ ----->DB

关于in-memory cache的横向扩展主要选用分布式缓存,hazelcast 等都可以或兵马俑 ehcache+terracotta,memcached和redis由于不是Java,只能做JVM之外的二级缓存,in-memory cache需要和Java应用在同一个JVM中。

关于是否需要Event Store,也就是保存事件还是保存领域模型状态,取决于你是否需要事务机制,Event Store可替代传统意义上的JTA等事务,实现回放,但是事件保存时需要根据先后排队,不能前后顺序搞错了,还要解决两个事件同时发生问题,后者可参考LMAX架构,使用两个Queue.如下:

Comand--->Disruptor1---> Model--->Disruptor2--->rabbitMQ ----->DB

在Disruptor1处就进行Event Store比较准确,直接将用户发出的命令按照他们先后次序储存。

总之,用事件的event store想法虽然好,但是真正替代JTA之类成熟同步事务,还需要一段路。

目前Jdonframework默认采取的是保存被事件改变状态,类似传统的一种储存方式,也能遵循DDD+仓储的原本意义。

zhizhesky
2013-01-07 18:36

非常感谢Banq 的回复。如果说 in-memory cache 一定要在同一个JVM中,JVM同步是不是会带来很多额外的开销?那我偏向于用 local cache + memcached/redis 层cache + repository 层.

zhizhesky
2013-01-08 12:36

请问现在 JiveJdon 是用的什么扩展 in-mem cache 呢? hazelcast?

2Go 1 2 下一页