Kafka第一篇——内部组件概念架构启动服务器zookeeper选举以及底层原理_kafka集群选举

目录

引入 ——为什么分布式系统需要用第三方软件？

JMS 

对比 

组件

架构推演——备份实现安全可靠 ，

Zookeeper 

controller的选举

 controller和broker底层通信原理

BROKER内部组件 

​编辑 topic创建

---

引入 ——为什么分布式系统需要用第三方软件？

 这里会讨论线程与线程之间的通信以及进程与进程之间的通信。

• 1.线程与线程之间通信，每个线程都有自己的栈空间，共享堆完全可以，通过共享内存来实现消息共享，如下图。

存在的问题：但是如果一个线程t1给堆内存发布数据比较快，接收数据的t2线程接收比较慢，就会导致每秒20条数据被积压来不及处理，积压数据就会导致内存不够用（对吞吐量造成影响，导致系统不稳定，严重情况会导致系统不可用），内存溢出，然后引入磁盘文件，虽然磁盘文件存储的数据比内存多，但也有上限。

• 2.进程和进程之间通过socket（网络数据流）来通信 ，两个不同的进程申请到的内存是不一样的，所以不能像线程那样去共用内存，

存在问题：第一个进程用于生产数据，第二个进程和第三个进程用来接收数据，如果进程1的数据要同时发给进程二和进程3，那进程1就要同时发送两份数据.如果是进程一发送不同的数据给进程2和进程3，就会增加进程1的逻辑处理难度，会增加系统响应的时间，消耗更多的系统资源，耦合性也高·。如果数据重复发送，也会对系统吞吐量造成影响，最根本还是系统资源不太够。这里谈到的问题也就是进程之间直接交互造成的问题，即耦合性高。

所以就引入中间缓冲区——第三方软件，又称为消息中间件，缓冲区的目的就是中转和临时存储，从而降低系统之间的耦合性。解耦合，负载均衡，削峰填谷。

JMS 

kafka没有完全遵循jms思想，但是借鉴了jms思想。

JMS（Java Message Service）是Java平台上用于消息传递的API标准。它定义了一种用于创建、发送、接收和读取消息的方式，使得不同应用程序之间可以通过消息进行通信。JMS的核心思想包括以下几个方面：

1. 消息模型：JMS定义了两种基本消息模型，即点对点模型（Point-to-Point）和 发布/订阅模型（Publish/Subscribe）。点对点模型中，消息被发送到特定的队列，只有一个消费者可以接收并处理消息。发布/订阅模型中，消息被发送到主题（Topic），多个消费者可以订阅主题并接收消息。

2. 消息生产者：负责创建并发送消息到消息中间件。消息生产者将消息发送到指定的队列或主题，并且可能会设置消息的属性、头信息等。

3. 消息消费者：负责从消息中间件接收并处理消息。消息消费者可以根据需要从特定队列或主题中订阅消息，并在消息到达时进行处理。

4. 消息中间件：提供消息传递的基础设施，负责存储、路由和传递消息。消息中间件通常是一个独立的服务器，它提供了可靠的消息传递机制，以及高效的消息路由和处理能力。暂时存储和中转。

Kafka借鉴了JMS的一些思想，比如消息模型中的发布/订阅模型，以及消息的生产者和消费者模式。但Kafka与JMS也有一些不同之处，比如Kafka更加注重持久化和水平扩展等方面的设计。因此，虽然Kafka没有完全遵循JMS的思想，但在某些方面受到了JMS的启发和借鉴。

各类消息中间件对比 

 在 单机吞吐量 方面，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 其实是一个不错的选择。

组件

消息队列就是内存模型，为了数据存储更加可靠，就不能只存储在内存中，引入磁盘文件。这样既保证了数据的高效，也保证了安全可靠。为了不仅仅能存储数据，并且保证数据的顺序不会被打乱，引入了偏移量，方便数据的有序访问，就可以按照某个标记或者某种标记的顺序进行访问，

以下是 Kafka 的一些主要组件：将JMS中的message换成record。

1. Broker：Kafka 集群中的每个节点都是一个 Kafka Broker。Broker 负责存储和管理数据，以及处理来自生产者和消费者的请求。

2. Topic：在 Kafka 中，消息被发布到特定的主题（Topic）。每个主题都是一个逻辑的数据流，可以有一个或多个生产者向其发布消息，并且可以有一个或多个消费者从中读取消息。每个主题可以有多个分区，从而实现消息的水平扩展和并行处理。

3. Producer：生产者是将消息发布到 Kafka 主题的应用程序。生产者负责将消息发送到 Kafka Broker。

4. Consumer：消费者是从 Kafka 主题中读取消息的应用程序。消费者订阅一个或多个主题，并从中拉取消息。

5. Consumer Group：消费者组是一组消费者的集合，它们共同消费一个或多个主题中的消息。Kafka 使用消费者组来实现消息的负载均衡和水平扩展。

6. ZooKeeper：ZooKeeper 是 Kafka 集群的协调服务。它用于管理和协调 Kafka Broker 的状态、主题配置和消费者组的信息。

7. Partition：每个主题可以分成多个分区，每个分区在物理上由一个或多个 Broker 托管。分区使得主题能够水平扩展，允许 Kafka 处理大规模数据流。

8. Replication：Kafka 使用副本来提供容错性和高可用性。每个分区都有一个或多个副本，这些副本被分布在不同的 Broker 上，以防止数据丢失。

这些组件共同构成了 Kafka 的核心架构，使其成为一个高效、可靠的流处理平台。

bin/kafka-topics.sh --create --topic <topic_name> --bootstrap-server <bootstrap_server_address> --partitions <num_partitions> --replication-factor <replication_factor>

<dependencies>
<dependency>
<groupId>org.apache.kafka</groupId><artifactId>kafka-clients</artifactId><version>3.6.1</version>
</dependency>
</dependencies>

架构推演发展历程——备份实现安全可靠 

声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：【wpsshop博客】