关于消息队列这种设计模式的利弊

 ［作者：jinsong    转贴自：www.umlchina.com    点击数：3616    更新时间：2004-8-26    文章录入：admin］ 编写过windows程序的人应该都知道消息队列，尽管design pattens里没有消息队列这种设计模式，不过我觉得这还是一种模式。现在我在写一个服务器程序，服务器要挂多个模块，我在犹豫模块间的通讯用消息队列是否最好，所以把这个问题拿来，请高手们讨论。　　优点：　　1、这时一种最简单的把并行访问变成串行访问的办法，减少了许多在并行访问中要考虑的资源共享问题。　　2、程序扩充功能相对容易，只需修改消息处理函数即可　　3、程序结构清晰、对外接口统一　　4、消息的异步响应提高了系统性能　　缺点：　　1、难以对访问权限进行控制，任何外部程序都可以通过发出消息来执行这个模块的方法　　2、把调用方法转换为发送消息，就无法判断参数的有效性，例如服务程序已修改了消息格式，客户端是　无法在编译时发现这个错误的。　　3、消息机制难以得到返回结果　　4、消息机制是不可靠的，不能保证发出的消息一定会被处理。可能在发出消息后，服务程序出现故障或停止了，这是可能会丢弃消息队列中的消息。　　　　服务器的各个模块中用消息队列来通讯是要严格区分，不可都用。例如，如果有多个工作线程来并发执行多个任务，这时用消息对列来分发任务，可以取得很不错的效果；如果这个模块是提供公用的功能，被频繁调用，并且要等着结果才继续，就不应用消息队列了，直接用函数的方式。当然，如果你的模块都是外部程序，那你没有办法，只好用IPC通讯了（不一定用消息队列，其他也可以，如socket, pipe, 共享内存....)。　　如果你要用消息队列，我建议你自己写一个，开销会小很多，也不会和windows的混在一起，你想，如果他界面不响应了，你的服务程序怎么办？　　1、如果在消息参数中加上发送者标识或类似的信息，是否可以控制访问权限呢？　　2、编译时确实不能知道服务程序修改了消息格式，但我觉得这不重要。　　3、消息可以是同步的，类似Windows中的SendMessage，这时可以返回结果。如果用异步消息，就比较复杂了。　　4、如果规定消息被处理时要给客户端一个确认，那么客户端得不到确认或结果为失败时，可以判断出消息未被处理，这和调用方法得到失败的返回值差不多。　　另外，是否采用消息通讯恐怕要考虑服务程序的性能，如果服务程序能同时处理多个请求（如每个请求对应一个线程），则可以用方法调用，如果必须处理完一个请求才能处理下一个，则只能用消息了。