- 产品简介
- 购买指南
- 快速入门
- 操作指南
- 实践教程
- 消息队列（Queue）模型
- 消息主题（Topic）模型
- 迁移说明
- 案例分享
- API 文档
- SDK 文档
- 服务等级协议
- 词汇表
- 产品简介
- 购买指南
- 快速入门
- 操作指南
- 实践教程
- 消息队列（Queue）模型
- 消息主题（Topic）模型
- 迁移说明
- 案例分享
- API 文档
- SDK 文档
- 服务等级协议
- 词汇表
阅文集团旗下的起点文学网，使用 CMQ 满足了3个核心需求：
1、『仗义书财』的运营系统，里面抢红包月票的功能，消费者入账的时候是异步的。入账信息会先写到 MQ 里。 消费者过来拉，且消费者确认已成功消费后，回调接口把 MQ 里的信息删掉。
2、另一个场景是，起点文学网的各大系统，包括运维、告警、运营系统的日志流水，会先聚合到 CMQ 中，后端的大数据分析集群，会按处理能力，不断到 CMQ 中拉去，分析。CMQ 理论上支持的消息堆积数量无上限，使用无后顾之忧。
3、提供类似于 Kafka 的消息回溯能力。当业务成功消费，并删除消息后，使用消息回溯，可重新消费已删除的消息。可指定 offset 的位置进行调整。这便于起点文学网，做账单的对账、业务系统重试等。
起点文学的整体业务对 CMQ 的压力，API 请求的 QPS 超过10万，全天请求量超10亿次，客户担忧如此大的业务压力，CMQ 是否能稳定支持？
CMQ 后端的集群对用户来说是透明无感知的，CMQ controller server 可根据集群的负载情况实时对queue进行调度搬迁。如果某个queue的请求量超过当前集群的服务阈值，controller server 可以将 queue 路由分布到多个集群上来提高并发量，理论上可以达到无限的消息堆积以及超高的QPS。
是
否
本页内容是否解决了您的问题？