我认为读和写要整合到一个顺序序列中才能解决读写竞争问题 ...
如果读写整到一起,虽然解决了读写竞争,但是也变成性能瓶颈了,锁模式就是这种解决办法,比如数据库锁或ORM的悲观或乐观锁等。
将”客户端提交数据然后返回结果“这种方式可以看成一种函数调用Lambda架构:
“query = function(all data)”
或者说,将客户端提交数据看成是一种写操作,在服务器端对写操作进行切分并行化或异步处理,如下图:

客户端提交了数据给领域模型,模型完成业务后立即将结果返回客户端;同时领域模型将其他处理如数据库存储等通过Disruptor这个并发框架立即开启。
打个比喻,快递送物品过来,你就立即处理一下快递想要的结果,比如签字等等活动,等快递走了,你同时打开包裹,检查商品。这样效率是不是很高?如果你在签字之前,要打开包裹,验机等等一系列操作,快递肯定等不及,不耐烦了,但是你认为这样保险,而快递说有问题可和商城联系,和他们无关。
在D D D 缓 存何时持久化,领域模型打发完客户端(快递)请求后,要进行持久化(验机),通过Jdonframework基于事件的模型可以并发立即持久化,这是由Disruptor完成的,持久化动作和签字动作几乎是同时并发发生。
实现无锁异步的事件编程的好处,原先有三个操作在一个方法中顺序执行,以jivejdon论坛发帖为例:
A. 插入新贴数据库
B. 加入Lucene搜索
C. 通知关注作者的所有订阅者更新信息
这就容易碰到问题,B动作因为是加入搜索文件还要优化索引,比较费CPU,当发帖作者关注人数很多时,能几百个几千条数据要插入数据库。这些因素合并在一起,致使发一次贴,CPU负载相当高,甚至影响正常功能,比如发完新贴,理应给发贴者显示一下其发帖的新内容,结果因为CPU忙于B和C两个操作,无法显示发帖内容了,有些系统甚至出现Session丢失,连接拒绝等等问题。
而引入事件编程后,我们有两种手段来对付,并发和异步,如下处理:
A.通过无锁并发,让另外一个线程插入数据库。
B.让另外一个线程延时60秒插入搜索索引
C.加入一个队列定时器,两分钟以后每隔5分钟向成百上千订阅者发布通知,包括邮件 微博通知等等。这个队列大小可根据服务器硬件配置设置一定大小,硬件弱的,队列小些。这样还可以缓冲短时间大量发帖(写操作)引起的对系统冲击。
关键是,因为A B C三个动作我们是在EventHandler事件处理器中实现,那么进行这些重构,丝毫不会影响触发事件那一端的代码,两者松耦合,修改相当轻松,几分钟完成。
具体代码可见:
Jdon框架+Guava的EventBus实现
[该贴被banq于2013-03-26 17:30修改过]