实习修炼第十四天

最新推荐文章于 2024-09-06 15:28:15 发布

ITSOK_U

最新推荐文章于 2024-09-06 15:28:15 发布

阅读量126

点赞数

本文链接：https://blog.csdn.net/ITSOK_123/article/details/95495903

版权

学习进程专栏收录该内容

26 篇文章 0 订阅

订阅专栏

整体内容

消息队列的使用 Zookeeper的Leader选举
原理在前面的文章中有介绍

消息队列

kafka架构中有下列角色参与：

broker: kafka 集群中的服务器实例就被称为broker，它是消息处理的中间节点
producer: 就是向broker发送消息的客户端
consumer:向从发送消息的客户端也就是borker中读取消息的客户端
zookeeper: 存储集群状态的注册中心，不处理具体消息。

逻辑模型:

message: 是kafka通信的基本单元
topic: topic 在逻辑结构上类似于队列, 每条消息都属于一个 topic，可以认为是一个消息集合
consumer group: 每个group中可以包含若干 consumer 实例，每个topic可以被多个consumer group订阅。消费者组拥有唯一的 GroupID 进行标识，每个 consumer 实例有且只有一个 GroupID。
partition:是topic物理上的分组， topic 被分为若干个 partition 进行存储，每条消息都属于一个 partition。同一 topic 下的不同分区包含的消息是不同的。每个partition物理上对应一个文件夹，该文件夹下存储这个partition的所有消息和索引文件。
offset: 每条消息在 partition 中使用 offset (偏移量)作为唯一标识

kafka的message是以topic为基本单位，不同topic之间是相互独立的。每个topic又可分为几个不同的partition，每个partition存储一部的分message。物理上来说，不同的 topic 的消息是分开存储的，每个 topic 可以有多个生产者向它发送消息，也可以有多个消费者去消费其中的消息。

参考 https://blog.csdn.net/qq_35571554/article/details/82593159
消息传递流程

1 Producer根据指定的partition方法（round-robin、hash等），将消息发布到指定topic的partition里面
2 kafka集群接收到Producer发过来的消息后，将其持久化到硬盘，并保留消息指定时长（可配置），而不关注消息是否被消费。
3 消费者通过 offset 标记自己读取的位置，主动读取 parttion 中的数据

• Consumer发送FetchRequest到Leader Partition所在的Broker
• Broker获取消息的 start offset和size (获取消息的size大小)，根据 .index 数据查找 offset 相关的 position 数据，由于 .index 并不存储所有的 offset，所以会首先查找到小于等于 start_offset 的数据，然后定位到相应的 .log 文件，开始顺序读取到 start_offset 确定 position。
• 根据 position 和 size 便可确认需要读取的消息范围，根据确定的消息文件范围，直接通过 sendfile 的方式将内容发送给消费者。

消费流程
消息由生产者发布到Kafka集群后，会被消费者消费。消息的消费模型有两种：推送模型（push）和拉取模型（pull）。

基于推送模型（push）的消息系统，由消息代理记录消费者的消费状态。消息代理在将消息推送到消费者后，标记这条消息为已消费，但这种方式无法很好地保证消息被处理。
如果采用拉取模型，则由消费者自己记录消费状态，每个消费者互相独立地顺序读取每个分区的消息。

参考链接 http://matt33.com/2016/03/09/kafka-transmit/

Zookeeper的Leader选举

前面文章又简单介绍过Zookeeper 传送门
对于Zookeeper来说，它的节点有下面四种类型：

LOOKING：寻找Leader状态，处于该状态需要进入选举流程
LEADING：领导者状态，处于该状态的节点说明是角色已经是Leader
FOLLOWING：跟随者状态，表示Leader已经选举出来，当前节点角色是follower
OBSERVER：观察者状态，表明当前节点角色是observer，不参与任何形式的投票

最初的时候，Zookeeper集群中每个server的最初状态都是LOOKING，当leader服务器选举出来后，leader服务器状态变为LEADING，不是observe服务器的server的状态自动变为FOLLOWERING，当leader服务器挂掉之后，所有非observe的server将状态都改为LOOKING，进行新的选举，选举出新的leader服务器，然后leader服务器状态变为LEADING，不是observe的server的状态自动变为FOLLOWERING。

Zookeeper中leader的作用：
一个zookeeper 集群只有一个leader：类似master/slave模式；客户端提交请求之后,先发送到leader,leader作为接收者,广播到每个server。选举的过程其实就是简单的争抢在Zookeeper注册临时节点的操作，谁注册了约定的临时节点，谁就是master。所有服务器同时会在servers节点下注册一个临时节点（保存自己的基本信息），以便于应用程序读取当前可用的服务器列表。