消息中间件之Kafka(一)

1.简介

  • 高性能的消息中间件,在大数据的业务场景下性能比较好,kafka本身不维护消息位点,而是交由Consumer来维护,消息可以重复消费,并且内部使用了零拷贝技术,性能比较好
    Broker持久化消息时采用了MMAP的技术,Consumer拉取消息时使用的sendfile技术
  • Kafka是最初由Linkedin公司开发,是一个分布式、支持分区(parition)、多副本的(replica),
    基于Zookeeper协调的分布式消息系统,它最大的特性就是可以实时地处理大量数据以满足各种需求场景
    比如:基于Hadoop的批处理系统、低延迟的实时系统、Storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写
  • 吞吐量在10w~100w

2.模型设计图

消息中间件之Kafka(一)_第1张图片

3.特点

  • 一个parition只能交给一个consumer消费,因为交给多个consumer让其进行poll拉取消息进行消费,会引起重复消费的问题
  • 服务端(broker)和客户端(producer、consumer)之间通信通过TCP协议来完成
  • Topic、Partition和Broker之间的关系.
    一个topic,代表逻辑上的一个业务数据集,比如按数据库里不同表的数据操作消息区分放入不同topic,订单相关操作消息放入订单topic,用户相关操作消息放入用户topic,对于大型网站来说,后端数据都是海量的.订单消息很可能时非常巨量的,比如有几百个G甚至达到TB级别,如果把这么多数据都放在一台机器上可能会有容量限制问题,那么就可以在topic内部划分多个partition来分片存储数据,不同的parition可以位于不同的机器上,每台机器上都运行一个Kafka的进程Broker
  • 同时未发布和订阅提供高吞吐量,Kafka的设计目标是以时间复杂度O(1)的方式提供消息持久化能力的,即使对TB级别以上数据也能保证常数时间的访问性能,即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输
  • 消费消息采用Pull模式,消息被处理的状态是在Consumer端维护的,而不是由服务端维护,Broker无状态,Consumer自己保存offset

4.核心组件

  • Topic:Kafka根据topic对消息进行归类,发布到Kafka集群的每条消息都需要指定一个topic
  • Parition:物理上的概念,一个topic可以分为多个partition,每个partition的内部时有序的
  • Broker: 消息中间件处理节点,一个Kafka节点就是一个broker,一个或者多个Broker可以组成一个Kafka集群
  • ConsumerGroup: 每个Consumer属于一个特定的ConsumerGroup,一条消息可以被多个不同的ConsumerGroup消费,到那时一个ConsumerGroup中只能有一个Consumer能够消费该消息
  • Consumer:消息消费者,从Broker读取消息的客户端
  • Producer: 消息生产者,向Broker发送消息的客户端

5.设计机制

5.1 Kafka核心总控制器Controller

在Kafka集群中会有一个或者多个broker,其中有一个broker会被选举为控制器(Kafka Controller),
它负责管理整个集群中所有分区和副本的状态
1.当某个分区的leader副本出现故障时,由控制器负责为该分区选举出新的leader副本
2.当检测到某个分区的ISR(In-Sync-Replica)集合发生变化时,由控制器负责通知所有的broker更新元数据信息
3.当使用kafka-topics.sh脚本为某个topic增加分区数量时,同样还是由控制器负责让新分区被其他节点感知到

5.1.1 Controller选举机制

在Kafka集群启动的时候,会自动选举以太broker作为controller来管理整个集群,
选举的过程时集群中每个broker都会尝试在zookeeper上创建一个/controller的临时节点,
zookeeper会保证有且仅有一个broker能创建成功,这个broker就会成为集群的总控制器controller
当这个controller角色的broker宕机了,此时zookeeper临时节点就会消失,集群里其他broker
会一直监听这个临时节点,发现临时节点消失了,就竞争再次创建临时节点,这就是我们说的选举机制,zookeeper又会保证有一个broker成为新的controller

5.2 Partition副本选举Leader机制

controller感知到分区Leader所在的broker挂了(controller监听了很多zk节点可以感知到broker存活)
controller会从ISR(In-sync replica)列表(参数unclean.leader.election.enable=false)里挑第一个broker作为leader(第一个broker最先放进ISR列表,
可能时同步数据最多的副本)
如果参数unclean.leader.election.enable为true,代表ISR列表里所有副本都挂了的时候可以在ISR列表以外的副本中选leader
这种设置,可以提高可用性,但是选出的新leader有肯恩那个数据少很多,
副本进入ISR列表有两个条件:
1.副本节点不能那个产生分区,必须能与zk保持会话以及跟leader副本网络连通
2.副本能复制leader上的所有写操作,并且不能落后太多。(与leader副本同步之后的副本,是由replica.lag.time.max.ms配置决定的,超过
这个时间都没有跟leader同步过的一次的副本会被移出ISR列表)

5.3 消费者消费消息的offset记录机制

每个consumer会定期将自己消费分区的offset提交给kafka内部topic:_consumer_offsets,
提交过去的时候,key时consumerGroupId+topic+分区号,value就是当前offset的值,
kafka会定期清理topic里的消息,最后就保留最新的那条数据,因为_consumer_offset可能会接收高并发的请求,
kafka默认给其分配50个分区(可以通过offsets.topic.num.paritions设置),这样可以通过加机器的方式抗大并发

5.4 消费者的rebalance机制

rebalance就是说如果消费组里的消费者数量有变化或者消费的分区数有变化,fafka会重新分配消费者消费分区的关系,比如consumer group中某个消费者挂了,此时会自动把分配给它的分区交给其他的消费者,如果它又重启了,那么,又会把一些分区重新交还给他
注意:relablance只针对subscribe这种不指定分区消费的情况,如果通过assign这种消费方式指定了分区,kafka不会进行rebalance,如下情况可能会触发消费者realance:
1.消费组里的consumer增加或减少了
2.动态给topic增加了分区
3.消费者组订阅了更多的topic,rebalance过程中,消费者无法从kafka消费消息,这对kafka的TPS会有影响,如果kafka集群内节点较多,比如数百个,那rebalance可能会耗时极多,所以尽量避免在系统高峰期的rebalance发生

5.5 producer发布消息机制

1.写入方式
producer采用push模式将消息发布到broker,每条消息都被append到partition中,属于顺序写磁盘(顺序写磁盘效率比随机写内存要高,保障kafka吞吐率)
2.消息路由
producer发送消息到broker时,会根据分区算法选择将其存储到哪一个partition,路由机制为:
2.1 指定了partition,则直接使用
2.2 未指定partition但指定key,通过对key的value进行hash选出一个partition
2.3 partition和key都未指定,使用轮询选出一个partition
3.写入流程
3.1 producer先从zookeeper的/brokers/…/state/节点找到该partition的leader
3.2 producer消息发送给该leader
3.3 leader将消息写入本地log
3.4 followers从leader pull消息,写入本地log后向leader发送ACK
3.5 leader收到所有的ISR中的replica的ACK后,增加HW(high watermark,最后commit的offset)并向producer发送ACK

5.6 HW与LEO机制

5.6.1

HW俗称高水位,HighWatermark的缩写,取一个partition对应的ISR中最小的LEO(log-end-offse)作为HW,consumer最多只能消费到HW所在的位置,另外每个replica都有HW,leader和follower各自负责更新自己的状态.,对于leader新写入的消息,consumer不能立刻消费,leader会等待该消息被所有ISR中的replica同步后更新HW,此时消息才能被Consumer消费,这样就保证了如果leader所在的broker失效,该消息仍然可以从新选举的leader中获取,对于来自内部broker的读取请求,没有HW的限制

5.6.2

由此可见,Kafka的复制机制既不是完全的同步复制,也不是单纯的异步复制。事实上,同步复制要求所有能工作的follower都复制完,这条消息才会被commit,这种方式极大的影响了吞吐率。而异步复制的方式下,follower异步的从leader复制数据,数据只要被,leader写入log就被认为已经commit,这种情况下如果follower都还没有复制完,落后于leader时,突然leader宕机,则会丢失数据,而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率,还可以设置消息发送端对于发出消息持久化机制参数acks的设置

5.6.3 模型图解释

消息中间件之Kafka(一)_第2张图片
消息中间件之Kafka(一)_第3张图片
消息中间件之Kafka(一)_第4张图片
消息中间件之Kafka(一)_第5张图片

5.7 日志分段存储

5.7.1

Kafka一个分区的消息数据对应存储在一个文件夹下,以topic名称+分区号命名,消息在分区内是分段(Segment)存储,
每个段的消息都存储在不一样的log文件里,这种特性方便old segment file快速被删除,kafka规定了一个段位的log文件
最大为1G,做这个限制的目的是为了方便把log文件加载到内存去操作

5.7.2 文件类型
  • index文件:部分消息的offset索引文件,kafka每次往分区发4K(可配置)消息就会记录一条当前消息的offset到index中,如果要定位消息的offset会在这个文件里快速定位,再去log文件里找具体消息
    00000000000000000000.index
  • log文件:消息存储文件,主要存offset和消息体 00000000000000000000.log
  • timeindex文件: 消息的发送时间索引文件,kafka每次往分区发4K(可配置)消息的发送时间戳与对应的,offset到timeindex文件,如果需要按照时间来定位消息的offset,会先在这个文件里找
    00000000000000000000.log
5.7.3

KafkaBroker有一个参数,log.setgment.bytes,限定了每个日志段文件的大小,最大就是1GB.
一个日志段文件满了,就自动开一个新的日志段文件来写入,避免单个文件过大,影响文件的读写性能,这个过程叫做log rolling,正在被写入的那个日志段文件,叫做active log segment

5.8 消费模式

  • 集群消费: 一个ConsumerGroup中,只能有一个消费者消费消息
  • 广播消费:一个ConsumerGroup中,每个消费者都可以消费到消息

6.线上规划

6.1概要设计消息中间件之Kafka(一)_第6张图片

6.2 JVM参数设置

export KAFKA_HEAP_OPTS="-Xmx16G 
-Xms16G -Xmn10G -XX:MetaspaceSize=256M 
-XX:+UseG1GC -XX:MaxGCPauseMillis=50
 -XX:G1HeapRegionSIze=16M"

Kafka是由Scala语言开发,运行在JVm上,需要对JVM参数合理设置
修改/bin/kafka-start-server.sh中的jvm设置,假设机器是32G内存,可进行如上设置:

这种大内存的情况一般都要用G1垃圾收集器,因为年轻代内存比较大,用G1可以设置GC最大停顿时间,不至于一次minor gc就花费太长时间,当然,因为像Kafka、RocketMQ ES这些中间件,写数据到磁盘会用到操作系统的Page Cache,所以JVM内存不宜分配过大,需要给操作系统的缓存预留出几个G

你可能感兴趣的:(消息中间件,kafka,分布式)