无锡建设机械网站,怎么才能做电商,wordpress通知邮件美化,衡阳电商网站建设文章目录 什么是 RocketMQ#xff0c;有哪些使用场景#xff1f;RocketMQ 由哪些⻆色组成#xff0c;每个⻆色作用和特点是什么#xff1f;RocketMQ 中的 Topic 和 JMS 的 queue 有什么区别#xff1f;RocketMQ 消费模式有几种#xff1f;RocketMQ 的 Consumer 是如何消费… 文章目录 什么是 RocketMQ有哪些使用场景RocketMQ 由哪些⻆色组成每个⻆色作用和特点是什么RocketMQ 中的 Topic 和 JMS 的 queue 有什么区别RocketMQ 消费模式有几种RocketMQ 的 Consumer 是如何消费消息的Broker 如何处理拉取请求的RocketMQ 如何做负载均衡消息重复消费RocketMQ 如何保证消息不丢失高吞吐量下如何优化生产者和消费者的性能?RocketMQ的集群架构是怎样的RocketMQ 的 Broker 有哪几种集群模式RocketMQ消息积压会发生什么问题如何避免RocketMQ 延迟消息是如何实现的RocketMQ 如何处理大量的消息有哪些优化措施RocketMQ的消息存储如何进行清理和归档RocketMQ 的消息是如何进行存储的RocketMQ 的事务消息是如何实现的有什么用途RocketMQ 如何保证消息顺序RocketMQ 的广播消息和集群消息有什么区别RocketMQ 提供了哪些消息过滤的机制RocketMQ 的 Producer 是如何发送消息的 什么是 RocketMQ有哪些使用场景 RocketMQ是阿里开源的一款非常优秀的中间件产品后捐赠给Apache基金会作为一款孵化技术仅仅经历了一年多的时间就成为Apache基金会的顶级项目。RocketMQ是一款分布式、队列模型的消息中间件支持分布式事务天然的支持集群模型、负载均衡、水平扩展能力亿级别的消息堆积能力。 RocketMQ的使用场景包括 异步通信RocketMQ 可以在不同的应用程序之间进行异步通信从而提高系统的可伸缩性和响应速度。同时减少多个模块之间的依赖性使整个系统更加灵活并易于维护。应用解耦通过RocketMQ作为中介生产方与消费方通过消息进行交互减少多个模块之间的依赖性使整个系统更加灵活并易于维护。削峰填谷RocketMQ 可以用于平滑处理流量峰值将请求缓冲并逐渐处理以防止系统过载。例如在大型活动如秒杀、抢红包、企业开门红等中通过RocketMQ的削峰填谷能力平稳流量峰值避免系统压力过大。保证消息顺序适用于需要保证多条消息处理顺序的场景例如证券交易过程、订单创建、支付、退款等流程。事件驱动架构RocketMQ 适用于构建事件驱动的架构以便快速响应事件和状态变化。日志收集统一收集业务日志供分析系统进行数据分析消息队列作为日志数据的中转站。并且RocketMQ 的流式计算框架非常适合与大数据框架集成如 Apache Hadoop 和 Flink 等用于构建实时数据流处理。 总之RocketMQ是一个功能强大的消息中间件适用于各种分布式应用程序和场景特别是那些需要高性能、低延迟和可靠性的应用。 RocketMQ 由哪些⻆色组成每个⻆色作用和特点是什么
⻆色作用Nameserver无状态动态列表这是和 ZooKeeper 的重要区别之一。ZooKeeper 是有状态的。Producer消息生产者负责发消息到 Broker。Broker就是 MQ 本身负责收发消息、持久化消息等。Consumer消息消费者负责从 Broker 上拉取消息进行消费消费完进行 ack。
RocketMQ 中的 Topic 和 JMS 的 queue 有什么区别 queue 就是来源于数据结构的 FIFO 队列。而 Topic 是个抽象的概念每个 Topic 底层对 应 N 个 queue而数据也真实存在 queue 上的。 RocketMQ 消费模式有几种 消费模型由 Consumer 决定消费维度为 Topic。 集群消费 一条消息只会被同 Group 中的一个 Consumer 消费多个 Group 同时消费一个 Topic 时每个 Group 都会有一个 Consumer 消费到数据。 广播消费 消息将对一个 Consumer Group 下的各个 Consumer 实例都消费一遍。即即使这些Consumer 属于同一个Consumer Group消息也会被 Consumer Group 中的每个 Consumer 都消费一次。 RocketMQ 的 Consumer 是如何消费消息的 RocketMQ的Consumer消费消息的方式有两种Push方式和Pull方式。 在 Push 推模式下RocketMQ 的 Broker 会主动将消息推送给对应的 Consumer。而 Consumer 会注册一个 MessageListener 回调函数并在接收到消息后立即触发回调函数。在 Pull 拉模式下Consumer 需要主动向 Broker 定期发送拉取消息的请求自行完成处理消息以及向 Broker 返回 ack 信息等步骤。 这两种模式都有各自的优缺点适合不同的业务场景。其中 Push 模式的优点是实现比较简单客户端只要注册回调方法专心处理业务就可以了。并且消息到达 Broker 后立即会被推送到 Consumer消息处理比较及时。缺点也比较明显消费者需要与 Broker保持长时间的连接对网络要求比较高。Push 模式的有点是Consumer 有更大的控制权可以根据自身处理能力来调整拉取消息的频率避免消息积压。并且拉模式只需要在拉取消息时与 Broker 保持短暂的网络连接比较适合那些网络连接不是很稳定的环境。而对应的缺点则是Pull 模式下Consumer 需要自行调整消息拉取的频率处理消息就没有 Push 模式那么及时。另外Push 模式下Consumer 的实现相对比较复杂容易产生消息积压。 不论是Push方式还是Pull方式从Broker获取消息后Consumer都会进行消费处理。RocketMQ还提供了多种消费策略如集群消费、广播消费、并行消费和顺序消费等以满足不同的业务需求。 Broker 如何处理拉取请求的 Consumer 首次请求 Broker。 Broker 中是否有符合条件的消息有 响应 Consumer。等待下次 Consumer 的请求。 没有 DefaultMessageStore#ReputMessageService#run 方法。 - PullRequestHoldService 来 Hold 连接每个 5s 执行一次检查pullRequestTable 有没有消息有的话立即推送。每隔 1ms 检查 commitLog 中是否有新消息有的话写入到pullRequestTable。当有新消息的时候返回请求。挂起 consumer 的请求即不断开连接也不返回数据。使用 consumer 的 offset。 RocketMQ 如何做负载均衡 通过 Topic 在多 Broker 中分布式存储实现。 producer 端 发送端指定 message queue 发送消息到相应的 broker来达到写入时的负载均衡 提升写入吞吐量当多个 producer 同时向一个 broker 写入数据的时候性能会下降 - 消息分布在多 broker中为负载消费做准备 默认策略是随机选择 producer 维护一个 index每次取节点会自增index 向所有 broker 个数取余自带容错策略 其他实现 SelectMessageQueueByHashhash 的是传入的 argsSelectMessageQueueByRandomSelectMessageQueueByMachineRoom 没有实现 也可以自定义实现 MessageQueueSelector 接口中的 select 方法 MESSAGEQUEUE SELECT(FINAL LISTMESSAGEQUEUE MQS, FINAL MESSAGE MSG, FINAL OBJECT ARG); consumer 端 采用的是平均分配算法来进行负载均衡。 其他负载均衡算法 平均分配策略(默认)(AllocateMessageQueueAveragely) 、环形分配策略(AllocateMessageQueueAveragelyByCircle) 、手动配置分配策略(AllocateMessageQueueByConfig) 、机房分配策略 (AllocateMessageQueueByMachineRoom)、一致性哈希分配策略 (AllocateMessageQueueConsistentHash)、靠近机房策略 (AllocateMachineRoomNearby) 追问当消费负载均衡 consumer 和 queue 不对等的时候会发生什么 Consumer 和 queue 会优先平均分配如果 Consumer 少于 queue 的个数则会存在部分Consumer 消费多个queue 的情况如果 Consumer 等于 queue 的个数那就是一 个 Consumer 消费一个 queue如果 Consumer个数大于 queue 的个数那么会有部分 Consumer 空余出来白白的浪费了。 消息重复消费 影响消息正常发送和消费的重要原因是网络的不确定性。 引起重复消费的原因 ACK 正常情况下在 consumer 真正消费完消息后应该发送 ack通知 broker 该消息 已正常消费从 queue 中剔除。 当 ack 因为网络原因无法发送到 brokerbroker 会认为词条消息没有被消费 此后会开启消息重投机制把消息再次投递到 consumer消费模式 在 CLUSTERING模式下消息在 broker 中会保证相同 group 的 consumer 消 费一次但是针对不同 group 的consumer 会推送多次 解决方案 数据库表 处理消息前使用消息主键在表中带有约束的字段中 insertMap 单机时可以使用 map ConcurrentHashMap - putIfAbsent guava cache - Redis 分布式锁搞起来。 RocketMQ 如何保证消息不丢失 首先在如下三个部分都可能会出现丢失消息的情况 Producer 端Broker 端Consumer 端 Producer 端如何保证消息不丢失 采取 send()同步发消息发送结果是同步感知的。发送失败后可以重试设置重试次数。默认 3 次。PRODUCER.SETRETRYTIMESWHENSENDFAILED(10); 集群部署比如发送失败了的原因可能是当前 Broker 宕机了重试的时候会发送到其他 Broker 上。 Broker 端如何保证消息不丢失 修改刷盘策略为同步刷盘。默认情况下是异步刷盘的将刷盘方式(FlushDiskType)配置为 Sync 同步刷盘保证消息尽快写入到磁盘中防止 Broker 出现故障造成内存中没有及时刷如到硬盘的那一部分消息丢失。集群部署主从模式高可用。为了防止 Broker 端硬盘出现故障造成消息丢失给 Broker 配置一个或多个 Slave 从节点进行消息冗余。同时将消息同步方式配置为 Sync 同步同步。 Consumer 端如何保证消息不丢失 完全消费正常后在进行手动 ack 确认。 高吞吐量下如何优化生产者和消费者的性能?
开发 同一 group 下多机部署并行消费 - 单个 Consumer 提高消费线程个数 - 批量消费消息批量拉取业务逻辑批量处理 运维 网卡调优jvm 调优多线程与 cpu 调优 - Page Cache RocketMQ的集群架构是怎样的 RocketMQ的集群架构包括四个主要角色Name Server集群、Broker主从集群、Producer和Consumer客户端。 Name Server集群是RocketMQ的一种轻量级的服务节点负责注册和管理Broker的服务地址提供服务的注册和发现功能。每个Broker节点都要跟所有的Name Server节点建立长连接定义注册Topic路由信息和发送心跳。每个 NameServer 节点都会保存完整的 Broker 列表数据并且 NameServer 个个节点之间不会同步数据。因此NameServer 集群不会因为单个节点发生故障而停止服务。Broker 是 RocketMQ 的核心组件负责存储和传输消息。一个 RocketMQ 集群通常包含多个 Broker 实例共同协作来提高 RocketMQ 的可用性和吞吐量。其中Master Broker主节点负责处理客户端的请求并将消息存储到磁盘上然后将消息同步复制给所有的从节点。而从节点是Master Broker 的消息备份。客户端包含 Producer 生产者和 Consumer 消费者。其中Producer 负责将消息发送给 Broker。Producer 可以将消息发送到指定的 TopicRocketMQ 会负责将消息存放到对应的 Broker 上。Consumer 可以订阅一个或多个 Topic并从对应的 Broker 上接收消息进行处理。RocketMQ 的客户端提供了多种处理消息的方式比如延迟消息、事务消息、集群消息、广播消息等。 RocketMQ 的 Broker 有哪几种集群模式 RocketMQ的Broker有三种集群模式 单Master模式只有一个Master节点其他都是Slave节点。Master节点负责响应客户端的请求并存储消息Slave节点只同步Master节点的消息也会响应部分客户端的读请求。这种模式的优点是简单易部署但是存在单点故障的问题如果Master节点宕机会导致整个服务不可用。Master-Slave模式经典双集群部署一个Master节点对应多个Slave节点Master和Slave都是独立的NameServer。Master节点负责响应客户端请求并存储消息Slave节点只同步Master节点的消息也会响应部分客户端的读请求。这种模式的优点是高可用性即使Master节点宕机Slave节点可以自动升级为Master节点继续提供服务。但是如果只有一个Master节点存在单点故障的问题。Dledger模式高可用集群部署在Master-Slave模式的基础上增加了Raft协议实现了自动脑裂后的数据高可靠性。即使某个节点从网络上掉下来或者宕机后仍然能够保证所有的消息不会丢失。这种模式的优点是高可用性和高可靠性即使某个节点出现故障也能保证服务的可用性。 总的来说单Master模式适合测试和开发环境Master-Slave模式适合生产环境而Dledger模式适合需要高可靠性的生产环境。 RocketMQ消息积压会发生什么问题如何避免 在RocketMQ中如果未消费的消息过多会给集群带来非常多的问题 消息堆积消息在Broker端不断堆积可能会导致Broker的存储压力过大影响整个系统的性能和稳定性。死信队列RocketMQ中的Broker会在一定时间内无法被消费的消息转换到死信队列中。如果消息持续堆积死信队列的空间有限一些消息可能会被丢弃导致数据丢失。消息延迟和积压如果消息持续堆积可能会导致消息的延迟增大进一步影响系统的响应速度和处理能力。消息丢失RocketMQ 会定期删除过期的日志文件。在删除时RocketMQ并不会关注过期文件中的消息是否被消费者处理。这就会造成过期日志文件中未被 Consumer 消费的消息丢失。 为了避免这些问题可以采取以下措施 控制消息发送速度Producer可以根据Consumer的处理能力动态地控制消息的发送速度。例如可以通过监控Consumer的处理情况调整发送速度避免消息堆积。增加Consumer可以增加更多的Consumer来提高消息的消费能力。通过增加Consumer的数量可以并行处理消息提高系统的吞吐量。及时处理死信队列可以在Broker端配置死信队列对无法正常被消费的消息进行捕获和处理。这样即使消息被丢弃也可以通过死信队列进行恢复和处理。合理配置Broker和Producer/Consumer的参数可以通过调整Broker和Producer/Consumer的配置参数如缓存大小、请求超时等来优化系统的性能和稳定性。 综合来说合理的配置和监控是避免生产者速率超过消费者速率的关键。根据实际业务需求和资源配置可以选择适当的措施来优化消息的处理以确保消息队列系统的稳定和高性能。 RocketMQ 延迟消息是如何实现的 RocketMQ的延迟消息实现是通过在消息发送时设置一个延迟级别然后消息会被存储到DelayMessageService中等待达到指定的延迟时间后再被重新推送到Broker的commitLog服务中。 具体流程如下 Producer 将消息投递到Broker的commitLog服务。commitLog服务判断消息是否为延迟消息如果是则将实际的topic和queueId保存到消息的属性中并将topic设置成延迟topicSCHEDULE_TOPIC_XXXXqueueId对应的延迟级别和消息投递时间保存在tagCode中。消息延迟服务DelayMessageService从SCHEDULE_TOPIC_XXXX主题循环拉取消息。DelayMessageService根据tagCode找到对应的延迟队列并按照延迟级别进行排序。当达到指定的延迟时间后DelayMessageService会将消息重新推送到commitLog服务。commitLog服务将消息推到Producer 指定的目标 Topic 中。Consumer从 目标 Topic 中拉取消息。 RocketMQ支持最多18个延迟级别可以满足不同延迟时间的需求。 另外在新版本的 RocketMQ 中使用时间轮机制提供了指定任意时间的延迟消息功能。 RocketMQ 如何处理大量的消息有哪些优化措施 RocketMQ可以通过以下优化措施来处理大量的消息 增加Broker数量增加Broker数量可以使得消息在消费端的负载均衡更加灵活同时可以提高系统的容错性和可用性。消息生产者的异步发送 消息生产者可以使用异步发送方式以降低发送消息的延迟提高发送吞吐量。异步发送允许生产者在等待确认之前继续发送更多的消息。使用批量发送和批量消费 RocketMQ 支持批量发送消息和批量消费消息。批量操作可以减少网络开销和提高处理效率特别是在高吞吐量的场景下。使用批量发送和批量消费可以显著减少网络负载和提高性能。合理设置消费者数量增加消费者数量可以显著提升消费者处理消息的并发能力。但是消费者数量不能超过对应 Topic 中的 MessageQueue 数量。另外增加消费者的工作线程数也能一定程度上提升消费者的处理性能。优化JVM参数通过调整JVM参数可以使得系统更加稳定减少因为垃圾回收导致的性能下降。使用硬件加速可以通过使用SSD等更快的存储设备来提高I/O性能从而加快消息的处理速度。 总之处理大量消息需要综合考虑多个因素包括集群配置、性能优化、顺序消息处理、分区等。通过合理的配置和优化可以实现高吞吐量和高性能的消息处理。同时要根据业务需求和负载情况不断进行性能监测和调整以保持系统的稳定性和可伸缩性。 RocketMQ的消息存储如何进行清理和归档 RocketMQ 提供了消息存储清理和归档的机制以便管理消息存储空间删除过期消息并将历史消息归档到其他存储介质中。这些功能有助于维护消息队列的性能和可用性。以下是关于 RocketMQ 消息存储清理和归档的主要方面 消息文件删除策略 RocketMQ 支持多种消息文件删除策略可以在配置文件中进行设置。以下是一些常见的策略 定时删除策略 您可以配置 RocketMQ 定期删除过期的消息文件和索引文件。这样一旦消息文件中的消息过期RocketMQ 将自动删除它们。空间满策略 如果存储磁盘空间达到一定限制RocketMQ 可以自动删除最早的消息文件以释放磁盘空间。这个策略确保了存储空间不会无限制地增长。指定时间段删除策略 您可以配置 RocketMQ 只删除特定时间段内的消息文件以保留历史消息。 消息归档 RocketMQ 允许您将历史消息归档到其他存储介质中以减小消息服务器的存储负担。归档通常涉及将消息转移到长期存储如云存储或本地归档系统中。归档可以手动触发也可以自动触发具体取决于您的需求。历史消息访问 尽管消息被归档RocketMQ 仍然提供了访问历史消息的机制。通过合适的归档系统或者存储介质您可以检索和访问历史消息以满足合规性要求或其他业务需求。 需要注意的是清理和归档消息不是 RocketMQ 的核心功能而是辅助功能。您需要根据自己的需求和业务场景来配置和管理消息的清理和归档策略。确保配置合理的清理策略以防止存储空间耗尽并根据业务需求进行消息的归档操作以保留历史消息数据。同时归档后的消息可以根据需要进行合适的检索和恢复以满足特定的数据需求。 RocketMQ 的消息是如何进行存储的 RocketMQ是采用分布式存储的方式来存储消息的。每个Broker的存储结构主要包括CommitLog、ConsumeQueue和IndexFile。 CommitLog是消息存储的物理文件存储了所有消息的主题、标签、时间戳等基本信息和消息体。每个Broker上的CommitLog被当前机器上的所有ConsumeQueue共享。ConsumeQueue是消息的逻辑队列存储了具有相同属性如Topic、队列ID等的消息。每个Broker上有多个ConsumeQueue每个Topic的消息都对应一个ConsumeQueue。Consu meQueue采用顺序写入、随机读取的方式存储消息同时支持高效的预写日志和刷盘策略。IndexFile是消息索引文件存储了消息在CommitLog中的偏移量和消息物理偏移量对应关系采用Hash索引方式加速定位。 RocketMQ通过这种分布式存储方式可以高效地存储和访问大量消息同时也具有良好的可扩展性和可靠性。 RocketMQ 的事务消息是如何实现的有什么用途 RocketMQ的事务消息是通过两阶段提交Two-phase Commit协议实现的。具体实现步骤如下 发送方将半事务消息发送至RocketMQ服务端由于消息为半事务消息在未收到生产者对该消息的二次确认前此消息被标记成“暂不能投递”状态不会被消费。发送方开始执行本地事务逻辑。可能是一系列的数据库更新、文件写入等操作他们要么全部成功要么全部回滚。发送方根据本地事务执行结果向服务端提交二次确认Commit 或是 Rollback服务端收到 Commit 状态则将半事务消息标记为可投递订阅方最终将收到该消息服务端收到 Rollback 状态则删除半事务消息订阅方将不会接受该消息。如果二次确认时发送方的本地事务没有执行完成则可以向服务端返回 Unknown 状态服务端收到 Unknown 状态则会等一段时间后重新向发送放发起状态确认。如果发送方多次返回 Unknown 状态服务端则会直接丢弃这一条消息。 RocketMQ 的事务消息机制是为了解决分布式事务问题而设计的它适用于需要确保一系列操作的一致性的场景如订单支付、库存扣减、资金结算等。主要的用途有 分布式事务 事务消息用于支持分布式系统中的分布式事务。它可以确保涉及多个操作的事务要么全部成功要么全部失败以维护数据的一致性。典型的应用包括订单支付、库存扣减、资金结算等。消息可靠性 事务消息与普通消息一样具有消息的可靠性传递特性。一旦事务消息被成功发送到 RocketMQ 服务器它将被存储和传递不会丢失。Exactly Once 语义 RocketMQ 事务消息提供了Exactly Once语义确保消息要么完全提交要么完全回滚不会出现部分提交或回滚的情况。 使用事务消息您可以更好地处理这些复杂的业务流程确保数据的完整性和一致性。但请注意事务消息也需要谨慎使用因为它可能会引入一些复杂性并影响系统的性能和可伸缩性。 RocketMQ 如何保证消息顺序 RocketMQ 提供了顺序消息机制用来保证一组消息的局部有序性具体实现步骤如下 Producer 在发送消息时通过设置一个 MessageQueueSelector 方法将一组有顺序的消息依次发送到对应 Topic 下的同一个 MessageQueue 上。而 MessageQueue 是能够保证 FIFO 先进先出的这样就可以保证一组有顺序的消息在 Broker 上是有序的。Consumer 在配置 MessageListener 时需要指定为 MessageListenerOrderly 实现类。这样就能保证一组有序的消息可以按照发送时的顺序进入 Consumer 进行处理从而保证这一组消息的顺序。 但是在使用顺序消息时有几个需要注意的问题 RocketMQ 的顺序消息机制只保证一组消息的局部有序性而并不保证所有消息的全局有序性。应用需要自行定义消息中的一些标识符来确定消息的顺序。顺序消息机制会给 MessageQueue 添加线程锁这会降低 Consumer 的消息吞吐量。如果 Consumer 消费消息出现错误会将整个 MessageQueue 阻塞而无法单独重试这一条消息。这样非常容易导致 Topic产生大量的消息积压因此使用顺序消息要尽量保证 Consumer 的消息处理正确性。 RocketMQ 的广播消息和集群消息有什么区别 广播消息和集群消息是 RocketMQ 的两种不同的消息消费模式。其中 广播模式意味着一条消息会被发送到所有订阅了这个主题 Topic 的消费者而所有消费者都会收到相同的消息副本。集群模式意味着一条消息只会分发给订阅了这个主题 Topic 的同一个消费者组中的一个消费者处理。每个消费者组只会处理一次消息。 他们的区别主要提现在实现方式以及适用场景上。 集群模式在 Broker 端统一管理每个消费者组的消费进度对消费进度的管理是严格的。这样每次消费者服务启动后都可以从上一次消费的进度开始开始进行消费。 而广播模式是交由每个消费者自行管理消费进度消费进度的管理是不严格的容易产生丢失。当消费者服务启动后如果本地的消费进度丢失了就只能消费到启动之后的消息而无法从上一次消费的进度开始消费。因此广播模式对于消息的连续性保证是不强的。集群模式适用于大多数常规对消息安全敏感的业务场景例如订单处理、库存管理等。多个消费者协同工作可以提高消息的处理能力并实现消息的负载均衡。而广播模式适用于一些对消息安全不太敏感的特殊业务场景。例如日记记录、时间通知等。这些场景下所有的消费者都需要处理相同的消息。 RocketMQ 提供了哪些消息过滤的机制 RocketMQ消息过滤分为两种基于表达式的过滤和基于类模式的过滤。 基于表达式的过滤有两种模式TAG模式和SQL92模式。其中RocketMQ 允许为每一条消息设置一个 Tag 标签。 TAG 模式下Consumer 可以选择订阅特定的 TAG对消息进行过滤。TAG模式根据消息的属性进行过滤适合于简单的场景SQL92模式可以支持更复杂的逻辑可以使用SQL92的语法进行过滤。这种过滤方式由于是在 ConsumeQueue 文件中直接进行过滤所以性能比较高。SQL92 模式下Consumer 可以通过设定一个满足 SQL92 标准的 SQL 语句定制相对比较复杂的过滤逻辑例如数值比较等。同时也可以引用消息中添加的其他自定义属性定制多维度的过滤条件组合。 基于类模式的过滤是使用用户自定义的过滤器类来实现消息过滤。消费者可以在消息监听器中编写自定义逻辑来实现更复杂的消息过滤机制。在这种模式下消费者可以完全控制消息的过滤逻辑适用于需要导读定制和特殊处理的场景。但是同样对Consumer 的编码能力要求更高。 RocketMQ 在进行消息过滤时都会将消息过滤的逻辑上推到 Broker 端执行。这样可以减少不必要的网络数据传递。但是同时也会给 Broker 增加业务复杂性。因此客户端需要根据不同的业务场景选择合适的过滤机制。 RocketMQ 的 Producer 是如何发送消息的 RocketMQ的Producer有三种消息发送模式RocketMQ允许在不同的场景下使用不同的消息发送模式以满足不同的业务需求。 同步发送Sync Send这是默认的发送模式。在同步发送模式下发送者发送一条消息后会等待 Broker 的响应直到 Broker 确认收到消息并返回结果。如果发送失败将会抛出异常。这种模式下Producer 可以确保消息成功发送到了 Broker消息安全性更高。但是由于需要等待 Broker 的响应可能会引起较大的发送消息延迟。异步发送Async Send这种模式下Producer发送消息后不会等待Broker的响应而是继续执行后续操作。Producer可以注册回调函数在消息发送完成后Broker会异步调用回调函数。这种模式可以提高 Producer 的吞吐量和响应速度但是Producer 需要在回调函数中自行处理 Broker 的消息响应对客户端代码要求较高。并且在这种模式下如果消息发送出现问题Producer 只能通过回调函数处理这样 Producer 处理消息错误的时机是有延迟的。单向发送Oneway Send这种模式下Producer 发送消息后不关心消息是否被 Broker 成功接收和存储也不等待 Broker 的响应。这样Producer 发送消息的效率是最高的。但是消息的安全性就无法保证。这种模式通常适用于那些强调消息吞吐量而不关心消息可靠性的场景例如日志消息。
