RocketMQ 基础

RcoketMQ 是一个队列模型的消息中间件，具有高性能、高可靠、可伸缩、高实时、分布式特点。

RocketMQ特点

• 支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型

• 在一个队列中可靠的先进先出（FIFO）和严格的顺序传递

• 支持拉（pull）和推（push）消息模式

• 单一队列百万消息的堆积能力

• 分布式高可用的部署架构，满足至少一次消息传递语义

• 提供配置、指标和监控等功能丰富的Dashboard

• 强调集群无单点，可扩展，任意一点高可用，水平可扩展

• 支持上万个队列，顺序消息

• 定制消息过滤
  rocketmq提供了两种类型的消息过滤，也可以说三种：通过topic、tag进行消息过滤、通过filter的方式任意定制过滤

• 消息的可靠性（无Buffer，持久化，容错，回溯消费）
  消息无buffer就不用担心buffer会满的情况，rocketmq的所有消息都是持久化的，生产者本身可以进行错误重试，发送者也会按照时间阶梯的方式进行消息重发，消息回溯说的是可以按照指定的时间进行消息的重新消费，既可以向前也可以向后（要注意消息的擦除时间）

• 海量消息堆积能力，消息堆积后，写入低延迟
  针对于provider需要配合部署方式，对于consumer，如果是集群方式，一旦master发现消息堆积会向consumer下发重定向指令，此时consumer就可以从slave进行数据消费。

• 分布式事务
  个人感觉rocketmq3.2.6对这一块说的不是很清晰，而且官方也说现在这块存在缺陷（会令系统pagecache过多），所以线上建议还是少用为好，这块我也是后面给大家看一下列子

• 消息失败重试机制
  针对provider的重试，自动选择其他的broker进行重发，默认重试三次，重试次数内要在消息发送的超时时间范围内。
  针对consumer的重试，自动加入到重试队列，一般情况如果是因为网络等问题连续重试也是照样失败，所以rocketmq采用阶梯重试的方式。

• 定时消费， 针对message设置setDelayTimeLevel。

• Master/Slave，broker的name相同，brokerid=0的为主，大于0的为从。

• producer、consumer队列都可以分布式。

• producer向队列轮流发送消息，队列集合称为Topic。

• 实时的消息订阅机制

• 在集群消费模式下，offset会同步持久化到broker，分摊消费消息。在广播模式下，offset会持久化到本地文件，独自消费所有消息。

Offset

RocketMQ中，有很多offset的概念。但通常只关心暴露到客户端的offset。一般，就是指逻辑Message Queue下面的offset。

Consumer Offset

用于标记Consumer Group在一条逻辑Message Queue上，消息消费到哪里了。注：从源码上看，这个数值是最新消费的那条消息的offset+1，所以实际上存储的是【下次拉取的话，从哪里开始拉取的offset】。
消费者拉取消息的时候需要指定offset，broker不主动推送消息，而是接收到请求的时候把存储的对应offset的消息返回给客户端。这个offset在成功消费后会更新到内存，并定时持久化。在集群消费模式下，会同步持久化到broker。在广播模式下，会持久化到本地文件。
实例重启的时候会获取持久化的consumer offset，用以决定从哪里开始消费。

集群消费

消费者的一种消费模式。Consumer Group中的各Consumer实例分摊消费消息，即一条消息只会投递到一个Consumer Group下面的一个实例。
而由Producer发送消息的时候是轮询所有的Q，所以消息会平均散落在不同的Q上，可以认为Q上的消息是平均的。那么实例也就平均地消费消息了。
这种模式下，消费进度会持久化到Broker。

广播消费

消费者的一种消费模式。消息将对一个Consumer Group下的各个Consumer实例都投递一遍。
这种模式下，消费进度会持久化到实例本地。

顺序消息

消费消息的顺序要同发送消息的顺序一致。由于Consumer消费消息的时候是针对Message Queue顺序拉取并开始消费，且一条Message Queue只会给一个消费者（集群模式下），所以能够保证同一个消费者实例对于Q上消息的消费是顺序地开始消费（不一定顺序消费完成，因为消费可能并行）。
在RocketMQ中，顺序消费主要指的是Queue级别的局部顺序。这一类消息为满足顺序性，Producer必须单线程顺序发送，且发送到同一个队列，这样Consumer就可以按照Producer发送的顺序去消费消息。
生产者发送的时候可以用MessageQueueSelector为某一批消息（通常是有相同的唯一标示id）选择同一个Queue，则这批消息的消费将是顺序消息（并由同一个consumer完成消息）。或者Message Queue的数量只有1，但这样消费的实例只能有一个，多出来的实例都会空跑。

普通顺序消息

顺序消息的一种，正常情况下可以保证完全的顺序消息，但是一旦发生异常，Broker宕机或重启，由于队列总数发生发化，消费者会触发负载均衡，而默认地负载均衡算法采取哈希取模平均，这样负载均衡分配到定位的队列会发化，使得队列可能分配到别的实例上，则会短暂地出现消息顺序不一致。

严格顺序消息

顺序消息的一种，无论正常异常情况都能保证顺序，但是牺牲了分布式 Failover 特性，即 Broker集群中只要有一台机器不可用，则整个集群都不可用，服务可用性大大降低。
如果服务器部署为同步双写模式，此缺陷可通过备机自动切换为主来解决，不过仍然会有几分钟的服务不可用。（依赖同步双写，主备自动切换，自动切换功能目前并未实现）