生产环境需考量各种因素，结合自身业务需求而制定。看一些考虑因素（以下顺序，可是分了顺序的哦）
现在我们就来看看在生产环境中的 Kafka 集群规划该怎么做。既然是集群，那必然就要有多个 Kafka 节点机器，因为只有单台机器构成的 Kafka 伪集群只能用于日常测试之用，根本无法满足实际的线上生产需求。而真正的线上环境需要仔细地考量各种因素，结合自身的业务需求而制定。
Kafka集群到底需要多大的存储空间？这是一个非常经典的规划问题。Kafka需要将消息保存在底层的磁盘上，这些消息默认会被保存一段时间然后自动被删除。虽然这段时间是可以配置的，但你应该如何结合自身业务场景和存储需求来规划Kafka集群的存储容量呢？
Kafka 集群方案该怎么做。既然是集群，那必然就要有多个 Kafka 节点机器，因为只有单台机器构成的 Kafka 伪集群只能用于日常测试之用，根本无法满足实际的线上生产需求。而真正的线上环境需要仔细地考量各种因素，结合自身的业务需求而制定。下面我就分别从操作系统、磁盘、磁盘容量和带宽等方面来讨论一下。
在选择压缩算法的时候，首先要考虑的就是压缩比和压缩速率。压缩比主要是为了节省网络带宽和磁盘存储空间，而压缩速率主要影响吞吐量。
先说结论，Kafka 部署在 Linux 上要比 Windows 和 Mac 上性能高的多，主要是以下几个原因：
kafka系列分为两个篇幅，分别是实用篇，讲使用命令和一些使用中会遇到的概念名词，理论篇，讲kafka为了实现高可用和高性能做了哪些努力。这篇我们从搭建开始，然后用kafka脚本去发送和接受信息，最后用go语言展示在代码之中怎么使用。
Kafka的优点 高吞吐量：单机每秒处理几十上百万的消息量。即使存储了许多TB的消息，它也保持稳定的性能。 高性能：单节点支持上千个客户端，并保证零停机和零数据丢失，异步化处理机制 持久化：将消息持久化到磁盘。通过将数据持久化到硬盘以及replica(follower节点)防止数据丢失。 零拷贝：减少了很多的拷贝技术，以及可以总体减少阻塞事件，提高吞吐量。 可靠性 ：Kafka是分布式，分区，复制和容错的。Kafka的特点 顺序读，顺序写 利用Linux的页缓存 分布式系统，易于向外扩展。所有的Produ
Broker丢失消息是由于Kafka本身的原因造成的，kafka为了得到更高的性能和吞吐量，将数据异步批量的存储在磁盘中。消息的刷盘过程，为了提高性能，减少刷盘次数，kafka采用了批量刷盘的做法。即，按照一定的消息量，和时间间隔进行刷盘。这种机制也是由于linux操作系统决定的。将数据存储到linux操作系统种，会先存储到页缓存（Page cache）中，按照时间或者其他条件进行刷盘（从page cache到file），或者通过fsync命令强制刷盘。数据在page cache中时，如果系统挂掉，数据会丢失。
创造一个分布式的实时流处理平台，也正是因为这个原因，Kafka选择了将日志分区和消费者群组模型。
Kafka存在丢消息的问题，消息丢失会发生在Broker，Producer和Consumer三种。Java面试宝典PDF完整版
Kafka存在丢消息的问题，消息丢失会发生在Broker，Producer和Consumer三种。
线上某个kafka集群由于种种原因，从 24 * 机型 A 置换迁移为 12 * 机型 B。从集群总资源维度看，排除其他客观因素，置换后，CPU总核数少了一半，使用率上升其实也是预期之内的。事实上置换后，集群CPU使用率确实也由原有的 20%提升至 40%，上升了约 1 倍多。但置换后，cpu sys使用率均值约达到了 12%，较为抢眼，系统相关服务却并无异常，令人有些困惑。
字符流：以字符为单位，每次次读入或读出是 16 位数据。其只能读取字符类型数据。
Kafka 使用 Zookeeper 来维护集群成员的信息。每个 broker 都有一个唯一标识符，这个标识符可以在配置文件里指定，也可以自动生成。在 broker 启动的时候，它通过创建临时节点把自己的 ID 注册到 Zookeeper。Kafka 组件订阅 Zookeeper 的 /broker/ids 路径，当有 broker 加入集群或退出集群时，这些组件就可以获得通知。
关于Kafka的一个灵魂拷问：它为什么这么快？或者说，为什么它能做到如此大的吞吐量和如此低的延迟？
Kafka 一直以来都以高吞吐量的特性而家喻户晓，就在上周，在一个性能监控项目中，需要使用到 Kafka 传输海量消息，在这过程中遇到了一个 Kafka Producer 异步发送消息会被阻塞的问题，导致生产端发送耗时很大。
『码哥』的 Redis 系列文章有一篇讲透了 Redis 的性能优化 ——《Redis 核心篇：唯快不破的秘密》。深入地从 IO、线程、数据结构、编码等方面剖析了 Redis “快”的内部秘密。65 哥深受启发，在学习 Kafka 的过程中，发现 Kafka 也是一个性能十分优秀的中间件，遂要求『码哥』讲一讲 Kafka 性能优化方面的知识，所以『码哥』决定将这篇性能方面的博文作为 Kafka 系列的开篇之作。
关于Kafka的一个灵魂拷问：它为什么这么快？ 或者说，为什么它能做到如此大的吞吐量和如此低的延迟？
『码哥』的 Redis 系列文章有一篇讲透了 Redis 的性能优化 ——《Redis 核心篇：唯快不破的秘密》。
Kafka[1]是linkedin用于日志处理的分布式消息队列，linkedin的日志数据容量大，但对可靠性要求不高，其日志数据主要包括用户行为（登录、浏览、点击、分享、喜欢）以及系统运行日志（CPU、内存、磁盘、网络、系统及进程状态）。 当前很多的消息队列服务提供可靠交付保证，并默认是即时消费（不适合离线）。高可靠交付对linkedin的日志不是必须的，故可通过降低可靠性来提高性能，同时通过构建分布式的集群，允许消息在系统中累积，使得kafka同时支持离线和在线日志处理。 注：本文中发布者（publish
以讲解性能作为 Kafka 之旅的开篇之作，让我们一起来深入了解 Kafka “快”的内部秘密。你不仅可以学习到 Kafka 性能优化的各种手段，也可以提炼出各种性能优化的方法论，这些方法论也可以应用到我们自己的项目之中，助力我们写出高性能的项目。
消息队列老大哥Kafka在官网的介绍是这么说的，真是霸气：全球财富前100强公司有超过80%信任并使用Kafka。Kafka目前在GitHub目前也已经有star数27.6k、fork数13.6k。
今天早上到公司的时候，接到开发反馈 DEV 环境所有接口都卡，耗时都在一分钟以上，严重影响开发正常工作，然后通过网关的日志定位到原因是因为 kafka 集群不可用（总共 3 个 broker，前一天晚上机房停电导致 leader 节点挂了），导致网关的反爬过滤器里面发送 kafka 消息的代码 kafkaTemplat.send 阻塞了 60s，当时在想这个 send 方法不是异步的吗，为什么会阻塞 60s？于是查阅了一些资料，大致搞清楚了原因，这里稍作整理，分享给可能踩坑或者以及踩过坑的同学。
线上某服务 A 调用服务 B 接口完成一次交易，一次晚上的生产变更之后，系统监控发现服务 B 接口频繁超时，后续甚至返回线程池耗尽错误 Thread pool is EXHAUSTED。因为服务 B 依赖外部接口，刚开始误以为外部接口延时导致，所以临时增加服务 B dubbo 线程池线程数量。配置变更之后，重启服务，服务恢复正常。一段时间之后，服务 B 再次返回线程池耗尽错误。这次深入排查问题之后，才发现 Kafka 异步发送消息阻塞了 dubbo 线程，从而导致调用超时。
Kafka 是一个分布式的、发布-订阅式消息中间件。最初是由 Linkedin 领英公司基于 Scala 和 Java 语言开发的分布式消息系统，现已捐献给 Apache 软件基金会。事实上 Kafka 不仅仅是一个消息队列（MQ），其已然成为一个开源的分布式流处理平台。Kafka 具有高吞吐、低延迟的特性，许多大数据处理系统比如 Storm、Spark、Flink 等都能很好地与之集成。
Apache Kafka 是一个分布式流处理平台：distributed streaming platform。
消息发送流程 因为Kafka内在就是分布式的，一个Kafka集群通常包括多个代理。为了均衡负载，将话题分成多个分区，每个代理存储一或多个分区。多个生产者和消费者能够同时生产和获取消息。 过程： 1.Producer根据指定的partition方法（round-robin、hash等），将消息发布到指定topic的partition里面 2.kafka集群接收到Producer发过来的消息后，将其持久化到硬盘，并保留消息指定时长（可配置），而不关注消息是否被消费。 3.Consumer从kafka集群pu
Java 框架由一系列可重用的预编写代码组成，它们起着模板的作用，开发人员可以根据需要通过填充自定义代码来创建应用。
本系列主题是大数据开发面试指南，旨在为大家提供一个大数据学习的基本路线，完善数据开发的技术栈，以及我们面试一个大数据开发岗位的时候，哪些东西是重点考察的，这些公司更希望面试者具备哪些技能。
kafka的生产者可以选择使用异步方式发送数据，所谓异步方式，就是我们调用 send() 方法，并指定一个回调函数， 服务器在返回响应时调用该函数。
Apache Kafka 社区正在积极推动一项名为 KIP-932（Kafka Improvement Proposal，KIP）的工作，目的是为这一广受欢迎的消息传递平台引入类似队列的功能。该提案引入共享群组的概念，用于实现协作式消息消费。与此同时，SoftwareMill 提供了一种替代解决方案，能够与现有的消费者群组机制无缝集成。
kafka 使用日志文件的方式来保存生产者和发送者的消息，每条消息都有一个 offset 值来表示它在分区中的偏移量。Kafka 中存储的一般都是海量的消息数据，为了避免日志文件过大，一个分片并不是直接对应在一个磁盘上的日志文件，而是对应磁盘上的一个目录，这个目录的命名规则是_。 比如创建一个名为firstTopic的topic，其中有3个partition，那么在 kafka 的数据目录（/tmp/kafka-log）中就有 3 个目录，firstTopic_0~3 多个分区在集群中多个broker上的分配方法
根据 KafkaProducer 类上的注释上来看 KafkaProducer 具有如下特征：
在上文中介绍了AdminClient API的使用，现在我们已经知道如何在应用中通过API去管理Kafka了。但在大多应用开发中，我们最常面临的场景就是发送消息到Kafka，或者从Kafka中消费消息，也就是典型的生产/消费模式。而本文将要演示的就是如何使用Producer API将消息发送至Kafka中，使应用成为一个生产者。
上篇文章说了，消息压缩可以看分情况进行，判断下服务器cpu空闲还是io空闲较多，如果cpu空闲较多，则考虑消息积压，反之则不考虑。还有消费者组，consumer group，对于同一个group，只会发送一条消息进入一个实例。位移提交在0.9.0.0版本之前是保存到zookeeper，后来版本是保存在内部topic的__consumer offsets。
本文将从消费顺序性这个问题出发，深度剖析 Kafka/RocketMQ 消费线程模型。
作为消息队列，Kafka允许发布和订阅数据，这点和其他消息队列类似，但不同的是，Kafka作为一个分布式系统，是以集群的方式运行的，可以自由伸缩。同时还提供了数据传递保证—可复制、持久化等。
本文收集整理了各大厂常见面试题N道，你想要的这里都有内容涵盖：Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、Spring Boot、Spring Cloud、RabbitMQ、Kafka、Linux 等技术栈，希望大家都能找到适合自己的公司，开开心心的撸代码。
kafka 不能脱离 zookeeper 单独使用，因为 kafka 使用 zookeeper 管理和协调 kafka 的节点服务器。
首先生产者线程main生成消息后调用send方法，然后会经过拦截器、序列化器、分区器（Partition），分区器会对消息进行分区放入不同的本地队列，本地队列保存在计算机的内存中，每个队列32m，每16k数据形成一批消息；
本文介绍了如何利用ELK（Elasticsearch、Logstash、Kibana）技术搭建日志分析平台，以及该平台的一些重要组件和架构设计。同时，还探讨了如何使用Filebeat进行日志收集和传输，以及自研程序如何与ELK集成。
更多内容: https://github.com/pierre94/kafka-notes
最近处理了一次线上故障，具体故障表现就是kafka某个topic消息堆积，这个topic的相关consumer全部掉线。
kafka通过一系列优化，写入和读取速度能够达到数万条/秒。通过增加分区数量，能够通过部署多个消费者增加并行消费能力。但还是有很多情况下，某些业务的执行速度实在是太慢，这个时候我们就要用到多线程去消费，提高应用机器的利用率，而不是一味的给kafka增加压力。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
