justlpf的专栏

消费者的心跳间隔时间由参数 heartbeat.interval.ms指定，默认值为 3000，即3 秒，这个参数必须比 session.timeout.ms 参数设定的值要小，一般情况下heartbeat.interval.ms 的配置值不能超过 session.timeout.ms配置值的1/3。消费者重平衡完成后，GroupCoordinator与消费者之间保持心跳信息，由心跳信息保证消费者与GroupCoordinator的从属关系，以及它们对分区的所有权关系的存活。a. 总结触发重平衡的原因；

hasNext)@Override......跟前面的大同小异，同样也是iterator()入口，当开启了压缩时，返回压缩迭代器，只是名字不同而已，迭代器内部依然是直接通过的解压逻辑对数据流进行解压。

即使enable.auto.commit为false，偏移量也会在每一批poll()的数据被消费者监听器（ListenerConsumer）处理之后提交，这里的提交实际上是手动提交，但是这个“手动提交”操作由Spring帮我们做了。如果后面有消息的offset被提交，那么该offset之前的所有消息都算作已提交，重启之后也不会被再次消费。MANUAL和MANUAL_IMMEDIATE的区别是。

因为每次处理都创建新的线程，造成大量线程同时创建和销毁，线程数波动剧烈，GC频繁，系统各项指标均不平稳。通过线程池进行处理，线程数一直保持在2000个左右。好像更加平稳了，但是很出现线程阻塞的情况。和第二种的执行时间差不多，但是各项。

上图中,我们发现并没有按照我们的预期去做;有三个消费者其实是闲置状态的;只有另外的3个消费者负责了2个Topic的总共6个分区;说明的问题就是 在消费的时候是单线程消费的,并且还是一个线程去消费 3个分区的数据;又涉及到切换消费分区的问题;假如如下情况,同时监听了2个Topic;并且每个topic的分区都是3;那么期望的是不是 2*3=6 刚好6个线程;一个线程分配一个分区;第一个客户端进行了 再平衡;因为多了第二个可以分担压力进行消费;如果想达到我们的预期;, 只启动一个客户端;在消费3个分区的数据;

kafka消息过滤器就是消息在到达监听器前被拦截并根据业务设置一种过滤策略，将返回结果为true的消息进行过滤，返回结果为false的消息交由监听器进行业务处理。

消息在写入broker时，且每个broker完成这条消息的同步后，hw才会变化。在同步完成之后，HW更新之后，消费者才能消费到这条消息，这样的目的是防止消息的丢失。消费者的消费速度远远赶不上生产者的生产速度，导致kafka中有大量的数据没有被消费。随着没有被消费的数据越来越多，消费者寻址的性能会越来越差。在防止消息丢失的方案中，如果生产者发送完消息后，因为网络抖动，没有收到ack，但实际上broker已经收到了。此时生产者会进行重试，于是broker就会收到多条相同的消息，而造成消费者的重复消费。

删除kafka topic及其数据，严格来说并不是很难的操作。但是，往往给kafka 使用者带来诸多问题。项目组之前接触过多个开发者，发现都会偶然出现无法彻底删除kafka的情况。本文总结多个删除kafka topic的应用场景，总结一套删除kafka topic的标准操作方法。

• 当broker数量大于partition数量，则有些broker空闲，此时增加partition会带来性能提升。而且是线性增长。• 当两者相等，则所有broker都启用，吞吐达到瓶颈。• 继续增加，则broker会不均衡，有点会分到更多的partition。顺序IO退化成随机IO。如果应用需要读取全量消息，那么请为该应用设置一个消费组；如果该应用消费能力不足，那么可以考虑在这个消费组里增加消费者。broker的数量最好大于等于partition数量。

【代码】Kafka--批量删除所有topic(或删除以 xxx 为开头的topic)

可用于并发处理，一个消息只能被一个worker拉到。类似生产者/消费者关系。中间转发，用于分发，负载均衡。

即消息的Ackownledge确认机制，为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消息了。实际操作过程中，发布订阅消息模型中，支持向一个特定的主题Topic发布消息， 0个或多个订阅者接收来自这个消息主题的消息。消息的收发处理支持事务，例如：在任务中心场景中，一次处理可能涉及多个消息的接收、处理，这处于同一个事务范围内，如果一个消息处理失败，事务回滚，消息重新回到队列中。

（3）txRollback用于回滚事务，在通过txSelect开启事务之后，我们便可以发布消息给broker代理服务器了，如果txCommit提交成功了，则消息一定到达了broker了，如果在txCommit执行之前broker异常崩溃或者由于其他原因抛出异常，这个时候我们便可以捕获异常通过txRollback回滚事务了。事务确实能够解决producer与broker之间消息确认的问题，只有消息成功被broker接受，事务提交才能成功，否则我们便可以在捕获异常进行事务回滚操作同时进行消息重发。

时间轮算法（Time Wheel Algorithm）是一种高效的实现方式，主要用于高并发下的定时。它利用了的思想，将时间轴分成一个一个的时间槽，每个时间槽代表一个时间段，定时任务在插入时被放到相应的时间槽中，当时间轮转动时，定时任务就会被触发。为了更好地理解时间轮算法，举个简单的例子：假设要在1小时后执行某项任务，那么我们可以将整个1小时时间轴分成60个时间槽，每个时间槽代表1分钟时间。然后将该任务放入第60个时间槽中。当时间轮启动时，时间轴开始滚动，当轴上的指针指向第60个槽时，任务就会被触发。

在电商、支付等领域，往往会有这样的场景，用户下单后放弃支付了，那这笔订单会在指定的时间段后进行关闭操作，细心的你一定发现了像某宝、某东都有这样的逻辑，而且时间很准确，误差在1s内；那他们是怎么实现的呢？定时任务关闭订单rocketmq延迟队列rabbitmq死信队列时间轮算法redis过期监听。

日前拜读阿牛老师的大作《领导：谁再用定时任务实现关闭订单，立马滚蛋！》发现其方案有若干瑕疵，特此抛砖引玉讨论一二。

一个简单的时间轮是一个定时器任务桶的循环列表。让u作为时间单位。尺寸为n的时间轮有n个桶，可以在n*u的时间间隔内保存定时器任务。每个bucket保存属于相应时间范围的计时器任务。在开始时，第一个桶保存[0，u）的任务，第二个桶保存[u，2u），…的任务…，[u*（n-1），u*n）的第n个bucket。每个时间单位u的间隔，计时器滴答作响移动到下一个bucket，然后使其中的所有计时器任务过期。因此，计时器从不插入任务到当前时间的存储桶，因为它已经过期。计时器会立即运行已过期的任务。

在开始介绍时间轮之前，思考这样一个问题：“怎么实现 Kafka 中的延时请求呢？”针对这个问题，第一反应是使用Java的DelayQueue。毕竟，这个类是 Java 天然提供的延时队列，非常适合建模延时对象处理。实际上，Kafka 的第一版延时请求就是使用 DelayQueue 做的。但是，DelayQueue 有一个弊端：它插入和删除队列元素的时间复杂度是 O(logN)。对于 Kafka 这种非常容易积攒几十万个延时请求的场景来说，该数据结构的性能是瓶颈。

https://www.cnblogs.com/softlin/p/7426083.html在Kafka中应用了大量的延迟操作但在Kafka中 并没用使用JDK自带的Timer或是DelayQueue用于延迟操作，而是使用自己开发的DelayedOperationPurgatory组件用于管理延迟操作，Kafka这类分布式框架有大量延迟操作并且对性能要求及其高，而java.util.Timer与java.util.concurrent.DelayQueue的插入和删除时间复杂度都为对数阶O(log n)并不

两个follower副本都已经拉取到了leader副本的最新位置，此时又向leader副本发送拉取请求，而leader副本并没有新的消息写入，那么此时leader副本该如何处理呢？可以直接返回空的拉取结果给follower副本，不过在leader副本一直没有新消息写入的情况下，follower副本会一直发送拉取请求，并且总收到空的拉取结果，消耗资源。其次，延时操作不同于定时操作，定时操作是指在特定时间之后执行的操作，而延时操作可以在所设定的超时时间之前完成，所以延时操作能够支持外部事件的触发。

当然，每个分区只能由同一个消费组内的一个 consumer 来消费.如下图所示，分别有三个消费者，属于两个不同的 group，那么对于 firstTopic 这个 topic 来说，这两个组的消费者都能同时消费这个 topic 中的消息，对于此事的架构来说，这个 firstTopic 就类似于 ActiveMQ 中的 topic 概念。中的消费者而言的，当有新 groupid 的消费者来消费指定的 topic 时，对于该参数的配置，会有不同的语义。情况下，新的消费者会从该 topic 最早的消息开始消费。

是kafka时间轮的实现，内部包含了⼀个数组，每个数组包含了⼀些链表组成的事件，每个表示时间轮的某⼀格，这⼀格的时间跨度为tickMs，同⼀个中的事件都是相差在⼀个tickMs跨度内的，整个时间轮的时间跨度为，该时间轮能处理的时间范围在到之间的事件。当添加⼀个时间他的超时时间⼤于整个时间轮的跨度时，，则会将该事件向上级传递，上级的tickMs是下级的interval，传递直到某⼀个时间轮满足，然后计算对应位于哪⼀格，然后将事件放进去，重新设置超时时间，然后放进。

延迟队列存储的对象是对应的延迟消息，所谓的延迟消息是指当消息被发送以后，并不想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费。在订单系统中，一个用户下单之后通常有30分钟的时间进行支付，如果30分钟之内没有支付成功，那么这个订单将进行异常处理，这时候就可以使用延迟队列来处理这些订单了。用户希望通过手机远程遥控家里的智能设备在指定的时间进行工作，这时候就可以将用户指令发送到延迟队列，当指令设定的时间到了再将指令推送到只能设备。在AMQP协议中，或RabbitMQ。

如果手动创建过或者RabbitMQ中已经存在该队列那么也可以省略下述代码…/*** RabbitMQ配置*/@BeanrabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> log.info("消息发送成功:correlationData({}),ack({}),cause({})", correlationData, ack, cause));

几种实现方式的demo已经都提交到github 地址：https://github.com/chengxy-nds/delayqueue，感兴趣的小伙伴可以下载跑一跑。

当时间轮的指针指向1号槽时，即currentTime=1Ms，说明0号槽的任务都已经到期了，这时0号槽就会被拿出来复用，可以容纳20~21Ms延迟时间的任务。也就是说，如果currentTime=0Ms时进来一个21Ms的延迟任务，就需要创建更高一级的时间轮，但是如果currentTime=1Ms时进来一个21Ms的延迟任务，就可以直接把它放到0号槽中，当currentTime=21时，指针又指向0号槽。也就是第二层时间轮每一个槽所能表示的时间是第一层时间轮所能表示的时间范围，也就是。

kafka的延迟队列使用时间轮实现，能够支持大量任务的高效触发，但是在kafka延迟队列实现方案里还是看到了delayQueue的影子，使用delayQueue是对时间轮里面的bucket放入延迟队列，以此来推动时间轮滚动，但是基于将插入和删除操作则放入时间轮中，将这些操作的时间复杂度都降为O(1)，提升效率。Kafka对性能的极致追求让它把最合适的组件放在最适合的位置。

说明：客户端直接通过客户端认证（比如client_id和client_secret）从认证服务器获取访问令牌。说明：客户端直接向用户获取账号密码（不安全），之后向授权服务器获取token。说明：正宗的oauth模式，先获取授权码，在通过授权码获取token。.0是目前流行的授权机制，用于授权第三方应用，获取数据。说明 ：和授权模式相比取消了授权过程，直接获取token。​​后，授权中心会要求资源所有者进行身份验证。​​,回调路径会，回调路径携带着令牌。当请求到达授权中心​​。

MQ的作用异步、解耦、削峰、填谷。1.1 未使用MQ的情况mysql并发写大部分情况下维持在600-800之间，并发读1200-1500之间，所以消费端在消费消息的时候需控制在并发小于1000，从而达到限流的效果。1.2 使用MQ的情况mq做个缓冲，消息放到磁盘，几个G或上t都可以存储，消息丢失的可能性比较小。

ActiveMQ和RabbitMQ的区别？关于文章没多少内容，请进链接：https://blog.youkuaiyun.com/qq_30764991/article/details/80573352,https://blog.youkuaiyun.com/qq_30764991/article/details/80516961好多学习内容，请自行学习。关于赞赏码倒是挺大的，哈哈，这个你得感谢中国伟大的企业家教育家...

-------------所以，当concurrency=3，自动提交设置为false时，如果你程序里有两个方法标记了@KafkaListener，那么此时会启动 2 * 3 = 6 个Consumer线程，6个Listener线程。3. 当concurrency > partition 的数量，会出现有的消费者的线程没有可消费的partition， 造成资源的浪费。可以看到当消费的线程为3 的时候，studentGroup 和 teacherGroup 的消费者数量是3，项目中总共是6个消费线程。

如果不想使用默认的"kafkaListenerContainerFactory"容器工厂，则必须手动创建一个"ConcurrentKafkaListenerContainerFactory"类的实例，并且其bean name 不能叫"kafkaListenerContainerFactory"（不然与默认的工厂实例重名了），然后把该对象加入spring容器中。另外，这两个消费者属于同一个组，Topic只有8个分区，2个消费者共10个线程，一个线程消费一个分区，所以必然有两个线程最后属于空闲状态。

尤其是在Windows下，很可能灰常麻烦。仅执行delete topic 是不好使的。还需要去zookeeper中删掉。Kafka消息可以添加key,添加唯一key。当然，这个根据需要，此条仅做讨论用。

在使用时Kafka时，经常遇到大批量消息在队列中，如果一个消息一个消息的消费的话效率太低下了，这时候要用到批量消费消息。

apache kafka可以使用SSL加密连接，还可以限制客户端访问，给客户端发行证书，只允许持有证书的客户端访问。下面使用jdk的keytool工具来生成证书，配置kafka。

参考: 【kafka专栏】不用zookeeper怎么安装kafka集群-最新kafka3.0版本在本专栏的之前的一篇文章《kafka3种zk的替代方案》已经为大家介绍过在kafka3.0种已经可以将zookeeper去掉。上图中黑色代表broker（消息代理服务），褐色/蓝色代表Controller(集群控制器服务)在搭建kafka3.0集群之前，我们需要先做好kafka实例角色规划。（四个broker，需要通过主动配置指定三个作为Controller，Controller需要奇数个，这一点和zk是一样的

KafkaConnect是一种用于在ApacheKafka和其他系统之间可扩展且可靠地流式传输数据的工具。它使快速定义将大量数据移入和移出Kafka的连接器变得简单。KafkaConnect可以摄取整个数据库或从所有应用程序服务器收集指标到Kafka主题中，使数据可用于低延迟的流处理。导出作业可以将数据从Kafka主题传送到二级存储和查询系统或批处理系统进行离线分析。

如果 ZooKeeper 集群的某个节点的数据发生变更，则会通知其它 ZooKeeper 节点同时执行更新，就得等着大家（超过半数）都写完了才行，这写入的性能就比较差了。当 Controller 变更的时候，需要重新加载所有的元数据到新的 Controller 身上，并且需要把这些元数据同步给集群内的所有 Broker。特别适合存储一些公共的配置信息、集群的一些元数据等等。存储系统了吧，一般而言，ZooKeeper 只适用于存储一些简单的配置或者是集群的元数据，不是真正意义上的存储系统。

参考文章： Centos7.4安装kafka并简单使用Kafka集群部署下载地址：Apache Kafka记住 千万不能下载源码，下载编译过的将kafka上传到 Linux里面并解压,kafka需要JDK的环境。配置config下面的server.properties文件三 kafka的一些基本命令二、Zookeeper集群搭建5、增加host配置：直接使用kafka自带的zookeeper建立zk集群1、将安装包kafka_2.11-0.10.0.1.tar.gz上传到/opt 目录下2

代码】KafkaAKHQ安装部署。