有才而性缓，定属大才。有智而气和，斯为大智。

因此，如果分区数量固定，消费者数量的上限就是分区的数量。这种方式更类似于Leader-Follower模式，而不是传统意义上的主从模式，因为在Kafka中，每个Broker（Kafka的服务器节点）都可能成为某个Partition的Leader，也可能是Follower，这取决于你如何配置和使用你的Kafka集群。需要注意的是，一个Partition在一个消费者组中，一次只能被一个消费者消费，所以消费者组中的消费者数量不能超过总的Partition数量，否则多余的消费者将会闲置。

6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。7）Offset(即id)：kafka的存储文件的每个分区的偏移量都从0开始，不同分区之间的偏移量都是独立的，不会相互影响。能数据管道，流分析，数据集成和关键任务等相关的应用程序。

kafka是一种分布式的，基于发布/订阅的消息系统。它可以处理消费者在网站中的所有动作流数据。这种动作(网页浏览，搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。

一、官网二、博主文章1、三、源码解读。

问题要从一次Kafka的宕机开始说起。笔者所在的是一家金融科技公司，但公司内部并没有采用在金融支付领域更为流行的 RabbitMQ ，而是采用了设计之初就为日志处理而生的 Kafka ，所以我一直很好奇Kafka的高可用实现和保障。从Kafka部署后，系统内部使用的Kafka一直运行稳定，没有出现不可用的情况。但最近系统测试人员常反馈偶有Kafka消费者收不到消息的情况，登陆管理界面发现三个节点中有一个节点宕机挂掉了。但是按照高可用的理念，三个节点还有两个节点可用怎么就引起了整个集群的消..

我们查询的任务数跟线程数映射不合理比如1000条数据 50个线程，每条数据一个线程顺序消费数据，按借据进行分片，，一条处理不完，其他不允许处理。缓冲区大小，调用频率，

buffer.memoryKafka的客户端发送数据到服务器，不是来一条就发一条，而是经过缓冲的，也就是说，通过KafkaProducer发送出去的消息都是先进入到客户端本地的内存缓冲里，然后把很多消息收集成一个一个的Batch，再发送到Broker上去的，这样性能才可能高。buffer.memory的本质就是用来约束Kafka Producer能够使用的内存缓冲的大小的，默认值32MB。如果buffer.memory设置的太小，可能导致的问题是：消息快速的写入内存缓冲里，但Sender线程来不及

01 为什么从 Kafka 开始？从这篇文章开始，我会讲解具体的消息中间件，之所以选择从 Kafka 开始，有 3 点考虑：第一，RocketMQ 和 Kafka 是目前最热门的两种消息中间件，互联网公司应用最为广泛，将作为本系列的重点。第二，从 MQ 的发展历程来看，Kafka 先于 RocketMQ 诞生，并且阿里团队在实现 RocketMQ 时，充分借鉴了 Kafka 的设计思想。掌握了 Kafka 的设计原理，后面再去理解 RocketMQ 会容易很多。第三，Kafka 其实..

前言我的上家公司是做餐饮系统的，每天中午和晚上用餐高峰期，系统的并发量不容小觑。为了保险起见，公司规定各部门都要在吃饭的时间轮流值班，防止出现线上问题时能够及时处理。我当时在后厨显示系统团队，该系统属于订单的下游业务。用户点完菜下单后，订单系统会通过发kafka消息给我们系统，系统读取消息后，做业务逻辑处理，持久化订单和菜品数据，然后展示到划菜客户端。这样厨师就知道哪个订单要做哪些菜，有些菜做好了，就可以通过该系统出菜。系统自动通知服务员上菜，如果服务员上完菜，修改菜品上菜状态，用户就知道哪些菜已经

这是[码哥]Kafka 系列文章的第二篇，码哥将从原理、实践和源码角度为大家深入剖析并实践 Kafka。此系列包括[原理篇]、[实践篇]和[源码篇]。这篇是[原理篇]的第二篇，主要讲解 Kafka 的架构和实现原理。读者可以回顾之前的文章《Kafka 性能篇：为何 Kafka 这么"快"？》。今天我们来深入讲解 Kafka 的架构和实现原理。[码哥]将从架构和细节入手，以生动的图深入讲解 Kafka 的实现原理。我想很多同学之前可能已经看过很多 Kafka 原理相关的文章，但往往看时"牛逼"声连

Kafka 是一个优秀的分布式消息中间件，许多系统中都会使用到 Kafka 来做消息通信。对分布式消息系统的了解和使用几乎成为一个后台开发人员必备的技能。今天码哥字节就从常见的 Kafka 面试题入手，和大家聊聊 Kafka 的那些事儿。思维导图讲一讲分布式消息中间件问题 什么是分布式消息中间件？ 消息中间件的作用是什么？ 消息中间件的使用场景是什么？ 消息中间件选型？ 消息队列分布式消息是一种通信机制，和 RPC、HTTP、RMI 等不一样，

『码哥』的 Redis 系列文章有一篇讲透了 Redis 的性能优化 ——《Redis 核心篇：唯快不破的秘密》。深入地从 IO、线程、数据结构、编码等方面剖析了 Redis “快”的内部秘密。65 哥深受启发，在学习 Kafka 的过程中，发现 Kafka 也是一个性能十分优秀的中间件，遂要求『码哥』讲一讲 Kafka 性能优化方面的知识，所以『码哥』决定将这篇性能方面的博文作为 Kafka 系列的开篇之作。先预告一下 Kafka 系列文章，大家敬请期待哦：以讲解性能作为 Kafka 之旅的开

应用从Kafka中读取数据需要使用KafkaConsumer订阅主题，然后接收这些主题的消息。在我们深入这些API之前，先来看下几个比较重要的概念。Kafka消费者相关的概念消费者与消费组假设这么个场景：我们从Kafka中读取消息，并且进行检查，最后产生结果数据。我们可以创建一个消费者实例去做这件事情，但如果生产者写入消息的速度比消费者读取的速度快怎么办呢？这样随着时间增长，消息堆积越来越严重。对于这种场景，我们需要增加多个消费者来进行水平扩展。Kafka消费者是消费组的一部分，当多个消费者

主要是提交和消费 消息位置的标识，避免重复消费。成功调用返回偏移量。小

错误：Failed to send; nested exception is org.apache.kafka.common.errors.NotLeaderForPartitionException: This server is not the leader for that topic-partition.找不到推送消息服务器的所在分区，那估计就是kafka挂掉了1.kafka的几个概念：producer：生产者。consumer：消费者。topic: 消息以topic为类别记录,

1.先看代码不断的去创建kafka发送客户端客户端id，我们指定的cliendId是固定的，在并发量小的时候，创建kafka客户端，指定客户端id，销毁，正常。但并发量大的时候，可能出现上创建cliendId的客户端服务没有来得及销毁，又重新创建了一个2.解决方案，1.不指定固定的clientid，2.保证每一建立连接的clientID唯一，3.把创建clientId的...