开始activeMQ的源码分析

公司的各个产品显然是一种分布式的架构方式了。现在系统之间整合成为最大的问题。尤其是在消息传递方面,是一个最大的问题。

现有的方式是采用触发器在数据源中将变动的数据触发到一个表中,然后将其打包成xml。通过webservice方式发送到目标库中。然后目标库进行解析xml,更新目标数据库。

这样,目标和源的数据结构我们都需要了解,而且,源数据发生变动之后,需要对目标进行变更。也就是直接操作目标数据库。这可能会引起目标数据发生异常。现在整个团队中大约有超过60%的时间都是熟悉各个系统的数据库表设计。接入一个系统会耗费很长的时间。

其实从接受部门,我管理整个团队开始了解这个产品,对这种做法有严重的抗拒心理。最近一直在看一些分布式的架构。作为淘宝的分析,我看的最多的也是淘宝的架构。感觉按照公司目前的研发能力,还是采用开源的消息中间件比较稳妥。

考察了几个消息中间件,包括淘宝的metaq和activeMQ。经过分析,感觉淘宝的东西更注重的是性能,采用的zookeeper作为同步方式,技术起点还是比较高的,感觉如果出问题,可能不太好解决。简单看了下activemq的设计,还是比较全面的。也更加符合我们当前的需要。所以,就把activemq源码在本地用maven构建了一下。并开始了阅读源码之旅。之前也完整的看过几个开源框架的源码,感觉看activemq的源码还算可以,没有那么吃力。稍微感觉吃力的地方就是并发方便的。这方面是弱项,也借这个机会好好的弥补一下。

activemq完全支持JMS规范1.1.这里先把JMS规范传上去。

http://download.csdn.net/detail/sjbup/5171045

稍后我将逐渐开始active源码的分析。限于个人水平,可能分析的并不是很好。只作为个人的一个积累。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值