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集群中只要有一台机器不可用，则整个集群都不可用，服务可用性大大降低。
如果服务器部署为同步双写模式，此缺陷可通过备机自动切换为主来解决，不过仍然会有几分钟的服务不可用。（依赖同步双写，主备自动切换，自动切换功能目前并未实现）
网友评论