之乎者也·的博客

消息不丢失、不重复是消息队列的基本要求，但这个基本要求还是很难满足的。消息丢失这个要求，主流消息队列通过消息重试和消息持久化的方式可以满足。但消息重试也同时带来了消息重复的可能性，主流消息队列在解决重复消息的问题上并没有现成的方案，对不允许重复消费的场景，需要开发人员在消费端做幂等处理。

从messageQueue 拉取消息，进行消费。Rocketmq 源码内部，拉模式消费使用的是DefaultMQPullConsumer/DefaultLitePullConsumerImpl，核心逻辑是先拿到需要获取消息的Topic对应的队列，然后依次从队列中拉取可用的消息。注意，拉取的消息，放在另一个队列 messageQueue 缓存，拉取之前，会进行流控检查，如果这个队列满了（>1000个消息或者 >100M内存） 则延迟50ms再拉取， 当然，下一次执行拉取之前，同样也会进行流控检查。

一条订单产生的三条消息：订单创建、订单付款、订单完成。上面三消息是有序的，消费时要按照这个顺序依次消费才有意义，但是不同的订单之间这些消息是可以并行消费的。什么是顺序消息？顺序消息是指对于一个指定的 Topic ，消息严格按照先进先出（FIFO）的原则进行消息发布和消费，即先发布的消息先消费，后发布的消息后消费。顺序消息分为两种：分区有序消息全局有序消息我们做一个关于顺序消费的总结：通过4把锁的机制，消息队列 messageQueue 的数据都会被消费者实例单线程的执行消费；

而对于局部有序的要求，只需要将有序的一组消息都存入同一个MessageQueue里，这样MessageQueue的FIFO设计天生就可以保证这一组消息的有序。而MessageQueue是RocketMQ存储消息的最小单元，他们之间的消息都是互相隔离的，在这种情况下，是无法保证消息全局有序的。而这时候，对消息的顺序就有一定的要求了。然后把所有消费者节点的目标Topic转向新的Topic，并紧急上线一组新的消费者，只负责转储，就是消费老Topic中的积压消息，并转储到新的Topic中，这个速度是可以很快的。

消息队列在高并发系统设计中起到了关键的作用。它可以帮助我们处理高并发的写请求，提高系统的性能和稳定性。然而，使用消息队列也需要我们关注一些实践问题，如消息的丢失和重复处理，以及消息队列的扩展性等。

自定义分区器可以参考下面。Kafka默认的分区器规则：1）当消息的key存在时，首先获取当前topic下的所有分区数，然后对key进行求hash值，根据hash值和分区总数进行取余，获取所属的的分区。2）如果key不存在时，会根据topic获取一个递增的数值，然后通过和分区数进行取余，获取所属的分区。

默认情况下，消息只要到了 Broker 端，将会优先保存到内存中，然后立刻返回确认响应给生产者。这种方式减少 I/O 次数，可以取得更好的性能，但是如果发生机器掉电，异常宕机等情况，消息还未及时刷入磁盘，就会出现丢失消息的情况。以上任一阶段都可能会丢失消息，我们只要找到这三个阶段丢失消息原因，采用合理的办法避免丢失，就可以彻底解决消息丢失的问题。若想保证 Broker 端不丢消息，保证消息的可靠性，我们需要将消息保存机制修改为同步刷盘方式，即消息。为了进一步提高消息的可靠性，我们可以采用同步的复制方式，

在Kafka中，一个consumer订阅多个topic时，其中一个topic的消息积压可能会影响consumer的性能。Kafka是一个高吞吐量的分布式消息系统，它的设计目标是能够处理大量的消息。当一个consumer订阅多个topic时，它会从这些topic中拉取消息，并逐一处理。如果其中一个topic的消息积压严重，consumer需要花费更多的时间和资源来处理这些积压的消息，这可能会影响到对其他topic的消费速度。

今天主要分享一下 kafka 的 rebalance，在 kafka 中，rebalance 是一个十分重要的概念，很多时候引发的一些问题可能都是由于 rebalance 引起的，rebalance 也就是再均衡，顾名思义，再均衡就是再次负载均衡，下面会对再均衡进行一个详细的描述。（1）range策略就是按照分区序号排序(范围分配)，假设 n＝分区数／消费者数量 = 3， m＝分区数%消费者数量 = 1，那么前 m 个消费者每个分配 n+1 个分区，后面的（消费者数量－m ）个消费者每个分配 n 个分区。

然后，Kafka使用一定的时间间隔将缓存中的消息批量写入磁盘。缓存的大小可以通过Kafka配置中的`log.flush.interval.messages`和`log.flush.interval.ms`参数来配置。当缓存中的消息被写入磁盘时，它们被追加到一个或多个日志文件中。需要注意的是，Kafka的数据存储在磁盘上是持久的，而在内存中的缓存则具有一定的容量限制。当缓存的大小达到了阈值或者达到了一定的时间间隔时，Kafka会将缓存中的消息写入磁盘，以确保数据的安全性和可靠性。

即代表的一个kafka的server服务器。kafka下的消息逻辑概念，可以看成众多的消息的集合。一个topic先可以多个分区，不同的分区可以分别部署在broker中。同一个分区的不同副本保存相同的数据，副本之间是一主多从，Leader和Follower角色。Leader副本负责读写请求，Folower只与Leader副本消息同步。Leader副本出现故障后，则从Follower副本中选举Leader副本对外提供服务。可以通过提高副本数量，可以提高容灾能力。

leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的 数据一致性，其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader 同步数据。follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘 记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。

是的，所有的问题，思路，优化点都已经列出来了，我们可以尽可能的细化，三个方向都可以细化，如此，所有的实现便一目了然，即使不看 Kafka 的实现，我们自己也可以想到一二点可以优化的地方。HashMap数据是无序的，是随机读写的。Producer、Broker 和 Consumer 使用相同的压缩算法，在 producer 向 Broker 写入数据，Consumer 向 Broker 读取数据时甚至可以不用解压缩，最终在 Consumer Poll 到消息时才解压，这样节省了大量的网络和磁盘开销。

ACK = 1：生产者发送数据，是需要等待leader的应答，如果应答完成，才能发送下一条message，是不关心follower是否pull完成，是否接收成功的。这样，虽说性能会慢些，但是数据会比较安全。可但是，在leader保存完数据后，突然leader所在的broker down掉了，此时的follower还没来得及从leader那儿pull数据，那么这个数据就会丢失。当生产者发送数据后，需要等待所有的副本的应答，包括leader+follower，这种方式是最安全的，但同时也是性能最差的。

1. 如果kafka 允许1个partition的数据可以被同组中多个consumer消费，那么多个消费者必然要共同维护同一个 offset，因为这个offset影响数据消费的准确性(消息重复或漏消息)，所以offset要做到强一致性。2.让同组的多个消费者消费同一个partition，其目的就是为了提高并发度。kakfa设计partition的初衷之一就是为了提高并发度，还有个目的是综合利用各个独立物理机的能力。

Kafka采用了分布式存储和分区机制，使得不同的数据分散存储在不同的节点上，并可水平扩展，从而实现高吞吐量。此外，Kafka还采用基于磁盘的存储方式，较少使用内存，因此可以存储更大量的数据。Kafka是一个开源的分布式流处理平台，主要用于处理高吞吐量的数据流和消息队列系统。相比其他消息队列系统，Kafka最大的优势在于它的高吞吐量和可靠性。Kafka的分区机制是指将数据划分为多个分区，每个分区存储在不同的节点上。每个分区中的消息是有序的，因此可以保证消息的顺序性，同时还可以提高并发处理的能力。

在消费端，Kafka通常不会出现消息丢失的情况。如果发生消息丢失，可以调offset来实现消息的重新消费。以上信息仅供参考，可以查阅Kafka相关的文档和书籍获取更多信息。

批处理是一种数据处理方式，它按照固定的时间间隔或固定的数据量来收集、处理和分析数据。批处理适用于那些不需要实时响应的任务，如数据报表生成、大规模数据清洗、离线数据分析等。在批处理中，数据通常存储在一个集中的位置，然后周期性地批量处理。这个处理周期可以是每天、每周或根据业务需求的其他时间间隔。批处理任务会在处理过程中消耗大量资源，因为它需要处理整个数据集。

延时队列：是一种消息队列，可以用于在指定时间或经过一定时间后执行某种操作。本案例已成功实现Kafka的延时队列，并进行实测，代码引入可用非常方便。Kafka实现的延时队列支持秒级别的延时任务，不支持毫秒级别，但是毫秒级别的延时任务也没有意义注意一个主题对应的延时时间是一致的，不能在同一个主题里放不同时间的延时任务。

登录Web界面，在“Exchanges”页签，单击Exchange名称，进入Exchange详情页。在“Publish message”区域，设置expiration值，如下图所示。从消息进入队列开始计算，超过了配置的队列过期时间，消息会自动被删除。过量的消息堆积可能会引起内存或磁盘告警，从而造成所有connection阻塞，进而影响到其他队列的使用，导致整体服务质量的下降。在Web界面新建队列时，设置x-message-ttl值，单位为毫秒(ms)。，设置x-message-ttl值，如下图所示。

消息重复消费的根本原因都在于：已经消费了数据，但是offset没有成功提交。其中很大一部分原因在于发生了再均衡。1）消费者宕机、重启等。导致消息已经消费但是没有提交offset。2）消费者使用自动提交offset，但当还没有提交的时候，有新的消费者加入或者移除，发生了rebalance（再平衡）。再次消费的时候，消费者会根据提交的偏移量来，于是重复消费了数据。

引入MQ消息中间件最直接的目的：系统解耦以及流量控制系统解耦： 上下游系统之间的通信相互依赖，利用MQ消息队列可以隔离上下游环境变化带来的不稳定因素。流量控制： 超高并发场景中，引入MQ可以实现流量 “削峰填谷” 的作用以及服务异步处理，不至于打崩服务。引入MQ同样带来其他问题：数据一致性。在分布式系统中，如果两个节点之间存在数据同步，就会带来数据一致性的问题。消息生产端发送消息到MQ再到消息消费端需要保证消息不丢失。

消费者中我们注册了一个监听器回调函数，当Consumer获取消息后，就会交给我们的回调函数来进行处理。如果处理完了，就返回一个ConsumeConcurrentlyStatus.CONSUME_SUCCESS，提交这批消息的offset到broker去，然后继续从broker获取下一批消息来进行处理。如果上面代码回调函数中，对一批消息处理的时候，数据库宕机了就不能再能返回CONSUME_SUCCESS，如果你返回的话，下一次就会处理下一批消息，但是这批消息其实没处理成功，此时必然导致这批消息就丢失了；

基本概念：延迟消息是指生产者发送消息发送消息后，不能立刻被消费者消费，需要等待指定的时间后才可以被消费。场景案例：用户下了一个订单之后，需要在指定时间内(例如30分钟)进行支付，在到期之前可以发送一个消息提醒用户进行支付。

一般最好把去重操作直接放在了消费端，消费端处理消息的业务逻辑保持幂等性。消费者收到消息后，从消息中获取消息标识写入到Redis（分布式锁）或数据库（标识作为表唯一索引插入一条记录），当再次收到该消息时就不作处理。在broker端对Queue加锁（synchronized），Consumer监听的Queue存在已投递但未收到ack且未超时的消息，不允许获取锁，直到该Queue投递的消息全部ack或者消费超时，才允许新的Consumer获取锁，拉取消息。

全称(message queue)消息队列,一个用于接收消息、存储消息并转发消息的中间件多用于解决异步、削峰、解耦等场景，是能接收消息并转发消息。

我们还是先从简单版的 MQ 入手，如果只是实现一个很粗糙的 MQ，完全不考虑生产环境的要求，该如何设计呢？任何 MQ 无外乎：一发一存一消费，这是 MQ 最核心的功能需求。另外，从技术维度来看 MQ 的通信模型，可以理解成：两次 RPC + 消息转储。（1）、直接利用成熟的 RPC 框架（Dubbo 或者 Thrift），实现两个接口：发消息和读消息。（2）、消息放在本地内存中即可，数据结构可以用 JDK 自带的 ArrayBlockingQueue。

Kafka 作为流平台具有以下三种能力：发布和订阅记录流，类似于消息队列或企业消息系统；具有容错能力，且可以持久化的方式存储记录流；当记录流产生时（发生时），可及时对其进行处理。Kafka 适用于两类应用：建立实时流数据管道，在系统或应用之间可靠地获取数据；建立对数据流进行转换或反应的实时流应用程序。kafka 包含四种核心 API。Producer API：基于该 API，应用程序可以将记录流发布到一个或多个 Kafka 主题（Topics）；

MQ(message queue)，从字面意思上看，本质是个队列，FIFO 先入先出，只不过队列中存放的内容是 message 而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ 是一种非常常 见的上下游「逻辑解耦 + 物理解耦」的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务。

Broker：接收和分发消息的应用，RabbitMQ Server 就是 Message Broker：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出多个 vhost，每个用户在自己的 vhost 创建 exchange／queue 等Connection：publisher／consumer 和 broker 之间的 TCP 连接Channel。

RabbitMQ 是采用 Erlang 语言开发的，所以系统环境必须提供 Erlang 环境，需要先安装 Erlang。安装包，分别是 RabbitMQ 安装包和 Erlang 环境安装包，后者提供环境给前者运行。这里安装的是 3.8.8 版本的 RabbitMQ，需要的 Erlang 版本依然是21.3。默认情况下，RabbiMQ 没有安装 Web 端的客户端软件，需要安装才可以生效。安装好这个后，再次安装 Erlang 即可成功。登录，输入添加好的用户名和密码，即可进入后台。

通过程序执行发现生产者总共发送 4 个消息，消费者 first 和消费者 second 分别分得两个消息，并且是按照有序的一个接收一次消息。在下图中，“ P” 是我们的生产者，“ C” 是我们的消费者。案例中生产者叫做 Task，一个消费者就是一个工作队列，启动两个工作队列消费消息，这个两个工作队列会以轮询的方式消费消息。轮询消费消息指的是轮流消费消息，即每个工作队列都会获取一个消息进行消费，并且获取的次数按照顺序依次往下轮流。创建一个类作为消费者，消费 RabbitMQ 队列的消息。

在最开始的时候我们学习到 RabbitMQ 分发消息采用的轮询分发，但是在某种场景下这种策略并不是很好，比方说有两个消费者在处理任务，其中有个消费者 1处理任务的速度非常快，而另外一个消费者 2处理速度却很慢，这个时候我们还是采用轮询分发的化就会到这处理速度快的这个消费者很大一部分时间处于空闲状态，而处理慢的那个消费者一直在干活，这种分配方式在这种情况下其实就不太好，但是 RabbitMQ 并不知道这种情况它依然很公平的进行分发。为了避免这种情况，在消费者中消费消息之前，设置参数//队列名称。

上一节中的我们的日志系统将所有消息广播给所有消费者，对此我们想做一些改变，例如我们希望将日志消息写入磁盘的程序仅接收严重错误(errros)，而不存储哪些警告(warning)或信息(info)日志 消息避免浪费磁盘空间。Fanout 这种交换类型并不能给我们带来很大的灵活性-它只能进行无意识的广播，在这里我们将使用 direct 这种类型来进行替换，这种类型的工作方式是，消息只去到它绑定的 routingKey 队列中去。在上面这张图中，我们可以看到 X 绑定了两个队列，绑定类型是 direct。

先从概念解释上搞清楚这个定义，死信，顾名思义就是无法被消费的消息，字面意思可以这样理解，一般来说，producer 将消息投递到 broker 或者直接到queue 里了，consumer 从 queue 取出消息 进行消费，但某些时候由于特定的原因。先启动消费者 C1，创建出队列，然后停止该 C1 的运行，则 C1 将无法收到队列的消息，无法收到的消息 10 秒后进入死信队列。，这样的消息如果没有后续的处理，就变成了死信，有死信自然就有了死信队列。1、消息生产者代码去掉 TTL 属性，

延时队列,队列内部是有序的，最重要的特性就体现在它的延时属性上，延时队列中的元素是希望 在指定时间到了以后或之前取出和处理，简单来说，延时队列就是用来存放需要在指定时间被处理的 元素的队列。订单在十分钟之内未支付则自动取消新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒用户注册成功后，如果三天内没有登陆则进行短信提醒用户发起退款，如果三天内没有得到处理则通知相关运营人员预定会议后，需要在预定的时间点前十分钟通知各个与会人员参加会议。

在生产环境中由于一些不明原因，导致 RabbitMQ 重启，在 RabbitMQ 重启期间生产者消息投递失败，导致消息丢失，需要手动处理和恢复。于是，我们开始思考，如何才能进行 RabbitMQ 的消息可靠投递呢？首先发布消息后进行备份在缓存里，如果消息成功发布确认到交换机，则从缓存里删除该消息，如果没有成功发布，则设置一个定时任务，重新从缓存里获取消息发布到交换机，直到成功发布到交换机。获取回退的消息，首先在配置文件开启该功能，然后需要自定义类实现。

幂等性概念用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。可以理解为验证码，只能输入一次，再次重新输入会刷新验证码，原来

Kafka日志管理器中会有一个专门的日志删除任务来定期检测和删除不符合保留条件的日志分段文件，这个周期可以通过broker端参数log.retention.check.interval.ms来配置，默认值为300,000，即5分钟。日志删除任务会检查当前日志的大小是否超过设定的阈值来寻找可删除的日志分段的文件集合。log.retention.bytes 配置的是日志文件的总大小，而不是单个的日志分段的大小，一个日志文件包含多个日志分段。Log Compaction是默认的日志删除之外的清理过时数据的方式。

controller是kafka集群的老大，是针对Broker的一个角色Leader是针对partition的一个角色，是通过ISR来进行快速选举Kafka启动时，会在所有的broker中选择一个controller前面leader和follower是针对partition，而controller是针对broker的创建topic、或者添加分区、修改副本数量之类的管理任务都是由controller完成的Kafka分区leader的选举，也是由controller决定的。