Zookeeper

目录

Zookeeper

Zookeeper选举机制(基于paxos算法实现的)

Kafka架构组件

kafka管理操作

[kafka通过 ack 应答机制来保证数据的可靠性](#kafka通过 ack 应答机制来保证数据的可靠性)


Zookeeper

分布式系统管理框架,主要用来解决分布式应用集群中应用系统的数据一致性问题 相当于各种分布式应用的 注册中心+文件系统+通知机制

本质:用于注册各种分布式应用,存储和管理这些分布式应用的元数据,如果应用或服务本身状态发送变化就会通知客户端

Zookeeper选举机制(基于paxos算法实现的)

第一次leader选举:比较服务器节点的myid,谁的myid最大就获取其它节点的选票,当选票超过服务器节点数量的半数则当选leader,其它节点为follower,即使以后再有其它myid更大的节点加入集群也不会影响之前的选举结果。

非第一次选举:如果是非leader节点故障,替换新的节点继续作follower,与现存的leader节点建立连接并同步数据

如果是leader节点故障,则需要重新选举新的leader,先比较每个存活节点的epoch(参与选举的次数),如由epoch最大的节点则直接当选leader

若epoch有相同的节点,再比较zxid(写操作的事务id),如由zxid最大的节点则直接当选leader

若zxid也有相同的节点,继续比较sid(等同于myid),由sid最大的节点当选leader

中间件 实现应用解耦、异步处理

Web应用型(代理服务器):Nginx Haproxy Tomcat PHP

消息队列型(MQ):Redis Kafka RabbitMQ RocketMQ ActiveMQ

消息队列的好处:应用解耦、异步处理、数据缓冲、流量削峰、可恢复 等

消息队列的模式:

点对点模式:一对一,一个消息只能有一个消费者能够消费,消息者消费完消息后会清除消息

发布/订阅模式(观察者模式):一对多,数据生产后会推送给所有消费者,消费者消费完消息后不会清除消息

Kafka 是一个分布式的基于发布/订阅模式的消息队列。主要应用于大数据实时处理领域和日志收集。

Kafka架构组件

Broker kafka服务器节点

Producer 生产者,发布消息到topic

Consumer 消费者

Consumer Group 消息者组,是消息的实际订阅者,一个消费者组包含一个或多个消费者,且组内成员不能重复消费同一个Partition数据

Producer -> Topic消息队列 -> 一个或多个partition分区 -> 一个或多个replica副本(leader负责数据读写,follower只负责同步复制leader的数据)

Consumer -> offset偏移量(用来记录消费者上一次消费到的位置)

Zookeeper 存储和管理kafka集群的元数据,生产者和消费者的动作都需要zk的管理和支持。

比如生产者推送数据到kafka需要先通过zk寻找到kafka集群节点的位置,消费者可以从zk获取offset记录的上一次消费的位置再继续往后消费。

kafka管理操作

kafka-topics.sh --zookeeper IP1:2181,IP2:2181,IP3:2181 --create --topic 队列名 --partitions 分区数 --replication-factor 副本数 #创建topic

kafka-topics.sh --zookeeper IP1:2181,IP2:2181,IP3:2181 --list #查看topic列表

kafka-topics.sh --zookeeper IP1:2181,IP2:2181,IP3:2181 --discribe --topic 队列名 #查看topic详细信息

kafka-topics.sh --zookeeper IP1:2181,IP2:2181,IP3:2181 --alter --topic 队列名 --partitions 分区数(只能增不能减) #修改topic分区配置

kafka-topics.sh --zookeeper IP1:2181,IP2:2181,IP3:2181 --delete --topic 队列名 #删除topic

kafka-console-producer.sh --broker-list IP1:9092,IP2:9092,IP3:9092 --topic 队列名 #向topic推送消息

kafka-console-consumer.sh --bootstrap-server IP1:9092,IP2:9092,IP3:9092 --topic 队列名 [--from-beginning] #从topic拉取消息

kafka通过 ack 应答机制来保证数据的可靠性

在 producer.properties 配置文件中设置 request.required.ack 参数

acks 参数设置 0,代表生产者不等kafka确认就会发送下一条消息。此机制性能最高,可靠性最低,当leader的broker故障可能会丢失数据

1,代表生产者会等leader接收到数据并确认后才会发送下一条数据、此机制性能其次,可靠性一般,当follower同步完成前leader故障可能会导致数据丢失

-1|all,代表生产者需要等所有的follower都同步完成并确认后才会发送下一条数据。此机制性能最低,可靠性最高

相关推荐
柒.梧.37 分钟前
MyBatis一对一关联查询深度解析:大实体类、SQL99联表、分布式查询实践
分布式·mybatis
野猪佩挤38 分钟前
k8s部署loki(distributed模式)
云原生·容器·kubernetes
跟着珅聪学java42 分钟前
ZooKeeper底层原理
zookeeper
Henry Zhu1231 小时前
VPP中DHCP插件源码深度解析第二篇:DHCPv4客户端实现详解(下)
服务器·c语言·网络·计算机网络·云原生
Code知行合壹2 小时前
Kubernetes实战进阶
云原生·容器·kubernetes
Wang's Blog2 小时前
Kafka: Admin 客户端操作指南之主题管理与集群监控
分布式·kafka
源代码•宸2 小时前
goframe框架签到系统项目开发(用户认证、基于 JWT 实现认证、携带access token获取用户信息)
服务器·开发语言·网络·分布式·后端·golang·jwt
伊克罗德信息科技2 小时前
【客户案例】KiwiCloud 携手伊克罗德信息,打造云原生 UEM 平台,实现统一终端管理的多区域高效部署
云原生
AR_xsy2 小时前
云原生数据备份还原利器---【velero】
云原生
前端世界2 小时前
别只测功能:一套可落地的鸿蒙分布式压力测试方案
分布式·压力测试·harmonyos