kafka基本原理介绍,以及重新选举,replica复制机制,isr等。

最近做的项目,通过数据库的log日志将数据库某些千万量级的表(这些表需要联表查询)数据同步到elasticsearch中,以减轻数据库的查询压力,其中以kafka作为消息中间件,以下是做该项目过程中对kafka的一些整理。

一、中间件

中间件,用于业务对于数据的时效性要求并不是特别高,有削峰填谷、解耦之功效。特别是中间件可以实现发送端和消费端的解耦,让消息的发送端异步发送消息,并迅速返回,可以极大提高系统整体的性能。中间件本质,就是发送、存储、消费,其实可以自己封装一个中间件,比如用并发包中的ArrayBlockingQueue,LinkedBlockingQueue,用put(T t)写入信息,用take(T t)拉取信息,这两个方法都有阻塞功能。FIFO队列,其中LinkedBlockingQueue效率更高。

选取中间件时,根据业务对于功能、性能、可靠性、可用性、生态性的需要,选用流行中间件,可以借助搜索引擎很快解决Bug,并且流行中间件的版本更迭及时,可以更快的获取更高的性能,和更多的功能。

二、kafka基本介绍

1、基本概念

需要了解producer,consumer,groupId,broker,topic,partition,segment的概念,如下图。

2、版本名

kafka_2.10-0.8.2.jar,2.10是指Scala版本,0.8.2是指kafka版本。

3、核心功能

  • Producer API允许程序发布数据流到一个到多个Kafka topic。
  • Consumer API允许程序订阅一个到多个topic,并且进行消费。
  • Streams API允许程序作为一个数据流处理,将一个或多个topic中输入的数据进行消费,并生产数据流到一个或多个topics中。
  • Connector API,可以通过Connector管理Kafka和另一个系统之间的数据复制,比如去捕获关系型数据库中的任意改变到一个表中。

4、topic介绍

topic(不同的业务数据,分流到不同的topic进行处理)

                                   \\

                                     \\

topic是基于zk建立的,实 \\ 际上同一topic下的partition是按如下分布在各个服务器上的(可以设置replicas的个数,此图partition黑色为leader,红色为 \\ 副本folower)。

                                         \    \\    /

                                              \||/

kafka对与zookeeper是强依赖的,是以zookeeper作为基础的,即使不做集群,也需要zk的支持。以下是kafka中必须要填写的配置文件,id为在zk中注册的brokerid,后者为要注册到的zookeeper的host和port。

broker.id=0
zookeeper.connect=localhost:2181

zk说白了,就是一个节点服务系统,至于用这个节点做什么,做单活、开关锁还是做检测服务器存活状态,都是业务代码根据这个节点做的一些逻辑处理。以下是kafka默认在zk中的节点层级结构:

5、partition介绍

partion可以看作一个有序的队列,里面的数据是储存在硬盘中的,追加式的。partition的作用就是提供分布式的扩展,一个topic可以有许多partions,多个partition可以并行处理数据,所以可以处理相当量的数据。只有partition的leader才会进行读写操作,folower仅进行复制,客户端是感知不到的。下图把kafka集群看成一个kakfa服务,仅显示leader。

1)offset概念

每一条数据都有一个offset,是每一条数据在该partition中的唯一标识。各个consumer控制和设置其在该partition下消费到offset位置,这样下次可以以该offset位置开始进行消费。

各个consumer的offset位置默认是在某一个broker当中的topic中保存的(为防止该broker宕掉无法获取offset信息,可以配置在每个broker中都进行保存,配置文件中配置)

offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=3

2)replicas的同步时机。

假如有N个replicas,其中一个replica为leader,其他都为follower,leader处理partition的所有读写请求,于此同时,follower会被动定期的去复制leader上的数据。

3)ISR介绍

leader会追踪和维护ISR中所有follower的滞后状态。如果滞后太多(数量滞后和时间滞后两个维度,replica.lag.time.max.ms和replica.lag.max.message可配置),leader会把该replica从ISR中移除。被移除ISR的replica一直在追赶leader。如下图,leader写入数据后并不会commit,只有ISR列表中的所有folower同步之后才会commit,把滞后的follower移除ISR主要是避免写消息延迟。设置ISR主要是为了broker宕掉之后,重新选举partition的leader从ISR列表中选择。

滞后情况:新增副本,GC挂起,follower失效,I/O瓶颈。

6、producer介绍

send(String topic, Integer partition, Long timestamp, K key, V data)
  • producer在发送消息的时候,必须指定topic和data,可以选择指定partion、key、timestamp,其中时间戳有两种方式,CreateTime和LogAppendTime,前者是客户端设置时间,后者是broker在消息写入log时设置的时间。如果为null,用的是System.currentTimeMillis()。如果同时不指定partition和key,那么就用round-bin决定发送到哪个partition。
  • 客户端会定时的取Broker的topic、partition、replicas等元数据信息,producer持有kafka节点的metadata信息,通过该信息创建ProducerPool,每次发送信息会根据要发送哪个Partition,来选择相应的Producer实例,Rpc连接。

7、consumer介绍

以下针对springBoot集成的kafka

@KafkaListener(topics = {"cache-music-user"},groupId="zwhUser",containerFactory = "batchAbleFactory")

public void consumeBatch(List<ConsumerRecord<String,String>> recordList, Acknowledgment acknowledgment) throws InterruptedException {

        ...

        方法体

        ...

}
  • consumer如何知道自己应该拉取哪一个partition。cordinator(某一个Kafka的broker)在分配consumer的时候,会选举consumer leader,后者分配每一个consumer要连接的broker,topic,partition,然后上报cordinator。然后consumer会根据自己被分配的partion去拉取数据。
  • 批量读取和单数据读取,ack机制。
  • 如果poll()时间超时,那么broker会认为consumer挂掉了,会踢掉该consumer。cordinator重新分配consumer。有时超时会抛异常,不过也会重新分配consumer。
  • consumer的groupId机制。对于一个groupId中的consumer来说,一个partition只能由一个consumer来消费。即不可能多个consumer消费1个partition。如下:

consumer可以在不同的机器中。

三、延伸

1、kafka重新选举

  • KafkaController的作用。Kafka集群中多个broker,有一个会被选举为controller leader,负责管理整个集群中分区和副本的状态,比如partition的leader 副本故障,由controller 负责为该partition重新选举新的leader 副本;当检测到ISR列表发生变化,有controller通知集群中所有broker更新其MetadataCache信息;或者增加某个topic分区的时候也会由controller管理分区的重新分配工作
  • KafkaController创建节点的方式去选举,作为leader,任何follower挂了,zk会感知到并通过Controller注册的Wather去通知Controller去重新选举。而leader挂了,zk会感知到,会通过Wather机制通知每一个broker去竞争Master。而ReplicaManager每个broker都有,是接受Contrloller的请求,对本服务上的partition进行管理的。

2、效率高的原因

因为kafka的数据都是存储在硬盘中,甚至有的公司将kafka其作为数据库使用,既然数据是基于硬盘的,那么为何kafka还是能够拥有如此高的吞吐量呢?

1)硬盘的索引功能。二分查找法。

分区:找到响应的分区

分段:根据文件segment的命名可以确认要查找的offset或timestamp在哪个文件中。

稀疏索引:快速确定要找的offset在哪个内存地址的附近。

2)I/O优化

普通程序I/O需要把Disk中的信息复制到系统环境内存(步骤1),再复制到kafka应用环境内存(步骤2),然后步骤3,步骤4到Socket通过网络发出,重复复制文本,I/O消耗大。

kafka则不一样:

3、kafka和rabbitMq的对比。

kafka是一种高吞吐量的分布式发布订阅消息系统。和rabbitMq各占半臂江山。以下是对比:

 

kafka

rabbitMq

书写语言

Java和Scala

Erlang

消息协议

自定义通信协议

AMQP/MQTT/STOMP等协议

消息过滤

topic和partition进行

交换机路由

消息堆积

磁盘式堆积

内存式堆积

消息传递模式

典型的Pub/Sub模式

典型的P2P模式

消费模式

典型的Pull

Push+Pull

消息回朔

通过offset和timestamp

消费即删除

流量控制

对producer和consumer进行主动设置

Credit—Based算法,作用producer

消息顺序

支持单分区级别的顺序性

单线程发送、消费

QPs

单机维持数十万,甚至达到百万

单机万级别

性能来说,kafka的吞吐量较大。kafka易于向外扩展,所有的producer、broker、consumer无需停机都可以即刻扩展机器。信息将全部的信息持久化到硬盘上,生产和消费互不影响,很灵活。功能来说,kafka适用于日志,事实上kafka本身就是LinkIn公司开发用于日志系统的,所以其文件叫做log。用户跟踪管道,对用户网页行为的记录跟踪,用于离线数据分析或者做报表。大数据分析。

发布了40 篇原创文章 · 获赞 75 · 访问量 7万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览