UCMQ FAQ 和 展望

本文主要收录了UCMQ开源后，各位网友提到的一些共性问题。此外，很多网友对UCMQ抱有更多的期望。在此，统一记录一下，既希望能解决大家的疑问，也希望有支持者与我共同完善大家的好点子。

---

1. 消息队列简介及应用场景相关

消息队列（Message Queue）：将消息按照产生的次序插入队列，而后由其他的处理程序、模块将其从队列中取出，并对消息加以处理，从而形成一个基本的消息队列。使用消息队列可以很好地将任务以异步的方式进行处理，或者进行数据传送和存储等。例如，当你频繁地向数据库中插入数据、频繁地向搜索引擎提交数据，就可采取消息队列来实现异步插入。另外，还可以将较慢、较复杂、有并发数量限制的处理逻辑，通过消息队列放在后台处理。

常见使用场景：短信服务、电子邮件服务、图片处理服务、好友动态推送服务等。

2. 协议相关

使用HTTP协议主要考虑了跨语言、跨平台和易接入。个人觉得UCMQ的性能不需要太过担忧，大家可以看相关测试数据：http://tech.uc.cn/?p=1344（测试场景：UCMQ只部署一个UCMQ实例），由于UCMQ是一个单进程单线程的轻量级服务，如果实在对性能有极高要求可以部署多个实例。

3. 周边方案对比

UCMQ比起其它消息组件的长处和短处是什么？

• 与其他消息队列相比，
  • 延续了：
    • 协议通用性好
    • 性能高
    • 支持较大并发
  • 扩展了：
    • 易用性
    • 数据安全性高
    • 内存消耗小（数据缓存随读写位置移动）
    • 易搬迁（每个队列数据独立）
    • 易维护（轻量级）
    • 监控简单（可实时获取“所有/单独”队列状态信息）
    • 添加了特色的队列服务（延时队列/队列写锁等）

4. 使用相关

1. 单个UCMQ无法满足性能要求怎么办？

   • 如果单个实例已经到达性能瓶颈，建议部署多个实例，客户端已实现负载均衡机制（轮询或随机）。

2. 一般消息队列里储存的数据格式是json吗？

   • 消息队列中的数据可以是任意格式，对于业务来说json是个不错的选择。消费者模块可以处理完后即时再去读取队列中的新消息，如果队列取空后服务端会返回特殊的标识，消费者模块通过识别该标识休眠读取线程，建议使用定期休眠机制（如：100ms）。

3. 任务分发策略，有订阅功能吗？

   • UCMQ不支持订阅功能，业务不分发。相对于gearman，UCMQ没有同步操作（即：生产者将消息写入队列后，队列将触发消费者来读取消息），在UCMQ中读写队列都是由客户端（包括：生产者和消费者）主动发起的，所以不是由消息队列分发。

4. 发生异常时的处理流程是怎样？

   • 如果消息生产者成功的将消息写入队列后，该消息一直在队列中有效，直到被消费者成功读取或者消息体被损坏。取出后的消息将不可再访问。

5. UCMQ是怎么减少IO消耗提高读写性能的？

   • 读写位置的数据都是缓存在内存中的，并随读写位置移动而移动。

6. 如果不手工清理的情况下，数据量级变大后，会不会对系统产生性能的影响？数据是如何进行清理的？

   • 后台数据存储是分文件存储的，已读完的数据文件将被清理，所以不会消耗存储资源。从存储设计（http://tech.uc.cn/?p=1344）可以看到，UCMQ只缓存当前读和写的数据文件，性能不会随着数据量增大而下降的。

5. 后期需求

1. 支持推拉，新增订阅功能
2. 增加安全校验，如：支持token/用户检测
3. 支持主备冗余/容灾
4. 使用libev + http_parse 替代libevent