360内部消息队列系统Qbus介绍

基础架构组 360云计算

女主宣言

做为每个互联网公司处理大数据的基础组件，诸如Kafka、rabbitMQ等一系列的消息队列系统越来越受到服务端程序猿的青睐，为了保持数据的持久性、可扩展性及高可用性，团队针对公司内部的现状以及业务特点，基于kafka深度定制了一款符合360内部特点的消息队列系统Qbus。今天小主就为大家奉上这篇关于消息队列的干货分享，希望能够帮助大家。
PS：丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！

Qbus简介

起源：

• LinkedIn用于日志处理的分布式消息队列kafka；
• 需要对用户行为（登录、浏览、点击、分享、喜欢）以及系统运行日志（CPU、内存、磁盘、网络、系统及进程状态）进行实时处理；
• 传统队列太重、性能也跟不上；

特点：

• 消息都是持久的，保存在磁盘；
• 高吞吐量；
• 客户端维护消费状态；
• 分布式，生产者、消费者、服务端都可分布式；
• 支持订阅；
• Push/pull方式；

消息收发
作为普通的消息系统来使用（同步、异步消息）
日志收集
收集业务日志进行实时分析，存储等
数据同步
使用订阅模式，同步数据到各个机房
监控服务
监控服务访问情况，防止用户对网站进行无限制的抓取数据
活动流跟踪等
Storm和Hadoop结合使用，在storm上消费数据，storm处理结果存储到QBus，数据可以异步复制一份到hadoop

与其它队列对比，相比gearman, JMS对比具有以下优势：

• 消息可持久化，不担心消息丢失；
• 分布式，服务器平滑扩展，业务无需感知；
• 无单点（多机房保证）；
• 支持订阅，一份消息，多份接收（支持跨机房结构，便于并行处理）；
• 高吞吐；
• 支持消息批量处理；
• 使用简单

Qbus原理介绍

原理图：

meta信息：

1. 集群broker的信息，包含其ip:port
2. topic的存储的位置
3. partition的消费位置信息
4. 所有consumer的信息
5. 当值的coordinator
6. agent配置和存活状态信息

一条消息从生产到消费的路径：

broker集群：

多个broker之间完全对等（可以平滑扩容）

Broker存储：

• 每个partition对应一个逻辑log，由多个segment组成
• 新的消息追加到最后一个segment文件末尾
• 消费者可以根据offset回溯到消息存在的位置重新进行消费

Broker高性能的关键：

• 利用文件系统缓存，用户空间不缓存消息
• zero-copy（比read-send方式节省60 - 70%时间）
• 端到端的批量压缩
• 顺序读写磁盘效率很高
• 不关心消息的状态（是否被消费，消费到哪等等）

性能：

支持php、C/C++、java版本SDK，性能与消息大小的趋势图如下：
（2.40GHz CPU单核环境，broker同机房）

代码编写 java：

Producer:（异步）

Consumer:（回调机制）

Producer:（同步、异步）

Consumer:（回调机制）

QBus相对于kafka的改进

1. 增加可靠传输请求类型，broker会对消息进行确认；
2. 增加agent节点，用于异步消息收集和日志收集；
3. 增加coordinator节点，独立消费分配逻辑，解决惊群效应，降低多语言开发成本；
4. 根据QBus系统设计改进php sdk，并重写C/C++、java SDK；
5. 增加消息自助管理平台，方便用户对消息进行管理；