![](https://img-blog.csdnimg.cn/20201014180756738.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
MOM(消息中间件)
shidcai
这个作者很懒,什么都没留下…
展开
-
JTangMQ开发历史
2004年11月 J2EE应用服务器立项,阅读JMS规范12月 收集关于JMS的OpenSource和现有的MQ产品 2005年1月 确定分析JBossMQ,UberMQ和OpenJMS的源码3月 总结和汇报源码分析成果,并开始对JBossMQ,WebloigMQ,SonicMQ等的测试4月 命名J2EE应用服务器为JTang,JMS实现为J原创 2005-07-21 00:27:00 · 2667 阅读 · 0 评论 -
线程的上下文开销真得那么厉害吗(2)?
线程切换的开销的确是比较厉害的。这是从今天的实验中得出的结果。 为了解决上次提出的疑问,今天在实验室做了一个试验,来测试线程的切换是否开销比较大。由于主要是为了比较线程的数目多少对性能的影响,所以,具体的测试环境就不提了,只要每次实验在同等的条件下即可。 首先,在MQ的Server端启动100个读线程,100个写线程,100个消息deliver线程,客户端同原创 2006-01-07 23:04:00 · 10526 阅读 · 9 评论 -
线程的上下文开销真得那么厉害吗(1)?
终究还是郁闷着了,为了JTangMQ的性能。 都是因为MQ,这个令人又爱又恨的家伙。想起当初刚刚开始设计JTangMQ的豪言壮志,为MQ设计、coding的三百多个日夜历历在目,如今却坐在椅子上一声叹息。为何JTangMQ的性能还是那么不尽如人意?为什么呢? 最初的设计目标是“超过国产MQ,迈向SonicMQ”,而现在的产品同JBossMQ相比还有那么一点的差距。这个差距原创 2006-01-07 00:11:00 · 7805 阅读 · 18 评论 -
JTangMQ的现在和未来
原本打算今天只是想写写JTangMQ接下来的改造计划,正思考着,接到吴健老师打来的电话,需要我提供一些JTangMQ的相关资料,那就干脆写一下JTangMQ的目前的情况以及将来的改造思路。 消息中间件的出现大概已经快有七八的历史了(具体什么时间开始还没考证)。起初的时候,各个厂家由于没有统一的标准,也出于企业的private的目的,各个消息产品都有自己的api和架构,彼此之间并不相容。原创 2006-01-08 00:16:00 · 3417 阅读 · 1 评论 -
消息cache,我真得需要你吗(1)?
由于JTangMQ提供的消息服务是异步的服务,消息的发送者和接收者可以不需要时刻在线或同时在线,也不需要知道彼此的身份,发送者和接收者只需要同MQ的服务器进行交互。因此,在实际应用中可能会出现两种场景:一是消息的发送者和接收者同时在线并分别不断进行收发操作。此时,对于服务器来说有一个消息接收流量和消息发送流量,如果消息接收流量大于消息发送流量,则服务器上的消息数就会越来越多,最终将原创 2006-01-12 00:24:00 · 3959 阅读 · 5 评论 -
消息cache,我真得需要你吗(2)?
本来写blog的时候并没有想到会有多少人看到,所以,只是把所想的写下来。后来,发现有很多热心的人给我的问题提了很多意见,心里很是感激。想想同仁的意见如果可以帮我改进JTangMQ的设计,那真得是求之不得的事情,亦或是我写的东西对其他人也有参考价值,那是我的莫大荣幸了。那就继续把所想的写下来吧。 上篇提到,消息cache引出的两个问题令人十分头痛,它的的确确影响着JTan原创 2006-01-15 00:31:00 · 2314 阅读 · 2 评论 -
流量控制器+消息cache实现高性能稳定的MQ服务器
本来想把MQ的消息cache改造过程详细写写,由于到年关了,项目要验收了,时间紧得很,只好把新的想法写下来,原来的改造想法就先搁着吧,等有空了再说(估计是不会有空的了)。 消息cache对MQ性能的影响是不必说了,肯定是导致MQ性能下降的一个重大原因。既然不能抛弃它,那就好好利用它。如果能在资源宽裕的情况下不使用消息cache,保持MQ的性能;而只有在资源吃紧的情况下原创 2006-01-17 23:55:00 · 4914 阅读 · 4 评论