2016 年的文章中，我们详细介绍过 rabbitmq，他是一种实现了 AMQP 队列协议的消息队列，具有非常强大的多种功能： rabbitmq 实战
经过上次 Kafka 日志集群某节点重启失败导致某个主题分区不可用的事故之后，这篇文章专门对分区不可用进行故障重现，并给出我的一些骚操作来尽量减少数据的丢失。
在 2 月10 号下午大概 1 点半左右，收到用户方反馈，发现日志 kafka 集群 A 主题 的 34 分区选举不了 leader，
Kafka 中消息是以 topic 进行分类的，生产者生产消息，消费者消费消息，都是面向 topic的。
Kafka在0.8和0.10版本引入了新的消费者API，所以spark Streaming与kafka的整合提供了两个包。 请根据你的集群选用正确的包。注意， 0.8和后期的版本0.9及0.10是兼
Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。Kafka是一种消息队列，主要用来处理大量数据状态下的消息队列，一般用来做日志的处理。
可靠的数据传输是系统的属性之一，不能在事后考虑，就像性能一样，它必须从最初的白板图设计成一个系统，你不能事后把系统抛在一边。更重要的是，可靠性是系统的属性，而不是单个组件的属性，因此即使在讨论apache kafka的可靠性保证时，也需要考虑其各种场景。当谈到可靠性的时候，与kafka集成的系统和kafka本身一样重要。因为可靠性是一个系统问题，它不仅仅是一个人的责任。每个卡夫卡的管理员、linux系统管理员、网络和存储管理员以及应用程序开发人员必须共同来构建一个可靠的系统。 Apache kafka的数据传输可靠性非常灵活。我们知道kafka有很多用例，从跟踪网站点击到信用卡支付。一些用例要求最高的可靠性，而另外一些用例优先考虑四度和简单性而不是可靠性。kafka被设计成足够可配置，它的客户端API足够灵活，允许各种可靠性的权衡。 由于它的灵活性，在使用kafka时也容易意外地出现错误。相信你的系统是可靠的，但是实际上它不可靠。在本章中，我们将讨论不同类型的可靠性以及它们在apache kafka上下文中的含义开始。然后我们将讨论kafka的复制机制，以及它如何有助于系统的可靠性。然后我们将讨论kafka的broker和topic，以及如何针对不同的用例配置它们。然后我们将讨论客户，生产者、消费者以及如何在不同的可靠性场景中使用它们。最后，我们将讨论验证系统可靠性的主体，因为仅仅相信一个系统的可靠是不够的，必须彻底的测试这个假设。
Kafka允许同⼀个Partition存在多个消息副本(Replica)，每个Partition的副本通常由1个Leader及0个以上的Follower组成，⽣产者将 消息直接发往对应Partition的Leader，Follower会周期地向Leader发送同步请求，Kafka的Leader机制在保障数据⼀致性地同时降低了了 消息备份的复杂度； 同⼀Partition的Replica不应存储在同一个Broker上，因为一旦该Broker宕机，对应Partition的所有Replica都无法⼯作，这就达不到 高可用的效果。为了做好负载均衡并提⾼容错能力，Kafka会尽量将所有的Partition以及各Partition的副本均匀地分配到整个集群上；
Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。
消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。
系统间的耦合高怎么办，我们如何不让一个服务过于庞大，一个好的方式就是依据具体的功能模块拆分服务，降低服务的耦合度，服务间的交互可以通过消息传递数据来实现，除此之外Kafka非常适合在线日志收集等高吞吐场景，kafka有更好的吞吐量，内置分区，副本和故障转移，这有利于处理大规模的消息，所以kafka被各大公司广泛运用于消息队列的构建：
大家好，我是 moon，作为在消息中间件中拥有神一样地位的 kafka，你真的了解它吗？
Kafka在可配置数量的服务器上复制每个主题分区的日志（您可以逐个主题地设置此复制因子）。这允许在群集中的服务器发生故障时自动故障转移到这些副本，以便在出现故障时消息仍然可用。
Kafka的存储机制以及可靠性 一、kafka的存储机制 kafka通过topic来分主题存放数据，主题内有分区，分区可以有多个副本，分区的内部还细分为若干个segment。 所谓的分区其实就是在kafka对应存储目录下创建的文件夹，文件夹的名字是主题名加上分区编号，编号从0开始。 1、segment 所谓的segment其实就是在分区对应的文件夹下产生的文件。 一个分区会被划分成大小相等的若干segment，这样一方面保证了分区的数据被划分到多个文件中保证不会产生体积过大的
Kafka是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。在流式计算中，Kafka一般用来缓存数据，Storm通过消费Kafka的数据进行计算。
导语 本文介绍了 Kafka 跨数据中心的两种部署方式，简要分析两种方式下的不同架构以及优缺点，对这些架构可能碰到的问题也提供了一些解决思路；同时也说明了 Kafka 跨数据中心部署的社区解决方案和商业化解决方案。 背景 Kafka 作为世界上最流行的消息中间件之一，一般是客户数据链路中的核心组件，高可用性是客户很关注的因素。近期在对接云上客户时发现，客户对 Kafka 的高可用也有需求，行业架构师也想了解 Kafka 高可用的方案细节；有些客户是需要云上 Kafka 的高可用能力，有些客户需要 IDC
◆ 介绍 几乎所有 Kafka Consumer 教程都是下面的代码： KafkaConsumer<String, Payment> consumer = new KafkaConsumer<>(props) // Subscribe to Kafka topics consumer.subscribe(topics); while (true) { // Poll Kafka for new messages ConsumerRecords<String, String> records
Kafka的存储机制以及可靠性 一、kafka的存储机制 kafka通过topic来分主题存放数据，主题内有分区，分区可以有多个副本，分区的内部还细分为若干个segment。 所谓的分区其实就是在kafka对应存储目录下创建的文件夹，文件夹的名字是主题名加上分区编号，编号从0开始。 1、segment 所谓的segment其实就是在分区对应的文件夹下产生的文件。 一个分区会被划分成大小相等的若干segment，这样一方面保证了分区的数据被划分到多个文件中保证不会产生体积过大
作为全球新冠疫情数据的实时统计的权威，约翰斯—霍普金斯大学的实时数据一直是大家实时关注的，也是各大媒体的主要数据来源。在今天早上的相当一段长的时间，霍普金斯大学的全球疫情分布大屏中显示，全球确诊人数已经突破200万。
现如今，Kafka 作为一个高性能、高可靠性、分布式的消息队列系统，广泛地被应用于大规模互联网服务中，如 Tencent、Facebook、LinkedIn、Netflix、Airbnb 等知名公司。然而，在大规模的分布式系统中，服务的不可预测性、复杂性和耦合性经常会导致一些不可预测的故障事件。当Kafka Broker节点宕机时，可能会出现以下故障：
分布式实时消息队列Kafka（四） 知识点01：课程回顾 Kafka中生产者的数据分区规则是什么？ 先判断是否指定了分区 指定分区：写入对应分区 没有指定：判断是否指定了Key 指定了Key：按照Key的Hash分区 没有指定Key：按照黏性分区 特点：优先将所有数据构建一个Batch，提交到一个分区中，尽量保证数据分配均衡 自定义分区规则 step1：开发一个类实现Partitioner step2：实现一个partition方法 ste
大家好，我是梦想家Alex，今天为大家带来面试过程中关于 Kafka 核心知识灵魂 16 问 ~ 内容较丰富，建议转发收藏。
在实际项目中，无论使用Storm还是SparkStreaming与Flink，主要从Kafka实时消费数据进行处理分析，流式数据实时处理技术架构大致如下：
Apache Kafka是由LinkedIn采用Scala和Java开发的开源流处理（open source、 stream-processing）平台，该项目旨在提供统一的、高吞吐量、低延迟的平台来处理实时数据流。
producer发送消息完，只等待lead写入成功就返回了，leader crash了，这时follower没来及同步，消 息丢失。
对于Kafka中的分区而言，它的每条消息都有唯一的offset，用来表示消息在分区中对应的位置。对于消费者而言，它也有一个offset的概念，消费者使用offset来表示消费到分区中某个消息所在的位置。在Kafka中其实有关于offset有两个含义。我这里主要分享消费者提交offset问题。首先我们来看一下issue：https://github.com/confluentinc/confluent-kafka-go/issues/195，涉及到问题：Why CommitOffsets() does not increment the offset like Commit()【为什么CommitOffsets和Commit方法一样不能增加offset】。里面有个正确答案：提交的offset等于msg.offset+1。为什么是这样的呢？我们来深入了解一下。
行为日志在这个大数据时代的作用日益重要，怎样更好的收集、存储、管理日志也是值得研究的一个问题，大型互联网公司一般都有成熟的日志聚合方案，但是每个公司尤其是中小型公司都要针对自己的应用场景来做技术选型，本文主要针对中小型公司如何以较小的成本快速构建一个行为日志聚合体系以及在建立日志聚合过程中要处理哪些问题。
日常开发中，相信大家都对 Kafka 有所耳闻，Kafka 作为一个分布式的流处理平台，一般用来存储和传输大量的消息数据。在 Kafka 中有三个重要概念，分别是 topic、partition 和 offset。
我们都知道Kafka的吞吐量很大，但是Kafka究竟会不会丢失消息呢？又会不会重复消费消息呢？
多分区原子写入： 事务能够保证Kafka topic下每个分区的原⼦写⼊。事务中所有的消息都将被成功写⼊或者丢弃。 ⾸先，我们来考虑⼀下原⼦读取-处理-写⼊周期是什么意思。简⽽⾔之，这意味着如果某个应⽤程序在某个topic tp0的偏移量X处读取到了消息A，并且在对消息A进⾏了⼀些处理（如B = F（A）），之后将消息B写⼊topic tp1，则只有当消息A和B被认为被成功地消费并⼀起发布，或者完全不发布时，整个读取过程写⼊操作是原⼦的。 现在，只有当消息A的偏移量X被标记为已消费，消息A才从topic tp0消费，消费到的数据偏移量（record offset）将被标记为提交偏移量（Committing offset）。在Kafka中，我们通过写⼊⼀个名为offsets topic的内部Kafka topic来记录offset commit。消息仅在其offset被提交给offsets topic时才被认为成功消费。 由于offset commit只是对Kafka topic的另⼀次写⼊，并且由于消息仅在提交偏移量时被视为成功消费，所以跨多个主题和分区的原⼦写⼊也启⽤原⼦读取-处理-写⼊循环：提交偏移量X到offset topic和消息B到tp1的写⼊将是单个事务的⼀部分，所以整个步骤都是原⼦的。
一、kafka基础介绍 Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 kafka是一种高吞吐量的分
许久不见，各位读者，上次更文已经是去年了，快两个月没发文章了，谢谢大家没有取关。没有加我微信的朋友，可能不知道我于去年12月当上了爸爸，算是我人生的一个重大变化。工作还未满两年，在25岁成为了父亲，还是挺有压力的，会有紧张感，所以也停更了一段时间，好好整理自己。现在我回来啦！今年还是会好好写文章，分享有价值的文章给读者。希望能提高自己的输出频率，多多输出，一起进步！
https://www.cnblogs.com/bainianminguo/p/12247158.html
需要server.properties中设置delete.topic.enable=true否则只是标记删除。
所谓的消息幂等性就是如何保证消息只消费一次不重复消费。这需要从Kafka的多个角度去回答该问题一是要包含Kafka自身的机制，还需要考虑客户端自己的重复处理。
Kafka的bin目录下shell脚本是kafka自带的管理工具，提供topic的创建/删除/配置修改、消费者的监控、分区重载、集群健康监控、收发端TPS压测、跨机房同步等能力，Kafka运维者可以使用这些工具进行集群的管理。
Flink内置了一些基本数据源和接收器，并且始终可用。该预定义的数据源包括文件，目录和插socket，并从集合和迭代器摄取数据。该预定义的数据接收器支持写入文件和标准输入输出及socket。
Kafka 是一个分布式的发布-订阅消息系统。它最初是在 LinkedIn 开发的，2011年7月成为一个 Apache 项目。今天，Kafka 被 LinkedIn、 Twitter 和 Square 用于日志聚合、队列、实时监控和事件处理等应用程序。在下面的文章中，我们将讨论下 Kafka 的 replication 设计。
在当今信息爆炸的时代，单台计算机已经无法负载日益增长的业务发展，虽然也有性能强大的超级计算机，但是这种高端机不仅费用高昂，也不灵活，一般的企业是负担不起的，而且也损失不起，那么将一群廉价的普通计算机组合起来，让它们协同工作就像一台超级计算机一样地对外提供服务，就成了顺其自然的设想，但是这又增加了软件的复杂度，要求开发的软件需要具备横向扩展能力，比如：Kafka、Elasticsearch、Zookeeper等就属于这一类软件，它们天生都是"分布式的"，即可以通过添加机器节点来共同地分摊数据存储和负载压力。
Kafka 最初由LinkedIn公司开发的，并于 2010 年贡献给了 Apache 基金会，之后成为 Apache 顶级项目。
当添加一个分区或分区增加副本的时候，都要从所有副本中选举一个新的Leader出来。
如上图所示： 一个典型的 Kafka 集群中包含若干 Producer（可以是 web 前端产生的 Page View，或者是服务器日志，系统 CPU、Memory 等）； 若干 broker（Kafka 支持水平扩展，一般 broker 数量越多，集群吞吐率越高），若干 Consumer Group，以及一个 Zookeeper 集群； Kafka 通过 Zookeeper 管理集群配置，选举 leader，以及在 Consumer Group 发生变化时进行 rebalance； Producer 使用 push 模式将消息发布到 broker，Consumer 使用 pull 模式从 broker 订阅并消费消息；
Apache Kafka 是一个分布式的流处理平台（分布式的基于发布/订阅模式的消息队列【Message Queue】）。
导语 熟悉Apache Kafka的同学都知道，当Kafka集群负载到达瓶颈或者出现突发流量需要紧急扩容时，新加入集群的节点需要经过数据迁移才能均分集群压力。而数据迁移会因为数据堆积量，节点负载等因素的影响，导致迁移时间较长，甚至出现迁移不动的情况。同时数据迁移也会增大当前节点的压力，可能导致集群进一步崩溃。本文将探讨应对需要紧急扩容的技术方案。 作者介绍 许文强 腾讯高级工程师 腾讯云CKafka研发负责人，Apache Kafka Contributor 拥有多年分布式系统研发经验，主要
在 Kafka 中还有两个特别重要的概念—主题（Topic）与分区（Partition）。Kafka 中的消息以主题为单位进行归类，生产者负责将消息发送到特定的主题（发送到 Kafka 集群中的每一条消息都要指定一个主题），而消费者负责订阅主题并进行消费。这里补充了对Kafka基本概念了解，附上上篇中的Kafka 体系结构概要图便于理解
我们需要将producer发送的数据封装成一个ProducerRecord对象
在zk中会保存AR（Assigned Replicas）列表，其中包含了分区所有的副本，其中 AR = ISR+OSR
Spark Streaming 是一种构建在 Spark 上的实时计算框架，它扩展了 Spark 处理大规模流式数据的能力。Spark Streaming 的优势在于：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
