应用消息队列应对大并发访问的解决方案

摘要：为了让使用此消息队列的开发人员了解此消息队列的接口以及结构，特编写此文档。

关键词：消息队列；设计

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）02-0412-03

在Web2.0的时代，高并发的情况越来越常见，从而使消息队列有成为居家必备的趋势，相应的也涌现出了很多实现方案，像Twitter以前就使用RabbitMQ实现消息队列服务，现在又转而使用Kestrel来实现消息队列服务，此外还有很多其他的选择，比如说：ActiveMQ，ZeroMQ等。上述消息队列的软件中，大多为了实现AMQP，STOMP，XMPP之类的协议，变得极其重量级，但在很多Web应用中的实际情况是：我们只是想找到一个缓解高并发请求的解决方案，不需要杂七杂八的功能，一个轻量级的消息队列实现方式才是我们真正需要的。因为redis本身实现了list，相关操作也可以保证是原子的，所以可以很自然的通过list来实现消息队列。队列的意义在于，分离了任务的产生和任务的执行。

2.2 内部结构

IFailure，失败信息处理接口；IHttpCallBack，Http方式回调接口；IMessageListener，

消息监听接口，提供消息监听方法； IMessageManager， 消息管理中心，提供对消息的各种操作方法；IMessageParser，消息解析器，提供消息到xml的转换，以及xml到消息的转换；IMessagePublisher，消息发布中心；IQueueManager，队列管理中心，提供对队列的各种操作方法；ISocketCallBack，Socket方式回调接口；ISubscriberManager，

订阅者管理中心，提供对订阅者的各种操作方法；ITopicManager，主题管理中心，提供对主题的各种操作方法；IXmlValidation，消息验证器，用以验证消息的完整性。

3 运行设计

运行控制：首先登录，登录完成后将转向主题列表页面。主题ID是提交消息时区分主题的，如果主题列表中没有需要的主题，可以点击主题进行注册，点击主题可以进入到订阅者列表页面。

主题注册完后会自动生成主题的ID，这个ID就是提交消息时需要的topicid。

订阅者注册：订阅者注册有个需要注意的地方就是采用http还是socket的回调方式，如果是http方式，系统将会将消息的xml格式以参数名xml 用post方式传递给订阅者。如何是socket的方式则会根据ip和端口号直接将消息的xml形式传递订阅者。订阅者需要返回一个消息是否接收成功的xml。

如果MSG为1，则表示消息已经发送成功，如果MSG不为1或者没有返回信息，系统则认为消息发送失败，此时系统将会将此消息重复发送直到成功，但不会超过五次。如果五次还不成功则放弃该消息的发送，写入日志。

队列注册：其中的ID就是消息提交时所需要的queueid。

4 系统数据结构设计

Redis下的key设计

Redis是key/value型数据库，发布订阅模式下消息和订阅者是以主题关联的，所以以主题id为主线来设计数据的存储结构。

点对点模式下就相对简单了，以队列id为主要的key就可以

5 系统出错处理设计

5.1 消息提交出错

消息提交出错将会给消息提交者返回一个xml格式的出错信息，格式如下：

其中MSG为返回信息的代码，方便判断。

[MSG＼&含义＼&1＼&成功＼&2＼&主题或队列不存在＼&3＼&Xml格式有误＼&4＼&队列中暂时没有消息＼&5＼&系统异常＼&]

MSG 为5的情况，是由于redis数据库出了问题，本系统将实时监控并自动重启redis。

5.2 消息发布出错

消息发布的时候如果没有得到订阅者的反馈，或者反馈的MSG不为1，则认为消息没有发布成功，系统将重复发送五次，再不成功将记入日志。