关于JMS系统设计的几点建议

回答一个老外同事关于JMS系统设计的几点建议，抄录如下，下图为其应用场景，消息流量1000条每秒

 

 

 

1.       Separate jms queues bese on function ( or systems) and volume requirement and message size, especially on volume requirement and size if you have concern on this.

1)      for different function, create different jms queue, to avoid impact on each other when message blocked.

2)      Separate jms queues will make possible to change target to jms server in future, which can avoid I/O bottleneck.

3)      Separate big message size and small message size function into different queue, even into different jms server, to avoid small size message blocked by big size message from I/O perspective.

This point only apply for high volume function, because you should balance not only on the performance&volume, but also on overall system complexity, over design on jms also make maintain some difficult, for those function with low volume, sharing same queue is acceptable:

 

2.       Group queues and bind to separate JMS server, based on message volume: because in wls, all queues in same JMS server will sharing the same persist store (jdbc/file), to avoid I/O bottleneck on persist store, you need consider separate high volume queues into different jms server. (this point can be tuned when you found I/O bottleneck on persist store, not required at beginning.)

 

3.       High performance jms system, means the messages come into queue, should must be consumed/received as quick as possible, so enough consumer threads will  be very critical, if no enough consumer, message will be blocked in queue, and jms server will be very slow when the number of messages goes up.

 

4.       Normally, when message picked up by consumer(in you case should be esb), consumer will do processing on the message, and during this period, will can not pick up message from queue, so the processing performance in backend is very critical, you must ensure processing in esb side quickly enough first, or the bottleneck should be at esb side, no matter how well design for jms, overall system still poor performance. So from my experience, you should also put more focus on performance for esb, jms design should not be the critical issue.