Kafka3.0之前依赖于zookeeper
Zookeeper开源,分布式的架构,提供协调服务(apache项目)
基于观察者模式设计的分布式服务管理架构
存储和管理数据,分布式节点上的服务接受观察者的注册,一旦分布式节点上的数据发生变化,由zookeeper开负责通知分布式节点上的服务
Zookeeper 分为领导者和追随者 leaderfoollower
只有一般以上的集群存活,zookeeper集群可以正常工作,适用于安装奇数台的服务集群
全局数据一致,每个zookeeper每个节点都保存相同的数据,维护监控服务的数据一致
数据更新的原子性,要么都成功,要么都失败。
Zookeeper的应用场景
- 统一命名服务,在分布式的环境下,对所有的应用和服务进行统一的命名
- 统一配置管理,配置文件同步,kafka的配置文件被修改,可以快速同步到其他节点
- 统一集群管理,实时掌握所有节点的状态
- 服务器动态上下线
- 负载均衡,把访问服务器的数据,发送到访问最少的服务器处理客户端的请求
领导者:zookeeper的选举机制
三台服务器 A B C
A先启动,发起第一次选举,投票给自己只有一票,不满半数,A的状态是looking
B启动,再次发起选举,A和B分别投自己一票,交换选票信息,myid,A发现B的myid比A大,A的这一票转而投给B
A0 B2 没有半数以上结果,A B会进入looking
C启动 MYID c的myid最大 A和B都会把票给C A0 B0 C3
C的状态变为leader,a和b变成follower
D myid4
只要leader确定,后续的服务器都是追随者
只有两种情况会开启选举机制
- 初始化的情况会产生选举
- 服务器之间的leader丢失了连接状态
Leader已经存在,建立连接即可
Leader不存,leader不存在
- 服务器ID大的胜出
- EPOCH大,直接胜出
- EPOCH相同,事务ID大的胜出
- EPOCH每个leader任期的代号,没有leader,大家的逻辑地址相同,每次投完一次之后,数据都是递增,事务id,表示服务器的每一次变更,每变更一次事务id变化一次
服务器ID,zookeeper集群当中都有一个id,每台机器不重复,和myid保持一致。
消息队列:kafka
为什么要引入消息队列这个机制(MQ),首先它是一个中间件,他负责发消息,客户到中间到服务端,服务端到中间件再到客户端,在高并发环境下,同步请求来不及处理,来不及处理的请求会形成阻塞,比方说数据库就会形成行锁或者表锁,请求线程满了,超标了,too manyconnection,出现就会引发系统雪崩 |
消息队列的作用
异步处理请求,流量削峰,应用解耦 | |
耦合 | 在软件系统当中,修改一个组件,需要修改所有其他组件,高度耦合 |
低度耦合 | 修改其中一个组件,对其他组件影响不大,无需修改所有 |
解耦 | 只要通信保证,其他的修改不影响整个集群,每个组件可以独立的跨站,修改,降低组件之间的依赖性 |
已来电就是接口约束,通过不同的端口,保证集群通信
可恢复性:系统当中的有一部分组件小时,不影响整个系统,也就是说在消息队列当中,即使有一个处理消息的进程失败,一旦恢复还可以重新加入到队列当中,继续处理消息
缓冲:可以控制和优化数据经过系统的时间和速度,解决生产消息和消费消息处理速度不一致问题
峰值的处理能力:消息队列在峰值情况之下,能够顶住突发的访问压力,避免了专门为了突发情况而对系统进行修改。
异步通信:允许用户把一个消息放入队列,但是不立即处理,等用户想处理的时候在再处理。
消息队列的模式
点对点 一对一 | 消息的生产者发送消息到队列中,消费者从队列中提取消息,消费者提取完之后,队列将不再存储被提取的消息,队列中被提取的消息会被移除,后续消费者不能在消费队列当中的消息,消息队列可以有多个消费者,但是一个消息只能有一个消费者 |
发布/订阅模式 | 1对多,又叫观察者模式,消费者提取数据之后,队列当中的消息不会被清除 |
生产者发布一个消息到主题,所有消费者都是通过主题获取消息
主题:topic topic类似一个数据流的管道,生产者把消息发布到主题,消费者从主题当中订阅数据,主题可以分区,每个分区都有自己的偏移量
分区:partion 每个主题可以分成多个分区,每个分区都是数据的有序子集,分区可以允许kafka进行水平拓展,,以处理大量数据消息在分钟按照偏移量存储,消费者可以独立读取每个分区的数据
偏移量: 是每个消息在分区中唯一的标识,消费者可以通过偏移量来跟踪获取已读或者未读消息的位置,也可以提交偏移量来记录已处理的信息
生产者:producer生产者把数据发送kafka的主题当中,负责写入消息
消费者:从主题当中读取数据,消费者可以是一个也可以十多个,每个消费者有一个唯一的消费者组ID,kafka通过消费者实现负载均衡和容错性
经纪人: broker,每个kafka节点都有一个borker,每个负责一个kafka服务器,id唯一,存储主题分区当中的数据,处理生产和消费者的请求,以及维护元数据(zookeeper),3.0之后不依赖zookeeper的核心,元数据由kafka节点自己管理
Zookeeper:zookeeper负责保存元数据,元数据就是topic的相关信息(发布在哪台主机,制定了多少分区,以及副本数,偏移量)
Zookeeper自建一个主题:_consumer_offsets
- zookeeper:主要是分布式,观察者模式,统一各个服务器节点的数据,在kafka当中,收集保存kafka的元数据
- Kafka消息队列订阅发布模式
RABBIT MQ(实现rabbit MQ消息队列)
Kafka的工作流程