在介绍该项目前我还是照例跟大家叨叨几句，希望大家看到的是有血有肉的“开源小生”(才开源第一个小项目就如此自封，见笑了)。其实该项目计划开源到现在已经有比较长的一段时间了，由于种种原因未能如期与大家相见。生活中每件事大家都憧憬有一个美好的第一次，然而也多数第一次都很拙劣。希望这个项目能由拙劣的开端一步步走向美好。今天起该项目正式对外开放源码，大家本着保护新手的心态请轻喷。

   项目地址：https://github.com/ucweb/ucmq

   使用指南：http://ucweb.github.io/ucmq_guide/

   —————————————-  正文  —————————————-

   简介：

   UCMQ是一款轻量的HTTP协议级消息队列服务组件，项目的最初原型来自“张宴”的HTTPSQS(http://blog.s135.com/httpsqs/)。

   基本特性：

• 支持标准的HTTP协议( GET/POST方法)，支持长连接(keep-alive)；

• 请求响应非常快速，入队列、出队列速度超过10000次/秒；

• 每个UCMQ实例支持多队列，队列通过操作接口自动创建；

• 单个队列默认限制存储100w未读消息，可以不限制(非必要建议限制)；

• 可以在不停止服务的情况下便捷地修改单个队列的属性(大小限制/只读锁/延时队列/同步频率)；

• 可以实时查看队列属性(入队列数量、出队列数量、未读消息数量、消息积压数量)。

• 每个队列有独立的数据文件易管理易搬迁。

   

   常见部署：

   UCMQ逻辑架构中通常会涉及到三个角色：生产者(producer)/异步消息队列(UCMQ)/消费者(consumer)，而三者间都以http协议作为通讯方式，如下图：

   

【UCMQ部署逻辑架构图】

   【说明】 在整个部署架构中“生产者”和“消费者”都被视为UCMQ的客户端。“生产者”和“消费者”通过设定的负载均衡机制访问UCMQ服务端。每个客户端(生产者/消费者)均可注册一个或多个服务端(在客户端配置文件添加每个UCMQ服务端监听地址)，如果注册多个则可以“业务容灾”和“负载均衡”。

   内部结构：

   

【UCMQ内部结构图】

    【说明】

   控制模块：负责UCMQ内部流程的控制；

   主从复制模块：将数据变更使用binlog方式同步到备机实现容灾(本版本暂不实现)；

   http协议处理模块：http处理模块负责http协议的解析和封装；

   libevent网络事件驱动模块：负责异步事件的接收和分发；

   MQ队列管理模块：管理所有队列的rtag信息和队列使用状态信息；

   数据存储模块：负责消息持久化(当前数据文件mmap到缓存，所以持久化由系统 辅助完成)，清理垃圾数据文件(一个队列中可有多个文件)；负责准确和完整的存/取队列的rtag信息。

   存储设计：

   由于HTTP_SQS项目是基于TC存储数据，众所周知TC的数据文件是从头开始map到缓存的，由于数据量的扩大不能被缓存的数据将很大程度上影响服务的性能和稳定性。所以UCMQ摒弃了TC，使用日志文件方式存储消息，数据缓存被顺序读取至内存中，且缓存区域随读写指针移动，这样既节省了内存使用也保证了性能。设计原理如图：

   

【UCMQ存储设计图】

   性能测试环境：

部署模块	CPU	内存	硬盘	网卡
客户端	16 * 2.40GHz	24G	3 * 270GB SATA	Intel(R) PRO/1000 (1000)
服务端	16 * 2.40GHz	24G	3 * 270GB SATA	Intel(R) PRO/1000 (1000)

   测试工具：

软件	IP地址	服务端口	安装目录	备注
ab	192.xxx.xxx.xxx	N/A	$HOME/local/ucmq/test

   性能测试(长连接)：

   

   

【UCMQ长连接性能测试图】

   【说明】

   同时读写：既启动多个客户端，部分做写入操作部分做读取操作，同时向服务端发送请求，读写分别计数。

   只读/只写：既启动多个客户端，但客户端只做读取或写入操作，服务端只接受读/写一类请求。

   长连接：客户端处理完请求后不主动断开连接。

   性能测试(短连接)

   

【UCMQ短连接性能测试图】

   【说明】

   同时读写：既启动多个客户端，部分做写入操作部分做读取操作，同时向服务端发送请求，读写分别计数。

   只读/只写：既启动多个客户端，但客户端只做读取或写入操作，服务端只接受读/写一类请求。