做淘客网站用备案,广宁城乡建设网站,常州网站开发公司推荐,长沙排名推广目录 引入 ——为什么分布式系统需要用第三方软件#xff1f; JMS 对比 组件 架构推演——备份实现安全可靠 #xff0c; Zookeeper controller的选举 controller和broker底层通信原理 BROKER内部组件 编辑 topic创建 引入 ——为什么分布式系统需要用第三方软件#… 目录 引入 ——为什么分布式系统需要用第三方软件 JMS 对比 组件 架构推演——备份实现安全可靠 Zookeeper controller的选举 controller和broker底层通信原理 BROKER内部组件 编辑 topic创建 引入 ——为什么分布式系统需要用第三方软件 这里会讨论线程与线程之间的通信以及进程与进程之间的通信。 1.线程与线程之间通信每个线程都有自己的栈空间共享堆完全可以通过共享内存来实现消息共享如下图。 存在的问题但是如果一个线程t1给堆内存发布数据比较快接收数据的t2线程接收比较慢就会导致每秒20条数据被积压来不及处理积压数据就会导致内存不够用对吞吐量造成影响导致系统不稳定严重情况会导致系统不可用内存溢出然后引入磁盘文件虽然磁盘文件存储的数据比内存多但也有上限。 2.进程和进程之间通过socket网络数据流来通信 两个不同的进程申请到的内存是不一样的所以不能像线程那样去共用内存 存在问题第一个进程用于生产数据第二个进程和第三个进程用来接收数据如果进程1的数据要同时发给进程二和进程3那进程1就要同时发送两份数据.如果是进程一发送不同的数据给进程2和进程3就会增加进程1的逻辑处理难度会增加系统响应的时间消耗更多的系统资源耦合性也高·。如果数据重复发送也会对系统吞吐量造成影响最根本还是系统资源不太够。这里谈到的问题也就是进程之间直接交互造成的问题即耦合性高。 所以就引入中间缓冲区——第三方软件又称为消息中间件缓冲区的目的就是中转和临时存储从而降低系统之间的耦合性。解耦合负载均衡削峰填谷。 JMS kafka没有完全遵循jms思想但是借鉴了jms思想。 JMSJava Message Service是Java平台上用于消息传递的API标准。它定义了一种用于创建、发送、接收和读取消息的方式使得不同应用程序之间可以通过消息进行通信。JMS的核心思想包括以下几个方面 消息模型JMS定义了两种基本消息模型即点对点模型Point-to-Point和 发布/订阅模型Publish/Subscribe。点对点模型中消息被发送到特定的队列只有一个消费者可以接收并处理消息。发布/订阅模型中消息被发送到主题Topic多个消费者可以订阅主题并接收消息。 消息生产者负责创建并发送消息到消息中间件。消息生产者将消息发送到指定的队列或主题并且可能会设置消息的属性、头信息等。 消息消费者负责从消息中间件接收并处理消息。消息消费者可以根据需要从特定队列或主题中订阅消息并在消息到达时进行处理。 消息中间件提供消息传递的基础设施负责存储、路由和传递消息。消息中间件通常是一个独立的服务器它提供了可靠的消息传递机制以及高效的消息路由和处理能力。暂时存储和中转。 Kafka借鉴了JMS的一些思想比如消息模型中的发布/订阅模型以及消息的生产者和消费者模式。但Kafka与JMS也有一些不同之处比如Kafka更加注重持久化和水平扩展等方面的设计。因此虽然Kafka没有完全遵循JMS的思想但在某些方面受到了JMS的启发和借鉴。 各类消息中间件对比 在 单机吞吐量 方面activemq,rabbitmq要比rocketmq,kafka第一个数量级rocketmq和Kafka都是十万级吞吐量支持高吞吐。 在 消息可靠性 方面rocketmq和Kafka可以通过参数优化配置做到0丢失。rabbitmq基本不丢失activemq有较低的概率丢失数据。 在 时效性 方面rabbitmq可以达到微秒级别其他都是毫秒级别。 在 topic主题分区数量对吞吐量的影响 方面上对于rocketmq,topic数量可以达到几百/几千量级但是对于Kafkatopic数量可以达到几百如果再多的话吞吐量会大幅度下降。 在 可用性 方面rocketmq和Kafka的可用性非常高支持分布式架构rabbitmq和activemq的可用性高支持分布式架构 功能支持 方面以及其他方面。 rocketmq是阿里开发社区活跃度不高mq功能较为完整分布式扩展性好。 Kafka是开源的社区活跃度极高高吞吐量只是借鉴了jms规范并没有完全的遵守所以只支持简单的mq功能在大数据领域应用广泛。、 rabbitmq开源稳定社区活跃度高并发能力强延时低性能极好。 通过上面各种消息中间件的对比大概可以了解在大数据场景中我们主要采用 kafka 作为消息中间件而在JaveEE开发中我们主要采用 ActiveMQ、RabbitMQ、RocketMQ作为消息中间件。如果将 JavaEE和大数据在项目中进行融合的话那么 Kafka 其实是一个不错的选择。 组件 消息队列就是内存模型为了数据存储更加可靠就不能只存储在内存中引入磁盘文件。这样既保证了数据的高效也保证了安全可靠。为了不仅仅能存储数据并且保证数据的顺序不会被打乱引入了偏移量方便数据的有序访问就可以按照某个标记或者某种标记的顺序进行访问 以下是 Kafka 的一些主要组件将JMS中的message换成record。 BrokerKafka 集群中的每个节点都是一个 Kafka Broker。Broker 负责存储和管理数据以及处理来自生产者和消费者的请求。 Topic在 Kafka 中消息被发布到特定的主题Topic。每个主题都是一个逻辑的数据流可以有一个或多个生产者向其发布消息并且可以有一个或多个消费者从中读取消息。每个主题可以有多个分区从而实现消息的水平扩展和并行处理。 Producer生产者是将消息发布到 Kafka 主题的应用程序。生产者负责将消息发送到 Kafka Broker。 Consumer消费者是从 Kafka 主题中读取消息的应用程序。消费者订阅一个或多个主题并从中拉取消息。 Consumer Group消费者组是一组消费者的集合它们共同消费一个或多个主题中的消息。Kafka 使用消费者组来实现消息的负载均衡和水平扩展。 ZooKeeperZooKeeper 是 Kafka 集群的协调服务。它用于管理和协调 Kafka Broker 的状态、主题配置和消费者组的信息。 Partition每个主题可以分成多个分区每个分区在物理上由一个或多个 Broker 托管。分区使得主题能够水平扩展允许 Kafka 处理大规模数据流。 ReplicationKafka 使用副本来提供容错性和高可用性。每个分区都有一个或多个副本这些副本被分布在不同的 Broker 上以防止数据丢失。 这些组件共同构成了 Kafka 的核心架构使其成为一个高效、可靠的流处理平台。 bin/kafka-topics.sh --create --topic topic_name --bootstrap-server bootstrap_server_address --partitions num_partitions --replication-factor replication_factordependencies
dependency
groupIdorg.apache.kafka/groupIdartifactIdkafka-clients/artifactIdversion3.6.1/version
/dependency
/dependencies
架构推演发展历程——备份实现安全可靠 1. 分析下图架构存在的问题 当只有一个节点broker,当他宕机了其他consumer就发从.log磁盘文件中获取数据了甚至有可能数据还没存到文件中就丢失了。所以不行。引入横向扩展增加集群或者纵向扩展增加系统资源配置采用io效率更好的固态硬盘。这里纵向扩展是解决不了问题的采用横向扩展增加多个broker。这种可以在一定程度缓解io热点问题但不能解决如下图其实并没有解决因为从同一个topic中进行获取。 2. 所以引入对topic进行分区partition并用不同的标记进行区分。此时consumer就可以订阅到相关主题中的所有数据如图1.2 1.2 3. 但是观察1.2图相当于consumer发送了更多的请求那这个还是不行呀于是kafka 将多个消费者当作一个整体对主题进行消费 4. 当partition-1宕机可以发现即使数据保存在文件中也不是完全可靠安全的 所以进行交叉备份kafka称之为副本多个副本中只有一个可以进行读写其他都是用来备份 小结 1.多个节点broker形成集群 2.分区编号 3. 副本leader和follower 不能因为某个节点由于网络或者某些问题宕掉 而导致整个集群不可用所以一般在所有broker中会选择一个管理者 在Kafka中每个主题被分成一个或多个分区每个分区可以有多个副本leaderfollower。这些副本分布在不同的Kafka节点上确保了数据的冗余和容错性。当主题中的消息被发布到一个分区时这些消息会被复制到该分区的所有副本中。这意味着即使某个节点发生故障仍然可以从其他节点的副本中获取数据确保了系统的高可用性和持久性。 因此在Kafka中副本的概念实际上是一种备份机制它确保了数据的可靠性和可恢复性。每个副本都可以提供数据的读写操作这样就实现了数据的高可用性和负载均衡。 kafka中的broker节点相当于一台服务器用于存储和管理生产者发送的消息以及消费者获取的消息。每个Broker都有一个唯一的ID并且可以在集群中进行扩展和复制以提供高可用性和容错性。存储处理负载均衡 controller控制整个集群某个节点出现问题对集群影响不大但是如果controller出现问题就会影响很大所以1.管理者备份 2让节点都可能做管理者zookeeper选举 Zookeeper Znode 每个Kafka 的broker都会在Zookeeper中注册一个节点znode用于存储broker的元数据信息znode包含了broker的id信息主机号端口号znode还扮演着协调集群的各种操作如领导选举分区分配副本管理Kafka集群中的broker们通过与ZooKeeper交互可以实时感知集群的状态以及变化从而协同工作并保持整个集群的稳定性和可靠性。 集群协调 Zookeeper 管理 Kafka 集群中的 broker 节点并协调它们的工作。它负责选举 leader维护集群的元数据以及监控 broker 的健康状态。 Leader 选举 在 Kafka 中每个分区都有一个 leader broker 负责处理读写请求而其他副本replica只是用来备份数据。Zookeeper 负责协调 leader 的选举过程确保在 leader 失效时能够快速选举出新的 leader。 元数据管理 Kafka 集群的元数据包括 topic、partition、replica 等信息。Zookeeper 负责存储和维护这些元数据以及通知 broker 有关元数据变更的消息。 消费者组管理 Zookeeper 也负责管理 Kafka 消费者组的状态。它跟踪每个消费者的偏移量offset确保每个消费者从正确的位置开始消费消息。 心跳检测 Zookeeper 监控 Kafka 集群中各个节点的健康状态包括 broker 和消费者。它定期发送心跳消息以确保集群中的各个节点都处于正常运行状态。 kafka连接Zookeeper就会创建节点kafka就可以进行数据的存储和访问但是创建节点只能创建一次持久性节点kafka切断和zookepper之间的连接节点自动被删除就是临时黄色节点否则就是持久化节点。 znode节点有自动监听功能连接超时数据变化回调从而对集群管理 controller的选举 broker是kafka集群当中有很多broker,每个broker都有自己的id对于broker启动zookeeper的时候就会出现一个黄色字体的controller_broker id1临时节点关闭连接就会消失。多个集群节点的kafka会选择一个管理者管理者作为controller, 当1挂掉2,3都在对它建立连接请求 对于kafka实现节点管理还用到zookeeper这样的软件以后会根据kafka自身的算法实现集群管理从而提高性能降低耦合性。 controller和broker底层通信原理 在 Apache Kafka 中Controller 和 Broker 的通信是 Kafka 集群管理的核心部分。Kafka 集群由多个 brokers 组成其中一个 broker 会被选举为 Controller。Controller 负责管理集群的元数据和各种关键的管理任务如负载均衡、broker 故障处理、topic 分区的分配和复制等。 集群中有很多broker节点第一个被创建的节点会被选举成为controller, 监听controller和brokers/ids不同。后者是监听子节点的变化。 底层实现 一部分是broker和zookeeper之间的通信broker内部会有zookepper的客户端工具 controller与broker之间是进程之间的通信 BROKER内部组件 replication Manager 副本管理器 Kafkacontroller kafak接受数据的处理是由kafka的apis处理的 应用处理接口 所以我们来想一想broker到底有什么用吧 是kafka集群中的每个节点节点就是服务器可以用来处理生产者和消费者的请求 存储分区 副本每个 Broker 可以存储一个或多个分区的副本当生产者发送消息时消息会被写入对应分区的 Leader 副本然后通过副本同步机制复制到其他副本。生产者和消费者通过与 Broker 进行通信来发送和接收消息Broker 之间也会进行数据的同步和复制以保持数据的一致性和可用性。同步和复制就是副本同步机制防止单个节点故障提高整个机群的容错能力。 topic创建
默认情况下topic自动创建好修改参数auto.create.topics.enaable, NewTopic newTopic new NewTopic(my_topic, 1, (short) 1);主题名称:._字母英文构成 分区数量int类型 副本因子·replicationcountshort类型
