我的ActiveMQ帖子.docVIP

探讨构建基于AMQ的消息服务中间件两种设计思路 ActiveMQ是人人皆知的开源消息中间件，提供了P2P和Pub/Sub两种模式。 本文主要探讨在AMQ中基于P2P模式的多进程通信两种设计思路，暂时不考虑Pub/Sub模式 1. 基于AMQ P2P模式的双队列方式(2进程通信) 在简单的情况下使用P2P模式，两个进程基于2个Queue就可以完成进程间的通信，示意图如下： 图-1 在上图中P1、P2是两个进程，Queue_P1和Queue_P2是两队列，P1是Queue_P2的Producer是Queue_P1的Consumer，P2是Queue_P1的Producer是Queue_P2的Consumer。 P1、P2进程的相关配置如下表: P1 P2 PROCESS_NAME=P1 TARGET_PROCESS_NAME=P2 PROCESS_NAME=P2 TARGET_PROCESS_NAME=P1 PROCESS_NAME属性是当前进程的标识，TARGET_PROCESS_NAME是通信对方的进程标识，各进程启动时根据这两个标识会创建两个Destination: 根据PROCESS_NAME属性值创建一个队列，并创建该队列的Consumer,监听队列 根据TARGET_PROCESS_NAME属性值创建一个队列，并创建该队列的Producer 这样一来，每个进程都有了自己的队列，然后监听自己的队列，可以收到对方给自己发来的消息,因此P1和P2可以实现双向的通信 在实际的应用中，会把创建Producer 和创建Consumer的操作封装在一个单独的组件中，以组件的方式对外提供，如果分布式应用中的单个进程应用了该组件，那么每个进程就可以创建一个通信节点，这个通信节点基于队列可以与别的进行通信 上面的这种情况其实是基于AMQ的2个进程通信的最简单的应用，也是个典型的P2P模式应用。 然而上面只是一些非常简单的情况，面对比较复杂的分布式应用，上面的这种方式将难以应对，例如，系统中5个进程，彼此都需要通信，那么这5个进程启动后都要创建一个用于自己消费的队列，自己是这个队列的Consumer.如下图所示： 图2 但是在每个进程中如果给要给别的进程发消息，则必须创建一个与其他进程的Queue对应的producer,根据上面的例子，每个进程都要创建4个这样的Producer，这才5个进程互相通信，在实际的分布式应用中，会有更多进程互通消息的需要，如果这种思路进行设计，则每个进程要创建更多的Producer，显然这样的设计是有很大缺陷的。 2. 基于AMQ P2P模式的消息路由方式通信(多进程通信) 无论如何变换，在AMQ中说到底都离不开Queue和P2P，因此还是把注意力放在第一种模式上，对这种模式经改造，可以使得在分布式应用中每个进程只创建一个Producer和一个Consumer。很自然的想到一点，那就是现实中的有线电话，每个用户都有一跟电话线连接到电话交换局，任何两个用户都可以通话，由电话交换局完成话路的接通和摘除。因此需要建立一个消息服务中心MSC(Message service center)，每个进程都连接到消息服务中心，发送消息时发送到消息服务中，由消息服务中心根据消息中的目的地把消息转发给相应的进程，这可以称作是最简单消息的智能路由。如下图所示： 图3 现在看来MSC将成为通信枢纽，如果在消息很多的情况下，每个进程都给其他的进程发消息，其实对MSC的压力还是比较大的，因此考虑采用多个MSC,并且MSC创建一个公共队列QUEUE_MSC并成为其Consumer，各个通信的进程都是这个QUEUE_MSC的Producer,然后各个进程都创建一个自己监听的消息队列，成为其Consumer, MSC是各个进程的Producer,示意图如下: 图4 QUEUE_MSC是个公共的队列，MSC1和MSC2进程中的MessageListener会监听该队列， 测试证明MSC1和MSC2会非常均匀的负担QUEUE_MSC队列中的消息处理，从而自然的完成负载均衡，根据需要还可以增加MSC。 下面看看如何实现消息的智能路由功能，MSC担当消息路由器的功能，但是一个消息具体下一个目的地是哪个进程还是由消息本身决定，因此需要在消息中定义发送消息的原进程信息和接受消息的目的进行信息，在这里我们仅用纯文本格式的消息来举例，比如我定义下面的消息: Src:P1,dest:P3,负载字段暂略 当P1进程把这个消息发送到QUEUE_MSC队列时，MSC收到此消息后，解析出dest字段内容，然后把这个消息发送给P3进程。因为有解析和转发的过程，因此会损耗少许的传输性能，但是设计本来就是权衡的过程，只是看如何权衡罢了 对于分布式应用中的各个进程只