在使用Apache Kafka时，你可能会遇到一个名为 "NoBrokersAvailableError" 的异常。这篇博客文章将深入讲解这个错误的原因、可能的解决方法以及如何避免它。
MirrorMaker 为Kafka 内置的跨集群/机房数据复制工具，二进制包解压后bin目录下有kafka-mirror-maker.sh，Mirror Maker启动后，包含了一组消费者，这些消费者属于同一个group，并从多个topic上读取数据，所有的topic均使用该group.id，每个MirrorMaker 进程仅有一个生产者，该生产者将数据发送给目标集群的多个topic；
生产者又名Producer，生产者生成的数据由topic进行标识管理，topic的数据可以通过设置分区写入数据到不同的分区中去。
数据中心宕机和数据丢失能导致企业损失很多收入或者完全停摆。为了将由于事故导致的宕机和数据丢失带来的损失最小化，企业需要制定业务可持续性计划和灾难恢复策略。
Hyperledger Fabric推荐Kafa用于生产环境。Kafa是一个分布式、具有水平伸缩能力、崩溃容错能力 的日志系统。在Hyperledger Fabric区块链中可以有多个Kafka节点，使用zookeeper进行同步管理。 本文将介绍Kfaka的基本工作原理，以及在Hyperledger Fabric中使用Kafka和zookeeper实现共识的原理，并通过一个实例剖析Hyperledger Farbic中Kafka共识的达成过程。
本书大部分内容都在讨论单个kafka集群的配置、维护和使用。但是，在一些场景中，可能需要多集群架构。 在某些情况下，集群是完全分离的，他们属于不同部门的不同实例，没有理由将数据从一个集群复制到另外一个集群。有时，不同的SLA或者工作负载使得单个集群提供多个用例服务的集群很难调优。在某些时候，还有不同的安全需求。这些场景非常容易管理多个不同的集群，就像多次允许单个集群一样。 在其他场景中，不同的集群是互相依赖的，管理有要不断地在集群之间复制数据。在大多数数据库中，在数据库服务之间持续复制数据称为复制。由于我们使用复制来描述属于同一集群的kafka节点之间的数据移动，因此我们将把kafak集群之间的数据复制称之为镜像。Apache kafka内置的跨集群 的复制器称为mirrormaker。 在本章中，我们将讨论所有或者部分数据的跨集群镜像。我们将首先讨论跨集群的镜像的一些常用用例。然后我们将展示一些用于实现这些用例的架构，并讨论每种架构的优缺点。然后我们将讨论MirrorMaker本书以及如何使用它。我们将分享一些操作技巧，包括部署的性能调优。最后我们将讨论mirrorMaker的一些替代方案。
一、消息队列 Apache Pulsar Pulsar 与 Kafka 对比 二、Kafka基础 三、Kafka架构及组件 四、Kafka集群操作 五、Kafka的JavaAPI操作 六、Kafka中的数据不丢失机制 七、Kafka配置文件说明 八、CAP理论 九、Kafka中的CAP机制 十、Kafka监控及运维 十一、Kafka大厂面试题
Kafka 起初是 由 LinkedIn 公司采用 Scala 语言开发的一个多分区、多副本且基于 ZooKeeper 协调的分布式消息系统，现已被捐献给 Apache 基金会。目前 Kafka 已经定位为一个分布式流式处理平台，它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性而被广泛使用。目前越来越多的开源分布式处理系统如 Cloudera、Storm、Spark、Flink 等都支持与 Kafka 集成。
上一阶段给大家讲的是Redis，接下来这一阶段，我给你大家更新Kafka的知识分享哦!!!
1. 介绍 最近在研究一些消息中间件，常用的MQ如RabbitMQ,ActiveMQ,Kafka等。NSQ是一个基于Go语言的分布式实时消息平台，它基于MIT开源协议发布，由bitly公司开源出来的一款简单易用的消息中间件。 官方和第三方还为NSQ开发了众多客户端功能库，如官方提供的基于HTTP的nsqd、Go客户端go-nsq、Python客户端pynsq、基于Node.js的JavaScript客户端nsqjs、异步C客户端libnsq、Java客户端nsq-java以及基于各种语言的众多第三方客户端功
kafka相关概念图 重点： kafka里的副本针对的是分区来做的， 副本不提供对外的服务，只记录消息数据，kafka通过对topic分区来实现消息系统的负载。
作为快速入门Kafka系列的第六篇博客，本篇为大家带来的是Kafka的JavaAPI操作~
Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。
在这个博客系列的第1部分之后，Apache Kafka的Spring——第1部分:错误处理、消息转换和事务支持，在这里的第2部分中，我们将关注另一个增强开发者在Kafka上构建流应用程序时体验的项目:Spring Cloud Stream。
Kafka 起初是由 LinkedIn 公司采用 Scala 语言开发的一个多分区、多副本且基于 Zookeeper 协调的分布式消息系统，现已被捐献给 Apache 基金会。目前 Kafka 已经定位为一个分布式流式处理平台，它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性被广泛使用。目前越来越多的开源式分布处理系统如：Storm、Spark、Flink 等都支持与 Kafka 集成。
非底层操作系统软件，非业务应用软件，不是直接给最终用户使用的，不能直接给客户带来价值的软件统称为中间件。
在实际项目中，无论使用Storm还是SparkStreaming与Flink，主要从Kafka实时消费数据进行处理分析，流式数据实时处理技术架构大致如下：
首先，我们需要创建一个Kafka服务来管理我们的Kafka集群。可以使用Kubernetes的Service资源来定义一个Kafka服务，如下所示：
Apache Kafka有许多针对其操作的度量，这些度量指标非常多，会让人混淆哪些是重要的，哪些是可以忽略的。这些度量的范围从关于通信量总体速率的简单度量，到针对每种请求类型的详细时间度量，再到每个topic和每个分区的度量。他们提供了broker中的每个操作的详细视图，但也可能使你成为负责管理监视系统的人员的缺点。 本节将详细介绍一直要监控的最关键的度量标准，以及如何响应他们。我们还将描述一些再调试问题的时候需要账务的更重要的度量标准，然而，这并不是可用的度量标准的详细列表，因为列表经常发生变化，而且其中有许多只对硬编码的kafka开放人员有用。
在现代的分布式系统和实时数据处理领域，消息中间件扮演着关键的角色，用于解决应用程序之间的通信和数据传递的挑战。在众多的消息中间件解决方案中，Kafka、ZeroMQ和RabbitMQ 是备受关注和广泛应用的代表性系统。它们各自具有独特的特点和优势，适用于不同的应用场景和需求。
本章节描述了如何安装apache kafka的broker,以及如何设置apache zookeeper,zookeeper被用于存储broker的元数据。本章节还将介绍kafka的基本配置，以及broker运行的硬件标准。最后，我们将介绍多实例集群的安装方法，以及在生产环节中使用kafka时需要注意的一些问题。
Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。 Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
oldproducer是生产者scala版本的生产者，支持同步模式，和异步模式，通过实行producer.type进行配置。
1.kafka消费者编程模型 分区消费模型 组(group)消费模型 1.1.分区消费模型 1.1.1.分区消费架构图，每个分区对应一个消费者。 1.1.2.分区消费模型伪代码描述 指定偏移量，用于
在没有使用消息系统之前，许多传统的系统业务对于消息的处理一般会采用串行方式或者并行方法；
解耦：A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃…A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
之前的版本：0.7.x，0.8.0，0.8.1.X，0.8.2.X，0.9.0.X，0.10.0.X。
Kafka 是由 Linkedin 公司开发的，它是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式消息流平台，它同时也是一款开源的基于发布订阅模式的消息引擎系统。
我在之前《Kafka源码阅读的一些小提示》写了一些关于Kafka源码阅读的注意事项。
KafkaProducer 是线程安全的，可以在多个线程中共享单个 KafkaProducer 实例，也可以将 KafkaProducer 实例进行池化来供其他线程调用。
消息发送者生产消息发送到消息队列中，然后消息接收者从消息队列中取出并且消费消息。消息被消费以后，消息队列中不再有存储，所以消息接收者不可能消费到已经被消费的消息。
公众号改版后文章乱序推荐，希望你可以点击上方“Java进阶架构师”，点击右上角，将我们设为★“星标”！这样才不会错过每日进阶架构文章呀。
流式应用特性就是流处理，通过kafka stream topic和topic之间内部转换。简单理解就是：
Kafka第一天课堂笔记 Kafka简介 消息队列 消息队列——用于存放消息的组件 程序员可以将消息放入到队列中，也可以从消息队列中获取消息 很多时候消息队列不是一个永久性的存储，是作为临时存储存在的（设定一个期限：设置消息在MQ中保存10天） 消息队列中间件：消息队列的组件，例如：Kafka、Active MQ、RabbitMQ、RocketMQ、ZeroMQ Kafka的应用场景 异步处理 可以将一些比较耗时的操作放在其他系统中，通过消息队列将需要进行处理的消息进行存储，其他系统可以消费消息队列
（1）解耦：将系统按照不同的业务功能拆分出来，消息生产者只管把消息发布到 MQ 中而不用管谁来取，消息消费者只管从 MQ 中取消息而不管是谁发布的。消息生产者和消费者都不知道对方的存在；
高吞吐量、低延迟每个topic可以分多个partition, consumer group 对partition进行consume操作。
我们先看一下维基百科是怎么说的： Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，[这使它作为企业级基础设施来处理流式数据非常有价值。此外，Kafka可以通过Kafka Connect连接到外部系统（用于数据输入/输出），并提供了Kafka Streams——一个Java流式处理库。看完这个说法，是不是有点一脸蒙蔽， 再看看其他大神的理解：Kafka 是由 Linkedin 公司开发的，它是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式消息流平台，它同时也是一款开源的基于发布订阅模式的消息引擎系统。 总的来说就是他就是发布订阅消息的引擎系统，在做集群的时候需要依靠zookeeper。
关于SparkStreaming从理论到实战的部分，博主已经在前面的博客中介绍了。本篇博客，为大家带来的是SparkStreaming整合Kafka的教程!
消息队列不知道大家看到这个词的时候，会不会觉得它是一个比较高端的技术。消息队列，一般会简称为 MQ（Message Queue）。消息队列是一种帮助开发人员解决系统间异步通信的中间件，常用于解决系统解耦和请求的削峰平谷的问题。
Flink内置了一些基本数据源和接收器，并且始终可用。该预定义的数据源包括文件，目录和插socket，并从集合和迭代器摄取数据。该预定义的数据接收器支持写入文件和标准输入输出及socket。
本文只包含Kafka入门使用导学，后续会继续整理Kafka进阶知识与底层原理剖析。
RabbitMQ基于主从模式实现高可用。RabbitMQ有三种模式：单机模式，普通集群模式，镜像集群模式。
消息队列是一种在应用程序之间进行通信的技术，允许将消息从一个应用程序发送到另一个应用程序，而无需明确的连接这些应用程序。消息队列中的消息被存储在一种称为队列的数据结构中，这些消息在队列中保留，直到被消费者接收。这使得消息的发送者和接收者能够异步地通信，而不必等待对方的响应，从而提高了系统的可伸缩性和弹性。消息队列还可以通过实现各种模式（例如发布/订阅模式、请求/响应模式等）来支持不同类型的应用程序通信。
为了理解Kafka是如何做到以上所说的功能，从下面开始，我们将深入探索Kafka的特性。
Java面试总结汇总，整理了包括Java基础知识，集合容器，并发编程，JVM，常用开源框架Spring，MyBatis，数据库，中间件等，包含了作为一个Java工程师在面试中需要用到或者可能用到的绝大部分知识。欢迎大家阅读，本人见识有限，写的博客难免有错误或者疏忽的地方，还望各位大佬指点，在此表示感激不尽。文章持续更新中…
作为快速入门Kafka系列的第三篇博客，本篇为大家带来的是Kafka架构之宏微观分析~
领取专属 10元无门槛券
手把手带您无忧上云
