1背景消息队列作为发布订阅模型的消息中间件广泛应用于上下游业务集成场景。在实际业务场景中，同一个主题下的消息往往会被多个不同的下游业务方处理，各下游的处理逻辑不同，只需要关注自身逻辑需要的消息子集。所以在消息中心和消费者之间，需要有一种消息过滤功能，可以帮助消费者更高效地过滤自己需要的消息集合，避免大量无效消息投递给消费者，降低下游系统处理压力。ApacheRocketMQ很好的支持了这一能力，它解决了单个业务域即同一个主题内不同消息子集的过滤问题。2关于消息过滤2.1概念在消费者订阅了某个主题后，ApacheRocketMQ会将该主题中的所有消息投递给消费者。若消费者只需要关注部分消息，可通
1背景在互联网业务的实际应用场景中，消息的批量处理是非常必要的，因为我们时刻面临着大量数据的并发执行。例如，我们在一个业务交互的时候会有大量的分支行为需要异步去处理，但是这些动作又是在不同的业务粒度上的，所以我们需要多次调用MQ写入消息，可能有多次的连接和消息发送。这个写MySQL数据库是一样的，多次建连和写入，跟一次建连和批量数据库，性能是完全不能比的。所以我们需要有MQ有批量消息的能力来对我们的业务数据进行快速处理。2批量消息实现过程RocketMQ的批量消息，可以提高消息的吞吐能力和处理效率，降低下游系统的API调用频率，同时对消息服务的稳定性也有帮助。2.1批量消息的特点批量消息具有相
1背景在互联网业务的实际应用场景中，消息的延时处理是非常必要的。例如，在金融交易系统中，某些交易的确认可能需要一段时间才能完成。又如，在物流跟踪系统中，货物的运输状态需要一段时间才能更新。而MQ作为中间件的角色专门来处理消息媒介，实际也具备了使用消息的延时处理来保证信息的及时性的能力。这边举两个具体的例子：火车票订购，提交了订单就把车票给占位了，这时候可以发送一个延时确认的消息，15m未付款，就要把该车票释放，这样其他人就可以购买了。购买电影票，可以发送一个核销检查消息，在电影开场前15分钟就无法退票了。既然消息延迟处理的使用场景这么常见，那我们就要详细来分析下怎么使用MQ来实现，这边以Roc
1背景我们在前面两个章节中，介绍了消息组件如何保证可靠性传输和顺序行消费，参考上面系列的11、12章节。比如在消息生产阶段，如何保证消息发出的稳定性和可靠性；在消息服务器处理阶段，如何保证消息从生产到发送出去，经过网络传输，再到达Broker服务器并被接收的这整个阶段的可靠性，即如何使用ACK机制来保证消息传递的可靠性；还有就是消息消费的可靠性，Broker作为消息服务器，消息接收并持久化消息并消费的整个过程的可靠性如何保障。对于消息队列组件来说，这几个步骤出现问题，都有可能造成消息队列无法进行正常运行，消息堆积的情况发生。另外一种情况可能就是突发的流量峰值，这种一般发生在某种消费促销活动或者
1介绍消息的有序性在很多业务场景中占有很重要的位置。比如购物场景，需要按照创建订单-->订单付款-->完成订单顺序执行。又比如出行场景，接单-->接送到达目的地-->付款-->完成订单。这种是严格按照顺序执行的，这样的顺序消费才不会出问题，而且各个订单之间是互相独立和并行执行的。所以，在MQ中，如何稳定地保证顺序性消息处理，是一个不可避免的话题。2消息的有序性说明消息的有序执行，一般不是单个组件的能力。而是整个消息从生产，排队，存储到消费都是有序的，比如上面提到的购物和出行场景。这就要求我们在消息队列（如果是Kafka，还是RocketMQ、RabbitMQ）中，
1介绍这篇我们来说说MQ消息的可靠性传输。可靠性传输其实包含两种情况：一种是重复消费的情况，我们上一篇的幂等性消费解决的就是这个问题；另外一种是消息丢失的情况的，要确保我们生产的消息一定最终会得到消费。这时候就要从消息执行的几个阶段去保证，每一个阶段都不能出现问题。2消息生产阶段消息生产阶段指的是消息从生产到消息发送出去，经过网络传输，再到达Broker服务器并被接收的这整个阶段，我们需要一个健壮的确认机制（ACK）来保证消息传递的可靠性。如果说消息被接收到之后可以反馈给消息生产方去确认，那这个过程就比较完美了。消息创建和发送事务性原则保证，要么成功，要么不成功同步发送时，处理好返回值，如果发
1介绍我们实际系统中有很多操作，不管你执行多少次，都应该产生一样的效果或返回一样的结果。例如：前端页面重复提交选中的数据，服务端只产生对应这个数据的一个反应结果，只保存一次数据。我们发起一笔付款请求，也只能扣用户账户一次钱，即使遇到网络重发或系统bug重发，也应该只扣一次金额。消息通知，也应该只能收到一次，如果收到多次的扣款通知短信，会让用户误解的。创建商品订单，一次业务请求只能创建一个，创建多个就会变成购买多次，就会出问题。以上等等很多重要的场景，都需要幂等的特性来支持。幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。在编程中.一个幂等操作的特
1介绍消息中间件是指在分布式系统中完成消息的发送和接收的基础软件。消息中间件也可以称消息队列（MessageQueue/MQ），互联网场景中经常使用消息中间件进行消息路由、订阅发布、异步处理等操作，来缓解系统的压力。引入消息队列主要是为了解决如下问题的：1、解耦：如订单系统，可以通过消息队列把削减库存的工作交给库存系统去处理，而不用等实时响应。2、执行有序性：先进先出原理，按照进入消息队列的顺序处理业务事件。3、消息路由：按照不同的规则，将队列中消息发送到不同的业务服务中。4、异步处理：将一些无需实时响应结果的计算放到异步中，提升系统的吞吐率。5、削峰：将峰值期间的操作削减，比如整个操作流程包
1介绍在之前的章节中，我们介绍了消息的发送和消息通信的原理。但是这边有一个比较核心的关键点，那就是如果已经把消息传递给Broker。在Broker在被消费之前，如何保证消息的稳定性，避免消息丢失和数据。这时候就需要数据持久化数据来进行保障了。根据之前我们MQ系列2：消息中间件的技术选型章节做的分析，RabbitMQ支持1W+级别的吞吐，Kafka和Rocket支持10W+级别的吞吐，想要实现这么大的吞吐，必须具备一个很强悍的存储功能。下面我们来看看。2Broker存储架构RocketMQ采用文件存储机制（类似Kafka），即直接在磁盘上使用文件来保存消息，而不是采用Redis或者MySQL之类
1介绍前面的章节我学习了NameServer的原理，消息的生产发送，以及消息的消费的全过程。我们来回顾一下：RocketMQ消息队列架构主要包括NameServe、Broker(Master/Slave)、Producer、Consumer4个核心部件，基本执行流程如下：NameServer优先启动。NameServer是整个RocketMQ的“中央大脑”，作为RocketMQ的服务注册中心，所以RocketMQ需要先启动NameServer再启动Rocket中的Broker。Broker启动后，需要将自己注册至NameServer中，并保持长连接，每30s发送一次发送心跳包，来确保Broke
在之前的文章中，我们学习了RocketMQ的原理；RocketMQ中命名服务ServiceName的运行流程；以及消息生产、发送的原理和模式。这一篇，就让我们从消息消费的角度去进一步的学习。1消息消费消息的消费主要是由如下几个核心能力组成的：消费方式：Push（推）或者Pull（拉）消费模式：广播模式和集群模式消息消费反馈流量控制（包括消费并发线程数设置）消息的过滤（Tag,Key）,过滤标签TagA||TagB||TagC1.1消费方式PushorPullRocketMQ消息订阅有方式：Push方式（MQPushConsumer），MQServer主动向消费端推送；这种模式不考虑消费端是否有
在之前的篇章中，我们学习了RocketMQ的原理，以及RocketMQ中命名服务ServiceName的运行流程，本篇从消息的生产、消费来理解一条消息的生命周期。1消息生产在RocketMQ中，消息生产指的是消息生产者往消息队列中写入数据的过程。因为业务场景的复杂性，RocketMQ架构设计了多种不同的发送策略。下面先讨论几种常见的场景：同步发送：整个过程业务是阻塞等待的，消息发送之后等待Broker响应，得到响应结果之后再传递给业务线程。异步发送：调用RocketMQ的AsyncAPI，消息生产者只要把消息发送任务放进线程池就返回给业务线程。所有的逻辑处理、IO操作、网络请求都由线程池处理，
1关于NameServer上一节的MQ系列3：RocketMQ架构分析，我们大致介绍了RocketMQ的基本组件构成，包括NameServer、Broker、Producer以及Consumer四部分。NameServer，指的是服务可以根据给定的名字来进行资源或对象的地址定位，并获取有关的属性信息。在Rocket中也一样，NameServer是RocketMQ的服务注册中心（类似于Kafka集群后面的Zookeeper集群一样，对集群元数据进行管理），根据元数据（ip、port和router信息）来唯一定位服务。RocketMQ需要先启动NameServer，再启动Rocket中的Broke
1背景我们前面两篇对主流消息队列的基本构成和技术选型做了详细的分析。从本篇开始，我们会专注当下主流MQ之一的RocketMQ。从他的如下的几个方面去讨论：基础能力（如组织构成、消息发送、消息存储（持久化）、消息通信、消息消费）功能性方面（如消息堆积、消息回溯、消息追踪、消息过滤），高可用性方面（如消息顺序性保障、消息幂等性保障、消息安全性保障、消息事务性保障），性能方面（如时效性，单机吞吐率）参考MQ系列2：消息中间件的技术选型1.1RocketMQ是的基本组件构成RocketMQ主要有四大核心组成部分：NameServer、Broker、Producer以及Consumer四部分。NameS
1背景在高并发、高消息吞吐的互联网场景中，我们经常会使用消息队列（MessageQueue）作为基础设施，在服务端架构中担当消息中转、消息削峰、事务异步处理等职能。对于那些不需要实时响应的的业务，我们都可以放在消息队列中进行传输。下面是用户在进行系统注册的时候场景，充分体现MQ的作用可以看到用户注册的过程步骤1+步骤2，从请求到响应总共耗时55ms。消息消费+短信发送的时间比较长，从上面看花了5s多，一般让消息队列服务去处理，用户静静等待短信送达即可。消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和
1关于消息中间件1.1什么是消息中间件？消息中间件是指在分布式系统中完成消息的发送和接收的基础软件。消息中间件也可以称消息队列（MessageQueue/MQ），用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。简而言之，互联网场景中经常使用消息中间件进行消息路由、订阅发布、异步处理等操作，来缓解系统的压力。1.2它解决了我们哪些痛点？1、解耦：比如说系统A会交给系统B去处理一些事情，但是A不想直接跟B有关联，避免耦合太强，就可以通过在A，B中间加入消息队列，A将要任务的事情交给消息队列,B