zookeeper集群

2023-12-13 11:18:00

zookeeper集群+Kafka集群:

kafka3.0之前依赖于zookeeper

zookeeper开源,分布式架构,提供协调服务(Apache项目)

基于观察者模式涉及的分布式服务管理架构。

主要功能就是存储和管理数据。分布式节点上的服务接受观察者的注册。一旦分布式节点上的数据发生变化,由zookeeper来负责通知分布式节点上的服务。

zookeeper:分为领导者 追随者 leader follower组成的集群

特点

只要有一半以上的集群存活,zookeeper集群就可以正常工作,适用于安装奇数台的服务集群

全局数据一致,每个zookeeper每个节点都保存相同的数据。维护监控服务的数据一致

数据更新与数据库一样 原子性 要么都成功要么都失败

实时性,只要有变化立刻同步

应用场景

1、统一命名服务 (在分布式环境下,对所有的应用和服务进行统一命名)

2、统一配置管理 (配置文件要求同步,比如kafaka的配置文件被修改,可以快速被同步到其他节点)

3、统一集群管理 (可以实时掌握所有节点的状态)

4、服务器动态上下线

5、可以实现负载均衡 (把访问服务器的数据发送到访问最少的服务器处理客户端的请求)

领导者和追随者: zookeeper的选举机制

比如有三台服务器 A B C

  • A先启动 发起第一次选举,投票投给自己 明明是三台,但是只有一票不满足半数 这时A的状态是looking
  • B 启动 再发起一次选举,A和B分别投自己一票,交换选票信息,myid A发现B的myid比A的大 那么A的这一票会转而投给B
  • 这时候A 0票 B 2票 没有半数以上的结果 这是A和B进入looking状态
  • C启动 比myid 如果C的myid最大 那么服务器A B 都会把票投给C 再加上C自己的一票 在这里B是有可能会成为leader的,而这个时候C会直接成为follower
  • C-3 A-0 B-0
  • 这个时候C的状态变为leader, A与B 变为follower

只要leader确定,后续的服务器都是追随者

只有两种情况会开启选举机制

1、初始化的情况下会产生选举投票

2、服务器之间和leader丢失了连接状态

如果leader已经存在,建立连接即可

leader不存在

1、服务器ID大的会胜出

2、EPOCH大,直接胜出

3、EPOCH相同,事务ID大的胜出

EPOCH每个leader任期的代号,没有leader,大家的逻辑地位是相同的,每投完一次之后,数据是递增的。

事务id,表示服务器的每一次变更,每变更一次事务ID变化一次

服务器ID,zookeeper集群当中都有一个ID,每台机器不重复,和myid保持一致。

zookeeper+kafuka(2.7.0)

kafuka (3.4.1)

zookeeper+kafuka实现过程:

1、zookeeper集群

192.168.211.51 zookeeper+kafuka

192.168.211.52 zookeeper+kafuka

192.168.211.53 zookeeper+kafuka

机器配置2核4G

server.1=192.168.211.51:3188:3288

每个zookeeper集群的初始myid

192.168.211.51:服务器IP的地址

3188:领导者和追随者之间交换信息的端口(内部通信的端口)

3288:一旦leader丢失响应,开启选举,3288就是用来执行选举时的服务器之间通信端口

消息队列:kafka

为什么要引入消息队列(MQ)他也是一个中间件。在高并发环境下,同步请求来不及处理。来不及处理的请求会形成阻塞。

比方说数据库就会形成行锁或者表锁。请求线程满了,超标了,too many connection 整个系统血崩

消息队列的作用:异步处理请求。流量削峰

解藕:

藕和:在软件系统当中,修改一个组件需要修改所有其他组件,高度耦合

低度耦合:修改其中一个组件,对其他组件影响不大,无需修改所有

A B C

只要通信保证,其他的修改不影响整个集群,每个组件可以独立的扩展,修改,降低组件之间的依赖性

依赖点就是接口约束,通过不同的端口,保证集群通信

可恢复性:系统当中的有一部分组件消失,不影响整个系统。也就是说在消息队列当中。即使有一个处理消息的进程失败,一旦恢复还可以重写加入到队列当中,继续处理消息

缓冲:可以控制和优化数据经过系统的时间和速度。解决生产消息和消费消息处理速度不一致的问题

峰值的处理能力:消息队列在峰值的情况之下,能够顶住突发的访问压力,避免专门为了突发情况而对系统进行修改

异步通信:允许用户把一个消息放入队列,但是不是立即处理,等用户想处理的时候在处理

消息队列的模式:

点对点一对一:消息的生产者发送消息到队列中,消费者从队列中提取消息,队列中被提取的消息将会被移除,后续消费者不能再消费队列当中的消息 。消息队列可以有多个消费者但是一个消息,只能由一个消费者提取

RABBITMQ

发布/订阅模式:一对多,观察者模式,消费者提取数据之后,队列当中的消息不会被清除

生产者发布一个消息到主题,所有消费者都是通过主题获得消息。

主题:topic topic类似一个数据流的管道,生产者把消息发布到主题,消费者从主题当中订阅数据,主题可以分区,每个分区都有自己的偏移量

分区:partition 每个主题都可以分成多个分区。每个分区是数据的有序子集,分区可以允许kafka进行水平扩展,以处理大量数据

消息在分区中按照偏移量存储,消费者可以独立读取每个分区的数据

偏移量:是每个消息在分区当中的唯一的标识。消费者可以通过偏移量来跟踪获取已读或者未读消息的位置。也可以提交偏移量来记录已处理的信息

生产者:producer 生产者把数据发送kafka的主题当中,负责写入消息

消费者:从主题当中读取数据,消费者可以是一个也可以是多个。每个消费者都有一个唯一的消费者组ID,kafka通过消费者实现负载均衡和容错性

经纪人:Broker 每个kafka节点都有一个Broker,每个Broker负责一台kafka服务器,ID唯一 ,存储主题分区当中的数据,处理生产和消费者的请求

维护元数据(zookeeper)

zookeeper:zookeeper负责保存元数据。元数据就是topic的相关信息(发布在哪台主机上,指定了多少分区,以及副本数,偏移量)

zookeeper自建一个主题:__consumer_offsets

3.0之后不依赖zookeeper的核心就是因为元数据由kafka自己管理。

kafka的工作流程:

kafka-topics.sh --create --zookeeper 192.168.211.51:2181,192.168.211.52:2181 --replication-factor 2 --partitions 3 --topic test1

创建主题:

1、在kafka的bin目录下,是所有的kafka可执行命令文件

2、--zookeeper 指定的是zookeeper的地址和端口,保存kafa的元数据

3、--replication-factor 2 定义每个分区的副本数

4、partitions 3 指定主题的分区数

5、--topic test1 指定主题的名称

Partition:分区编号

Leader:每个分区都有一个领导者(Leader),领导者负责处理分区的读写操作。

在上述输出中,领导者的编号分别为 3、1、3。

Replicas:每个分区可以有多个副本(Replicas),用于提供冗余和容错性。

在上述输出中,Replica 3、1、2 分别对应不同的 Kafka broker。

Isr:ISR(In-Sync Replicas)表示当前与领导者保持同步的副本。

ISR 3、1分别表示与领导者同步的副本。

1、zookeeper:主要是分布式,观察者模式,统一各个服务器节点的数据

在kafka当中,收集保存kafka大的元数据

2、kafka消息队列 订阅发布模式

RABBIT MQ(实现rabbit mq 消息队列)

文章来源:https://blog.csdn.net/2301_78496557/article/details/134943424
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。