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

zhizhesky
您好各位大牛，最近在研究Jdon 框架，在看介绍时看到JF关键技术特点中的第2点:
事件驱动架构Event-driven Architecture(EDA) ,异步领域事件,并发策略, 懒惰加载，异步消息机制，结合JMS可实现大型分布式可伸缩的架构, 6.4整合入号称最快的并发框架Disruptor。

请问Disruptor 如何做扩展呢？加机器+轮询？
还有就是Jdon +Disruptor 如何去查看delivery history ?

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

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?
banq 2013-01-08 13:48
2013-01-08 12:36 "@zhizhesky"的内容
请问现在 JiveJdon 是用的什么扩展 in-mem cache 呢？ hazelcast? ...

hazelcast替代JF缺省的ehcache

使用 local cache + memcached/redis都是可以的，但是注意这里local cache其实是in-memory cache，这也是in-memory 本身的含义。