zoukankan      html  css  js  c++  java
  • 《Kafka技术内幕》学习笔记

    第一章 Kafka入门

    1.1 Kafka流式数据平台

    Kafka作为流式数据平台的特点:

      消息系统:两种消息模型:队列和发布订阅。

        队列模型:将处理工作平均分给消费组中的消费者成员。

        发布订阅模型:将消息广播给多个消费组(consumer group)

      队列模式(点对点模式):多个消费者读取消息队列,每条消息只发给一个消费者。

      发布订阅模式:多个消费者订阅主题,主题的每条记录会发布给所有消费者。

      存储系统:数据写入Kafka集群的服务器节点时,会复制多份来保证出现故障时仍然可用。

    为了保证消息的可靠性,允许生产者的生产请求在收到应答结果之前,阻塞地等待一条消息,直到它完全复制到多个节点,才认为这条消息写入成功。

      流处理系统:提供了流处理API,比如流的聚合、连接、各种转换。

      将消息系统、存储系统、流处理系统组合在一起。

    1.2 Kafka的基本概念

    分区模型:

      Kafka集群由多个消息代理服务器(broker server)组成。

      每条消息都有一个topic,一个topic一般会有多个消息的订阅者。

      每个topic都有1到N个分区。

      分区中每条消息都会按照顺序分配到一个编号,叫做偏移量(offset)。

      每条消息包含键值和时间戳。

      Kafka以分区为最小的粒度,确保一个分区只属于一个消费者。

      每个topic有多个分区,不同消费者处理不同分区,保证了消息的有序性,也做到了消费者的负载均衡。

    消费模型

      消息的消费模型有两种:推送模型和拉取模型。

      推送模型:由消息代理记录消费者的状态。发送完消息后,状态为已发送,消费者确认收到后状态为已消费。

    这种做法是不可取的,因为消息代理要记录所有消息的状态。

      拉取模型:Kafka采用拉取模型,由消费者自己记录消费状态。

    消费者控制偏移量:可以按任意顺序消费消息,可以重置到旧的偏移量。

    生产者发布的消息会一直存在集群中,不管有没有被消费,用户可以设置保留时间来清理过期数据。

    分布式模型:

      每个分区会以副本的方式复制到多个消息代理节点上。

      其中一个节点为主副本(leader),其他节点作为从副本(follower)。

      主副本负责所有的读写,从副本仅从主副本同步数据。

      当一个主副本出现故障时,其中一个从副本会成为新的主副本。

      分区的主副本是均衡分布在各个节点上的。

      分区是消费者线程模型的最小并行单位。

      消息没有键时,通过轮询方式发布到不同分区,如果有键,相同键的消息总是发布到同一个分区。

      当一个新消费者加入消费组时,或者消费者离开消费组,都会触发再平衡。

      Kafka消费消息时,只保证分区内消息的有序性,并不保证主题中多个分区的消息顺序。

    1.3 Kafka的设计与实现

      生产者使用批量发送消息集的方式解决了网络请求过多的问题。生产者会一次发送一批数据。

      消费者拉取消息也可以一次拉一批。

      允许消费者的拉取请求以阻塞式,长轮询的方式等待,直到有新的数据到来。

      一个消息只有被完全复制到所有副本,才会认为消息被成功提交。成功提交的消息才对消费者可见。

    Kafka对节点存活的定义:

      节点必须和ZK保持会话。

      如果节点是某个分区的从副本,那么它必须对主副本的写操作进行复制,并且不能落后太多。

    第二章 生产者

    2.1 新生产者客户端

      生产者要发送消息,并不是直接发送给服务端,而是先在客户端把消息放入队列中。然后由一个消息发送线程从队列中拉取消息,以批量的方式发送消息给服务端。

      生产者发消息给Kafka集群,可以同时往多个服务端节点写数据。

      如果指定了消息的键,对键进行散列之后,再与分区的数量取模得到分区编号。

    为消息选择分区:

      生产者可以将一批消息分成多个分区,每个分区写入不同的服务端节点。

      在客户端就为消息选择分区:因为这样才知道应该发送到哪个节点。

    客户端记录收集器:

      生产者发送的消息先缓存到记录收集器(RecordAccumulator),再由发送线程Sender批量写入Kafka集群。 

      消息发送线程按照分区的目标节点发送。

      在发送线程需要数据时,记录收集器能够按照节点将消息重新分组再交给发送线程。

      发送线程并不负责发送客户端请求,它拿到消息后,会创建好客户端请求,然后把请求交给客户端网络对象去发送。

    客户端网络连接对象(NetworkClient):

      发送线程的run()会调用3个方法:

      ready():从记录收集器获取准备完毕的节点,并连接所有准备好的节点。

      send():为每个节点创建一个客户端请求。

      poll():轮询动作会真正执行网络请求。

    选择器处理网络请求:

      选择器使用javaNIO异步非阻塞方式管理连接和读写请求,它用单线程就可以管理多个网络连接通道。

      生产者客户端只用使用一个选择器,就可以和集群的多个服务端进行网络通信。

      SocketChanmel(客户端网络连接通道):底层的字节数据读写都发生在通道上。

      Selector(选择器):选择器通过选择键的方式监听读写事件的发生。

      SelectionKey(选择键):将通道注册到选择器上。

    第三章 消费者

    使用消费组实现消息队列的两种模式:

      同一个分区只可被一个消费者处理,这样可以不加锁,提升消费者处理能力。

      每个消费者都可以配置一个所属的消费组,并且订阅多个主题。

      同一条消息会广播给多个消费,单播给同一组中的消费者。

    消费组再平衡实现故障容错:

      如果一个消费者宕机了,分配给这个消费者的分区要重新分给组内的其他消费者。

      如果新加入了消费者,分区也得重新分配。

      如果订阅主题的分区发生了变化,所有消费者也要再平衡。

      再平衡是消费组中的所有消费者都要执行重新分配分区的动作。

      如果再平衡前,消费者C1保存了分区P1的消费进度,再平衡后C2可以从保存的进度继续读取P1。

    消费者保存消费进度

      消费者客户端要保存消费消息的偏移量,即消费进度。

      消费进度应该面向消费组级别,保证再平衡后,别的消费者也能拿到这个分区的消费进度。

      消费进度保存在ZK中。

    消费者与ZK的关系:

      ZK不仅保存了Kafka的内部元数据,而且记录了消费组的成员列表,分区的消费进度,分区的所有者。

      高级API:消费者代码不需要管理偏移量的提交。并且采用了消费组的自动负载均衡,确保消费者的增减不会影响到消息的消费。

      低级API:通常针对特殊逻辑,比如消费者只想消费特定分区。代码要实现选择分区的主副本等这些。

    3.1 消费者启动和初始化

      消费者的配置信息要指定连接的ZK集群以及消费组编号。

  • 相关阅读:
    eclipse如何设置高亮代码的背景色,比如选中某个单词,高亮所有的
    javascript弹层
    click只能点击一次
    eclipse创建文件夹河包
    maven工程如何引用css和js文件
    maven-parent的pom.xml配置
    pom.xml设置maven的编码方式
    springmvc搭建环境时报No mapping found for HTTP request with URI [/exam3/welcome] in DispatcherServlet with name 'spring2'
    sso的实现
    C#中,重新排列panel中的按钮
  • 原文地址:https://www.cnblogs.com/mengchunchen/p/9525305.html
Copyright © 2011-2022 走看看