RocketMQ 介绍

基础介绍

RocketMO是由阿里捐赠给Apache的一款低延迟、高并发、高可用、高可靠的分布式消息中间件，经历了淘宝双十一的洗礼。

RocketMO可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。

官方文档： https://rocketmg.apache.org/docs/quick-start/

github中文主页： https://github.com/apache/rocketmg/tree/master/docs/cn

核心概念

• Topic：

  消息主题，一级消息类型，生产者向其发送消息；

• Message：

  生产者向Topic发送并最终传送给消费者的数据消息的载体；

• 消息属性：

  生产者可以为消息定义的属性，包含Message Key和Tag；

• Message Key：

  消息的业务标识，由消息生产者 (Producer) 设置，唯一标识某个业务逻辑；

• Message ID：

  消息的全局唯一标识，由消息队列RocketMQ系统自动生成，唯一标识某条消息；

• Tag：

  消息标签，二级消息类型，用来进一步区分某个Topic下的消息分类；

• Producer：

  也称为消息发布者，负责生产并发送消息至Topic；

• Consumer：

  也称为消息订阅者，负责从Topic接收并消费消息；

• 分区：

  即Topic Partition，物理上的概念。每个Topic包含一个或多个分区；

• 消费位点：

  每个Topic会有多个分区，每个分区会统计当前消息的总条数，这个称为最大位点MaxOfset，分区的起始位置对应的位置叫做起始位点MinOffset；

• Group：

  一类生产者或消费者，这类生产者或消费者通常生产或消费同一类消息，且消息发布或订阅的逻辑一致；

• GroupID：

  Group的标识；

• 队列：

  个Topic下会由一到多个队列来存储消息；

• Exactly0nce投递语义：

  Exaty-0nce投递语义是指发送到消息系统的消息只能被(onsumer处理目仅处一次，即使Producer重过消息发送导致某消息重复投递，该消息在Consumer也,只被消费一次；

• 集群消费：

  一个Group D所标识的所有onsumer平均分摊消费消息。例Topi有9条消息，一个roup lD有3个Consumer实例，那么在集群消费模式下每个实例平均分摊，只消费其中的3条消息；

• 广播消费：

  一个Group lD所标识的所有(onsumer都会各自消费某条消息一次，例女某Topi有9条消息，一个Group lD有3个onsumer实例，那么在广播消费模式下每个实例都会各自消费9条消息；

• 定时消息：

  Producer将消息发送到消息队列RocketMO服务端，但并不期望这条消息立马投递，而是推迟到在当前时间点之后的某一个时间投递到Consumel进行消费，该消息即定时消息。

• 延时消息：

  Producer将消息发送到消息队列RocketMO服务端，但并不期望这条消息立马投递，而是延一定时间后才投到Consumer进行消费，该消息即延时消息。[

• 事务消息：

  RocketMQ提供类似X/0pen XA的分布事务功能，通过消息队列RocketMQ的事务消息能达到分布式事务的最终一致。顺序消息: RocketMQ提供的一种按照顺序进行发布和消费的消息类型，分为全局顺序消息和分区顺序消息。

• 全局顺序消息：

  对于指定的一个Tpic，所有消息按照严格的先入先出(FIFO) 的顺进行发布和消费

• 分区顺序消息：

  对于指定的一个Topl，所有消息根据Sharding ke进行区块分区，一个分区内的消息按照严格的FIFO顺序进行发布和消费，Sharding Key是顺序消息中用来区分不同分区的关键字段，和普通消息的Message Key是完全不同的概念。

• 消息堆积：

  Producer已经将消息发送到消息队列RocketMQ的服务端，但由于Consumer消费能力有限，未能在短时间内将所有消息正确消费掉，此时在消息队列RocketMQ的服务端保存着未被消费的消息，该状态即消息堆积。 消息过(onsumer可以根消息标签Tag) 对消息进行过滤，确onsumer最终只接收被过后的消息类型，消息过流在消息队列RoketMQ的服务端完成。

• 消息轨迹：

  在一条消息从Producer发出到(onsumer消费处理过程中，由各个相关节点的时间、地点等汇聚而成的完整推路信息。通过消息轨迹，您能清附定位消息从Producer发出，经由消息队列RocketMO服务端，投递给Consumer的完数鞋路，方便定位排查问题

• 重置消费位点：

  以时间纳为坐标，在消息持久化存储的时间范围内(默认3天)，重新设置(onsumer对订阅的TODC的消费进度，设置完成后(nsumer将接收设定时间点之后由Producer发送到消息队列RocketMO服务端的消息。

• 死信队列：

  死信队列用于处理无法被正常消费的消息，当一条消息初次消费失败，消息队列RocketMQ会自动进行消息重试;达到最大重试次数后，若消费依然失败，则表Consumer在正常情况下无法正确地消费该消息，此时，消息队列oketM0不会立刻将消息丢弃，而是将这条消息发关到该onsumer对应的特殊队列中。 消息队列RocketMQ将这种常况下无法被消费的消息称为死信消息Dead-Letter Message) ，将存储死信消息的特殊队列称为死信队列(Dead-LeteiQueue)

应用场景

• 削峰填谷：

  诸如秒杀、抢红包、企业开门红等大型活动时皆会带来较高的流量脉冲，或因没做相应的保护而导致系统超负荷其至脂溃，或因限制大过导致请术大量失败而影响用户体验，消息队列RocketMQ可提供削峰填谷的服务来解决该问题。

• 异步解耦：

  易系统作为淘宝和天猫主站最核心的系统，每笔交易订单款据的产生会起几百个下游业务系统的关注，包括物流、购物车、积分、流计算分析等等，整体业务系统庞大而且复杂，消息队列RocketMQ可实现异步通信和应用解耦，确保主站业务的连续性。顺序收发:细数日常中需要保证顺序的应用场景非常多，例如证券交易过程时间优先原则，交易系统中的订单创建、支付、退款等流程，航班中的旅客登机消息处理等等。与先进先出FIFO (First n First Out) 原理类仪，消息队列RoketMO提供的顺序消息即保证消息FIFO。分布式事务一致性:交易系统、支付红包等场景需要确保教据的最终一致性，大景引入消息队列RocketMO分布式事务，既可以实现系统之间的解钱，又以保证最终的数据一致性。

• 大数据分析：

  数据在“流动“中产生价值，传统教据分析大多是基于批量计算模型，而无法做到实时的数据分析，用阿里云消息队列ROCKetMO与流式计宣了警相结合，可以很方便的实现业务数据的实时分析。

• 分布式缓存同步：

  天猫双11大促，各个分会场琳琅满目的商品需要实时感知价格变化，大量并发访问数据库导致会场页面响应时间长，集中式缓存因带宽瓶颈，限制了商品变更的访问流量，通过消息队列RocketMQ构建分布式缓存，实时通知商品数据的变化。

架构设计