【Alibaba中间件技术系列】「RocketMQ技术专题」小白专区之领略一下RocketMQ基础之最！

应一些小伙伴们的私信，希望可以介绍一下RocketMQ的基础，那么我们现在就从0开始，进入RocketMQ的基础学习及概念介绍，为学习和使用RocketMQ打好基础！

RocketMQ是一款快速地、可靠地、分布式、容易使用的消息中间件，由Alibaba开发，其前身是 Metaq，Metaq 可以看成是linkedin的Kafka（scala）的java版本，并对其增加了事务的支持。

RocketMQ为Metaq3.0，相比于原始kafka，其擅长点出了原始的 log collecting之外，还增加诸如HA、事务等特性，使得从功能上可以替代传统大部分 MQ。

可靠的FIFO和严格的消息顺序
Pub/Sub 和 P2P 消息模型
单队列容纳百万消息的能力
拉（Pull）和推（push）队列
各种消息协议，如 JMS，MQTT 等
分布式集群，支持容错
Docker images for isolated testing and cloud Isolated clusters
丰富的配置和监控功能的管理

Topic 是一个主题。一个系统中，我们可以将消息划成 Topic ，这样，将不同的消息发送到不同的 queue。

一个topic下，我们可以设置多个queue，每个queue就是我们平时所说的消息队列；
因为queue是完全从属于某个特定的topic的，所以当我们要发送消息时，总是要指定该消息所属的topic是什么。
通过equeue就能知道该topic下有几个queue了，但是到底发送到哪个queue呢？比如topic下有4个queue，那对于这个topic下的消息，发送时，到底该发送到哪个queue呢？
目前，equeue的做法是在发送一个消息时，需要用户指定这个消息对应的topic以及一个用来路由的一个object类型的参数。
equeue会根据topic得到所有的queue，然后根据该object参数通过hash code然后取模queue的个数最后得到要发送的queue的编号，从而知道该发送到哪个queue。
这个路由消息的过程是在发送消息的这一方做的，也就是下面要说的producer。之所以不在消息服务器上做是因为这样可以让用户自己决定该如何路由消息，具有更大的灵活性。

消息队列的生产者。我们知道，消息队列的本质就是实现了publish-subscribe的模式，即生产者-消费者模式。生产者生产消息，消费者消费消息。所以这里的Producer就是用来生产和发送消息的。

消息队列的消费者，一个消息可以有多个消费者。

消费者分组，这可能对大家来说是一个新概念。之所以要搞出一个消费者分组， 是为了实现下面要说的集群消费。一个消费者分组中包含了一些消费者，如果这些消费者是要集群消费，那这些消费者会平均消费该分组中的消息。

equeue中的broker负责消息的中转，即接收producer发送过来的消息，然后持久化消息到磁盘，然后接收consumer发送过来的拉取消息的请求，然后根据请求拉取相应的消息给consumer。
所以，broker可以理解为消息队列服务器，提供消息的接收、存储、拉取服务。
broker对于equeue来说是核心，它绝对不能挂，一旦挂了，那producer，consumer就无法实现publish-subscribe了。
使用CPU资源来换取网卡流量资源；
FilterServer与Broker部署在同一台机器，数据通过本地回环通信，不走网卡；
一台Broker部署多个FilterServer，充分利用CPU资源，因为单个JVM难以全面利用高配的物理机CPU资源；
因为过滤代码使用Java编写，应用几乎可以做任意形式的服务器端消息过滤，例如通过Messgae Header进行过滤，甚至可以按照Message Body进行过滤；
使用Java语言进行作为过滤表达式是一个双刃剑，方便了应用的过滤操作，但是带来了服务器端的安全风险。需要应用来保证过滤代码安全，例如在过滤程序中尽可能不做申请大内存，创建线程等操作，避免Broker服务器发生资源泄露。
SEND_OK:消息发送成功；
FLUSH_DISK_TIMEOUT:消息发送成功，但是服务器刷盘超时，消息已经进入服务器队列，只有此时服务器宕机，消息才会丢失；
FLUSH_SLAVE_TIMEOUT：消息发送成功，但是服务器同步到slave时超时，消息已经进入服务器队列，只有此次服务器宕机，消息才会丢失；
SLAVE_NOT_AVAILABLE:消息发送成功，但是此时slave不可用，消息已经进入服务器队列，只有此时服务器宕机，消息才会丢失；

集群消费是指，一个consumer group下的consumer，平均消费topic下的queue。

假如一个topic下有4个queue，然后当前有一个consumer group，该分组下有4个consumer，那每个consumer就被分配到该topic下的一个queue，这样就达到了平均消费topic下的queue的目的。
如果consumer group下只有两个consumer，那每个consumer就消费2个queue。
如果有3个consumer，则第一个消费2个queue，后面两个每个消费一个queue，从而达到尽量平均消费。

应该尽量让consumer group下的consumer的数目和topic的queue的数目一致或成倍数关系。这样每个consumer消费的queue的数量总是一样的，这样每个consumer服务器的压力才会差不多。当前前提是这个topic下的每个queue里的消息的数量总是差不多多的。这点我们可以对消息根据某个用户自己定义的key来进行hash路由来保证。

广播消费是指一个consumer只要订阅了某个topic的消息，那它就会收到该topic下的所有queue里的消息，而不管这个consumer的group是什么。所以对于广播消费来说，consumer group没什么实际意义。consumer可以在实例化时，我们可以指定是集群消费还是广播消费。

对于集群消费和广播消费，消费进度持久化的地方是不同的，集群消费的消费进度是放在broker，也就是消息队列服务器上的，而广播消费的消费进度是存储在consumer本地磁盘上的。

*由于一个queue的消费者可能会更换，因为consumer group下的consumer数量可能会增加或减少，然后就会重新计算每个consumer该消费的queue是哪些，所以，当出现一个queue的consumer变动的时候，新的consumer如何知道该从哪里开始消费这个queue呢？

如果这个queue的消费进度是存储在前一个consumer服务器上的，那就很难拿到这个消费进度了，因为有可能那个服务器已经挂了，或者下架了，都有可能。而因为broker对于所有的consumer总是在服务的，所以，在集群消费的情况下，被订阅的topic的queue的消费位置是存储在broker上的，存储的时候按照不同的consumer group做隔离，以确保不同的consumer group下的consumer的消费进度互补影响。