Kafka简介(一)
一、简介
1.1 介绍
Kafka是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写。
Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。
特性:
1.通过O(1)的磁盘数据结构提供消息的持久化,这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
2.高吞吐量:即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。
3.支持通过Kafka服务器和消费机集群来分区消息。
4.支持Hadoop并行数据加载。
1.2 优点
1)持续的消息:为了从大数据中派生出有用的数据,任何数据的丢失都会影响生成的结果,kafka提供了一个复杂度为O(1)的磁盘结构存储数据,即使是对于TB级别的数据都是提供了一个常量时间性能。
2)高吞吐量:keep big data in mind,kafka采用普通的硬件支持每秒百万级别的吞吐量
3)分布式:明确支持消息的分区,通过kafka服务器和消费者机器的集群分布式消费,维持每一个分区是有序的。
4)支持多种语言:java、.net、php、ruby、python。
5)实时性:消息被生成者线程生产就能马上被消费者线程消费,这种特性和事件驱动的系统是相似的。
1.3 使用场景
1)用户的行为数据
2)应用工程的性能数据
3)日志的用户活动数据等
二、通信方式
2.1 名词解释【重要】
Producer:生产者,用于将流数据发送到kafka消息队列上,它的任务是向Broker发送数据。
Customer:消费者,与其它消息中间件不同,它主动向broker拉message
Customer Group:消费者组,每个customer属于一个特定的customer group,可以为每个customer指定一个group name。
Broker:代理,即一个kafka实例,即一个kafka进程,可以把Message持久化到本地磁盘;
多个Broker即多个kafka实例构成kafka集群;
每个Cluster当中会选举出一个Broker来担任Controller,负责处理Partition的Leader选举,协调Partition迁移等工作。Broker是无状态的,消费状态靠消费者维护的offset偏移量。
Topic:类别,主题
每条发布到kafka集群的消息都属于一个类别,这个类别被称为Topic;
物理上:不同Topic的消息分开存储、
逻辑上:一个Topic的消息虽然保存于一个或多个Broker上,但用户只需指定消息的Topic,即可生产或消费数据,而不用关心数据存于何处。
用于划分message的逻辑概念,可以理解为message的类别,一个topic可以分布于多个broker上,其信息存于注册中心。
Partition:分区
每个topic至少有一个partion(即每个类别至少有一个分区),
这个topic在每个broker上有多个分区partion(或无分区partion)都是ok的,即随意。
生产环境中分区数只能增不能
Offset:偏移量,offset是message在partition中的编号,offset编号不跨partition。
partition中的消息是有序的,
偏移量记录在注册中心。
Topic和Partition
该图可以看到,消息是按照类别topic来提交到partition当中的。
Partition当中的消息是有序的,consumer从一个有序的分区消息队列中顺序获取消息。
相关名次定义如下:
1.Topic:用于划分Message的逻辑概念,一个Topic可以分布在多个Broker上。
2.Partition:是Kafka中横向扩展和一切并行化的基础,每个Topic都至少被切分为1个Partition。
3.offset:消息在Partition中的编号,编号顺序不跨Partition。
Replication:备份机制,每个分区partition都有自己的镜像分区来保证高可用,该分区和备份分区不在同一台物理机上。
其中一个分区为leader,若leader挂了则会选举新的leader。
Replica个数为所有分区的份数,如下4个partition,2个replica。
AR(Assigned Replicas):所有已注册副本,AR = ISR + OSR。为保证高可用,参数offsets.topic.replication.factor设置大于1,比如3。
ISR(In-Sync Replicas):副本同步队列,由leader维护,follower从leader同步数据有一些延迟(包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度,版本0.10.x中只支持replica.lag.time.max.ms这个维度) ,任意一个超过阈值都会把follower剔除出ISR, 存入OSR。
注:Kafka 0.10.x版本后移除了replica.lag.max.messages参数,只保留了replica.lag.time.max.ms作为ISR中副本管理的参数。为什么这样做呢?replica.lag.max.messages表示当前某个副本落后leaeder的消息数量超过了这个参数的值,那么leader就会把follower从ISR中删除。假设设置replica.lag.max.messages=4,那么如果producer一次传送至broker的消息数量都小于4条时,因为在leader接受到producer发送的消息之后而follower副本开始拉取这些消息之前,follower落后leader的消息数不会超过4条消息,故此没有follower移出ISR,所以这时候replica.lag.max.message的设置似乎是合理的。但是producer发起瞬时高峰流量,producer一次发送的消息超过4条时,也就是超过replica.lag.max.messages,此时follower都会被认为是与leader副本不同步了,从而被踢出了ISR。但实际上这些follower都是存活状态的且没有性能问题。那么在之后追上leader,并被重新加入了ISR。于是就会出现它们不断地剔出ISR然后重新回归ISR,这无疑增加了无谓的性能损耗。而且这个参数是broker全局的。设置太大了,影响真正“落后”follower的移除;设置的太小了,导致follower的频繁进出。无法给定一个合适的replica.lag.max.messages的值,故此,新版本的Kafka移除了这个参数。
OSR(Outof-Sync Replicas):副本未同步队列,ISR中超过阈值的flower会被踢出ISR加入OSR,新加入的flower也会先存放在OSR。
HW(High Watermark):高水位,每个replica都有自己的HW,replica中各partition对应ISR最小(越小越旧)的LEO作为HW,即最后commit的offset,consumer最多只能消费到HW所在的位置。
LEO(log end offset):日志尾部偏移量,每个partition都有自己的LEO,是每个partition日志中的最后的offset,可能未被commit。
Coordinator:中心协调器,0.10.x版本及之后才有,为所有Consumer Group的子集选举出一个Broker作为Coordinator,由它来管理Consumer的增减,然后生成Rebalance命令,并检查是否这些Rebalance。
2.2 拓扑图
以下的组件在分布式环境中均可以是多个,
ZK仅和Broker和Customer有关。
Broker是无状态的,消费的状态依靠消费者维护partition的offset偏移量,message依靠消费者主动拉取。
Brokers中的Controller,主要负责Partition管理和副本状态管理,也会执行类似重分配partition之类的管理任务,如处理Partition的Leader选举等。
2.3 局部有序性
Producer从0开始生产,进入不同的分区按进入顺序从0开始排列,消费者从0开始消费,这就保证了单个分区的消息有序性,但无法保证全局有序性。
2.4 ZK存储结构
说明: 本人原创,后续会继续更新增加内容;
如有错误之处,敬请指出,不胜感谢,共同学习共同进步