深入理解RocketMQ--基础知识
1.简介
RocketMQ是具有低延迟、高并发、高可用、高可靠的分布式消息中间件，可为分布式应用系统提供异步解耦和削峰填谷的能力。
2.核心概念
- nameserver：主要管理Broker、路由信息
- 管理Broker，接受来自Broker集群发送的注册，以及提供心跳机制来检查Broker是否还存活。
管理路由信息，每一个NameServer都存储有路由信息和队列信息，提供给Producer和Consumer查询
- broker:主要负责消息的存储和传递，消息查询
存储消息、consumer的消费偏移量、consumer的订阅关系、Topic信息
Topic的创建和更新消息通过broker转发到nameserver
- Topic:消息主题，一级消息类型，通过Topic对消息进行分类。更多信息，请参见Topic与Tag最佳实践。
- 消息（Message）:消息队列中信息传递的载体。
- Message ID:消息的全局唯一标识，由消息队列RocketMQ版系统自动生成，唯一标识某条消息。
- Message Key:消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。
- Tag:消息标签，二级消息类型，用来进一步区分某个Topic下的消息分类。更多信息，请参见Topic与Tag最佳实践。
- Producer:消息生产者，也称为消息发布者，负责生产并发送消息。
- Consumer:消息消费者，也称为消息订阅者，负责接收并消费消息。可分为两类：
Push Consumer：消息由消息队列RocketMQ版推送至Consumer。
Pull Consumer：该类Consumer主动从消息队列RocketMQ版拉取消息。
- 分区：即Topic Partition，物理上的概念。每个Topic包含一个或多个分区。
- 消费位点（消费策略）：即从哪个位置(First_Offset、Last_Offset)开始消费。
- Group：一类Producer或Consumer，这类Producer或Consumer通常生产或消费同一类消息，且消息发布或订阅的逻辑一致。
- Group ID：Group的标识。
- 队列：每个Topic下会由一到多个队列来存储消息。每个Topic对应队列数与消息类型以及实例所处地域（Region）相关。
- 集群消费：一个Group ID所标识的所有Consumer平均分摊消费消息。例如某个Topic有9条消息，一个Group ID有3个Consumer实例，那么在集群消费模式下每个实例平均分摊，只消费其中的3条消息。更多信息，请参见集群消费和广播消费。
- 广播消费：一个Group ID所标识的所有Consumer都会各自消费某条消息一次。例如某个Topic有9条消息，一个Group ID有3个Consumer实例，那么在广播消费模式下每个实例都会各自消费9条消息。更多信息，请参见集群消费和广播消费。
- 事务消息：消息队列RocketMQ版提供类似X/Open XA的分布事务功能，通过消息队列RocketMQ版的事务消息能达到分布式事务的最终一致。更多信息，请参见事务消息。
- 顺序消息：消息队列RocketMQ版提供的一种按照顺序进行发布和消费的消息类型，分为全局顺序消息和分区顺序消息。更多信息，请参见顺序消息。
- 全局顺序消息：对于指定的一个Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。更多信息，请参见顺序消息。
- 消息过滤：Consumer可以根据消息标签（Tag）对消息进行过滤，确保Consumer最终只接收被过滤后的消息类型。消息过滤在消息队列RocketMQ版的服务端完成。更多信息，请参见消息过滤。
3.消息类型
RocketMQ主要分为四种消息类型
注意：收发消息时，四种消息类型所对应的Topic不能混用。比如，创建的普通消息的Topic只能用于收发普通消息，不能用于收发其他类型的消息；同理，事务消息的Topic也只能收发事务消息，不能用于收发其他类型的消息，以此类推。
4.高级特性
（1）消息重试
i）顺序消息的重试
对于顺序消息，当消费者消费消息失败后，消息队列RocketMQ版会自动不断地进行消息重试（每次间隔时间为1秒），这时，应用会出现消息消费被阻塞的情况。因此，建议您使用顺序消息时，务必保证应用能够及时监控并处理消费失败的情况，避免阻塞现象的发生。
ii) 无序消息的重试
对于无序消息（普通、定时、延时、事务消息），当消费者消费消息失败时，您可以通过设置返回状态达到消息重试的结果。
无序消息的重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。
配置方式
注意： 一条消息无论重试多少次，这些重试消息的Message ID不会改变。
（2）消费过滤
Tag，即消息标签，用于对某个Topic下的消息进行分类。消息队列RocketMQ版的生产者在发送消息时，已经指定消息的Tag，消费者需根据已经指定的Tag来进行订阅。
场景示例
以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息，以以下消息为例：
- 订单消息
- 支付消息
- 物流消息
这些消息会发送到Trade_TopicTopic中，被各个不同的系统所订阅，以以下系统为例：
- 支付系统：只需订阅支付消息。
- 物流系统：只需订阅物流消息。
- 交易成功率分析系统：需订阅订单和支付消息。
- 实时计算系统：需要订阅所有和交易相关的消息。
（3）集群消费和广播消费
消息队列RocketMQ版是基于发布或订阅模型的消息系统。消费者，即消息的订阅方订阅关注的Topic，以获取并消费消息。由于消费者应用一般是分布式系统，以集群方式部署，因此消息队列RocketMQ版约定以下概念：
- 集群：使用相同Group ID的消费者属于同一个集群。同一个集群下的消费者消费逻辑必须完全一致（包括Tag的使用）。更多信息，请参见订阅关系一致。
- 集群消费：当使用集群消费模式时，消息队列RocketMQ版认为任意一条消息只需要被集群内的任意一个消费者处理即可。
- 广播消费：当使用广播消费模式时，消息队列RocketMQ版会将每条消息推送给集群内所有注册过的消费者，保证消息至少被每个消费者消费一次。
i）集群消费模式
适用场景
适用于消费端集群化部署，每条消息只需要被处理一次的场景。此外，由于消费进度在服务端维护，可靠性更高。具体消费示例如下图所示：
- 注意事项
- 集群消费模式下，每一条消息都只会被分发到一台机器上处理。如果需要被集群下的每一台机器都处理，请使用广播模式。
- 集群消费模式下，不保证每一次失败重投的消息路由到同一台机器上。
ii) 广播消费模式
适用场景
适用于消费端集群化部署，每条消息需要被集群下的每个消费者处理的场景。具体消费示例如下图所示：
注意事项
- 广播消费模式下不支持顺序消息。
- 广播消费模式下不支持重置消费位点。
- 每条消息都需要被相同订阅逻辑的多台机器处理。
- 消费进度在客户端维护，出现重复消费的概率稍大于集群模式。
- 广播模式下，消息队列RocketMQ版保证每条消息至少被每台客户端消费一次，但是并不会重投消费失败的消息，因此业务方需要关注消费失败的情况。
- 广播模式下，客户端每一次重启都会从最新消息消费。客户端在被停止期间发送至服务端的消息将会被自动跳过，请谨慎选择。
- 广播模式下，每条消息都会被大量的客户端重复处理，因此推荐尽可能使用集群模式。
- 广播模式下服务端不维护消费进度，所以消息队列RocketMQ版控制台不支持消息堆积查询、消息堆积报警和订阅关系查询功能。
(4) 批量消费
消息队列RocketMQ版接收到生产者发送地消息后，不需要分开一条一条的推送给消费者，可以先将消息进行缓存，等攒够指定数量的消息或等待指定的时长后统一将缓存的这些消息推送给消费者进行批量消费。
消息缓存的数量和等待时间分别由ConsumeMessageBatchMaxSize和BatchConsumeMaxAwaitDurationInSeconds参数控制，具体的配置方法，请参见Push方式的批量消费示例代码。
- ConsumeMessageBatchMaxSize：批量消费的最大消息数量，缓存的消息数量达到参数设置的值，消息队列RocketMQ版会将缓存的消息统一推送给消费者进行批量消费。
- BatchConsumeMaxAwaitDurationInSeconds：批量消费的最大等待时长，等待时长达到参数设置的值，消息队列RocketMQ版会将缓存的消息统一推送给消费者进行批量消费。
应用场景
若业务侧对消息吞吐量的要求优先于消息的实时性，建议使用批量消费功能。例如，给数据库中插入数据，每更新一条数据执行一次插入任务，如果数据更新较频繁，可能会对服务器造成较大压力。此时，您可以设置批量消费功能，例如，您可以设置为每10条数据批量插入一次或每5秒执行一次插入任务，降低系统运行压力。
忘是亡心i
清疚
￡神魔★判官ぃ
刺骨的言语ヽ痛彻心扉
àì夳堔傛蜴生んèń
小灰灰
还没有评论，来说两句吧...