拿来就能用去哪儿网消息中间件QMQ详解
作者
去哪儿网QMQ团队
责编
伍杏玲
年，随着业务快速增长，公司内部开始了服务化进程，通过拆分单体服务加快开发部署效率，提高业务迭代速度。服务化情况下不同的服务分开部署，不同服务之间需要通过网络来通信。
当时公司内部选择使用Dubbo作为主要的RPC框架。但是RPC并不适用于所有通信场景，RPC主要表达同步的直接调用关系，但是实际上还有异步通知类型的通信需求。
分布式消息队列（MQ）是典型的异步通知类型的通信实现，有很多好处：
业务可以专注核心流程，通过消息解耦“通知类”业务，减少核心流程受影响的可能性。可以方便的实现最终一致性，提高服务可用性和吞吐能力。通过错峰和流控可以提高服务可靠性，降低下游系统对上游的影响力。QMQ就是Qunar内部实现的分布式消息队列。
实际上，在Qunar内部，QMQ的服务端实现有新老两个完全不同的版本。目前开源的是最新的版本，本文也会专注于介绍新版本的使用、设计和实现。
最初引入QMQ主要用于支付、订单等场景，对服务的可靠性、一致性要求比较高，但是当时并没有满足要求的可靠开源实现，所以公司内部自己造了QMQ这个轮子。根据当时考虑支持的主要业务场景，初版QMQ利用业务库实现了消息发送的可靠性和一致性，服务端存储则选择了MySQL+Redis。后来也基于MySQL开发了延时消息队列。
随着业务的发展和QMQ在公司内部的推广，QMQ支撑的业务种类越来越多，消息量越来越大。这种情况下，初版QMQ暴露了一些问题：
吞吐能力不足，逐渐不能满足公司内部的需求，和使用越来越多的Kafka相比差距很大。堆积能力弱，不能有效的实现错峰。推模型在消息堆积时会增加消费者的压力。这些问题迫使我们重新设计了QMQ的存储模型。此时直接基于本地顺序文件的Kafka和RocketMQ等已经成为业内广泛使用的方案，它们提供了非常好的写入和堆积能力，QMQ重新设计时也参考了他们的存储模型。
但根据公司内部的实际使用场景，我们单独设计了消费管理的模型，这点会在后面详细说明。
基本概念
首先，我们介绍一些使用时需要知道的基本概念。
producer表示消息生产者，consumer表示消息消费者，broker一般用来表示QMQ的服务端。
subject表示消息的主题，可以理解为消息的分类，每条消息发送时都需要指定一个主题，消费者订阅消息时也需要指定需要订阅的主题。
consumergroup表示消费者所在的消费组。在QMQ中，所有的消费者都属于一个消费组，消费组内共享消费进度，不同消费组之间的消费进度相互独立。消费时一条消息一般情况下只会派发给消费组中的一个消费者。
比如一个消费组中有10个消费者，那么这10个消费者就会均分主题的消息，而不是每个消费者都消费全部消息。实际业务场景里，也有单个消费者需要消费一个主题全部消息的情况，这种消费方式在QMQ中称为广播消费，广播消费时每个消费者都属于一个单独的消费组。
发送消息
发送消息时首先需要创建一个producer，创建时需要提供两个参数，一个是标识当前项目的AppCode，另一个是QMQmetaserver的地址。
MessageProducerProviderproducer=newMessageProducerProvider();producer.setAppCode(yourapp);producer.setMetaServer(
