Kafka第一篇——内部组件概念架构启动服务器zookeeper选举以及底层原理
目录引入 ——为什么分布式系统必要用第三方软件？
JMS
对比
组件
架构推演——备份实现安全可靠 ，
Zookeeper
controller的选举
controller和broker底层通讯原理
BROKER内部组件
编辑 topic创建
引入 ——为什么分布式系统必要用第三方软件？
这里会讨论线程与线程之间的通讯以及进程与进程之间的通讯。
[*]1.线程与线程之间通讯，每个线程都有自己的栈空间，共享堆完全可以，通过共享内存来实现消息共享，如下图。https://img-blog.csdnimg.cn/direct/1b4629397d2249f09c5437868cdc60d2.png
存在的题目：但是假如一个线程t1给堆内存发布数据比较快，接收数据的t2线程接收比较慢，就会导致每秒20条数据被积蓄来不及处理，积蓄数据就会导致内存不敷用（对吞吐量造成影响，导致系统不稳定，严重情况会导致系统不可用），内存溢出，然后引入磁盘文件，固然磁盘文件存储的数据比内存多，但也有上限。https://img-blog.csdnimg.cn/direct/f7701ea4e5c543db96e1df9ae6a47cad.png
[*]2.进程和进程之间通过socket（网络数据流）来通讯 ，两个差别的进程申请到的内存是不一样的，所以不能像线程那样去共用内存，
存在题目：第一个进程用于生产数据，第二个进程和第三个进程用来接收数据，假如进程1的数据要同时发给进程二和进程3，那进程1就要同时发送两份数据.假如是进程一发送差别的数据给进程2和进程3，就会增长进程1的逻辑处理难度，会增长系统相应的时间，消耗更多的系统资源，耦合性也高·。假如数据重复发送，也会对系统吞吐量造成影响，最根本还是系统资源不太够。这里谈到的题目也就是进程之间直接交互造成的题目，即耦合性高。
所以就引入中间缓冲区——第三方软件，又称为消息中间件，缓冲区的目标就是中转和临时存储，从而低落系统之间的耦合性。解耦合，负载均衡，削峰填谷。https://img-blog.csdnimg.cn/direct/8b5d2d88684c49c6a14a0cf41ceb9020.png
JMS
kafka没有完全遵循jms思想，但是鉴戒了jms思想。https://img-blog.csdnimg.cn/direct/58408ce9cd9c43bca6f0ad1ba478a251.png
JMS（Java Message Service）是Java平台上用于消息传递的API尺度。它界说了一种用于创建、发送、接收和读取消息的方式，使得差别应用程序之间可以通过消息举行通讯。JMS的核心思想包括以下几个方面：
[*] 消息模型：JMS界说了两种基本消息模型，即点对点模型（Point-to-Point）和 发布/订阅模型（Publish/Subscribe）。点对点模型中，消息被发送到特定的队列，只有一个消费者可以接收并处理消息。发布/订阅模型中，消息被发送到主题（Topic），多个消费者可以订阅主题并接收消息。https://img-blog.csdnimg.cn/direct/6362661bb30b4261bb5efe878e90e498.png
[*] 消息生产者：负责创建并发送消息到消息中间件。消息生产者将消息发送到指定的队列或主题，并且可能会设置消息的属性、头信息等。
[*] 消息消费者：负责从消息中间件接收并处理消息。消息消费者可以根据必要从特定队列或主题中订阅消息，并在消息到达时举行处理。
[*] 消息中间件：提供消息传递的基础设施，负责存储、路由和传递消息。消息中间件通常是一个独立的服务器，它提供了可靠的消息传递机制，以及高效的消息路由和处理能力。临时存储和中转。
Kafka鉴戒了JMS的一些思想，好比消息模型中的发布/订阅模型，以及消息的生产者和消费者模式。但Kafka与JMS也有一些差别之处，好比Kafka更加注意持久化和水平扩展等方面的设计。因此，固然Kafka没有完全遵循JMS的思想，但在某些方面受到了JMS的启发和鉴戒。
各类消息中间件对比
https://img-blog.csdnimg.cn/direct/ae1df0fe509444208c6c1efc098463d8.png https://img-blog.csdnimg.cn/direct/c964304f56b842ac9aa9b6c0b6efc6fd.png
在 单机吞吐量 方面，activemq,rabbitmq要比rocketmq,kafka第一个数量级，rocketmq和Kafka都是十万级吞吐量，支持高吞吐。
在 消息可靠性 方面，rocketmq和Kafka可以通过参数优化配置，做到0丢失。rabbitmq基本不丢失，activemq有较低的概率丢失数据。
在 时效性 方面，rabbitmq可以达到微秒级别，其他都是毫秒级别。
在 topic主题分区数量对吞吐量的影响 方面上，对于rocketmq,topic数量可以达到几百/几千量级，但是对于Kafka，topic数量可以达到几百，假如再多的话，吞吐量会大幅度下降。
在 可用性 方面，rocketmq和Kafka的可用性非常高，支持分布式架构，rabbitmq和activemq的可用性高，支持分布式架构，
功能支持 方面以及其他方面。
rocketmq是阿里开发，社区活泼度不高，mq功能较为完整，分布式，扩展性好。
Kafka是开源的，社区活泼度极高，高吞吐量，只是鉴戒了jms规范，并没有完全的服从，所以只支持简单的mq功能，在大数据领域应用广泛。、
rabbitmq开源稳定，社区活泼度高，并发能力强，延时低，性能极好。
通过上面各种消息中间件的对比，大概可以了解，在大数据场景中我们紧张采用 kafka 作为消息中间件，而在JaveEE开发中我们紧张采用 ActiveMQ、RabbitMQ、RocketMQ作为消息中间件。假如将 JavaEE和大数据在项目中举行融合的话，那么 Kafka 其实是一个不错的选择。
组件
https://img-blog.csdnimg.cn/direct/6f6405ef3e3343eab2265115c4294276.png消息队列就是内存模型，为了数据存储更加可靠，就不能只存储在内存中，引入磁盘文件。如许既包管了数据的高效，也包管了安全可靠。为了不但仅能存储数据，并且包管数据的顺序不会被打乱，引入了偏移量，方便数据的有序访问，就可以按照某个标记或者某种标记的顺序举行访问，
以下是 Kafka 的一些紧张组件：将JMS中的message换成record。
[*] Broker：Kafka 集群中的每个节点都是一个 Kafka Broker。Broker 负责存储和管理数据，以及处理来自生产者和消费者的哀求。
[*] Topic：在 Kafka 中，消息被发布到特定的主题（Topic）。每个主题都是一个逻辑的数据流，可以有一个或多个生产者向其发布消息，并且可以有一个或多个消费者从中读取消息。每个主题可以有多个分区，从而实现消息的水平扩展和并行处理。
[*] Producer：生产者是将消息发布到 Kafka 主题的应用程序。生产者负责将消息发送到 Kafka Broker。
[*] Consumer：消费者是从 Kafka 主题中读取消息的应用程序。消费者订阅一个或多个主题，并从中拉取消息。
[*] Consumer Group：消费者组是一组消费者的聚集，它们共同消费一个或多个主题中的消息。Kafka 利用消费者组来实现消息的负载均衡和水平扩展。
[*] ZooKeeper：ZooKeeper 是 Kafka 集群的协调服务。它用于管理和协调 Kafka Broker 的状态、主题配置和消费者组的信息。
[*] Partition：每个主题可以分成多个分区，每个分区在物理上由一个或多个 Broker 托管。分区使得主题能够水平扩展，允许 Kafka 处理大规模数据流。
[*] Replication：Kafka 利用副原来提供容错性和高可用性。每个分区都有一个或多个副本，这些副本被分布在差别的 Broker 上，以防止数据丢失。
这些组件共同构成了 Kafka 的核心架构，使其成为一个高效、可靠的流处理平台。
https://img-blog.csdnimg.cn/direct/a9f73e6285a143e8bc887ff4b89dd65e.png
bin/kafka-topics.sh --create --topic <topic_name> --bootstrap-server <bootstrap_server_address> --partitions <num_partitions> --replication-factor <replication_factor>
https://img-blog.csdnimg.cn/direct/66c45cb897974e808787481242af8415.png
https://img-blog.csdnimg.cn/direct/6faa6b4111274f12bff962412abcaa06.png
<dependencies>
<dependency>
<groupId>org.apache.kafka</groupId><artifactId>kafka-clients</artifactId><version>3.6.1</version>
</dependency>
</dependencies> 架构推演发展进程——备份实现安全可靠
页:
[1]