Kafka
Kafka是最初由Linkedin公司开发,是一个分布式、支持分区的(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
1.前言
消息队列的性能好坏,其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度,分析Kafka是如何实现高效文件存储,及实际应用效果。
1.1  Kafka的特性:
- 高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个topic可以分多个partition, consumer group 对partition进行consume操作。
- 可扩展性:kafka集群支持热扩展
- 持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失
- 容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败)
- 高并发:支持数千个客户端同时读写
1.2   Kafka的使用场景:
- 日志收集:一个公司可以用Kafka可以收集各种服务的log,通过kafka以统一接口服务的方式开放给各种consumer,例如hadoop、Hbase、Solr等。
- 消息系统:解耦和生产者和消费者、缓存消息等。
- 用户活动跟踪:Kafka经常被用来记录web用户或者app用户的各种活动,如浏览网页、搜索、点击等活动,这些活动信息被各个服务器发布到kafka的topic中,然后订阅者通过订阅这些topic来做实时的监控分析,或者装载到hadoop、数据仓库中做离线分析和挖掘。
- 运营指标:Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据,生产各种操作的集中反馈,比如报警和报告。
- 流式处理:比如spark streaming和storm
- 事件源
1.3  Kakfa的设计思想
- Kakfa Broker Leader的选举:Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点,因为只有一个Kafka Broker会注册成功,其他的都会失败,所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller,其他的Kafka broker叫Kafka Broker follower。(这个过程叫Controller在ZooKeeper注册Watch)。这个Controller会监听其他的Kafka Broker的所有信息,如果这个kafka broker controller宕机了,在zookeeper上面的那个临时节点就会消失,此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点,因为只有一个Kafka Broker会注册成功,其他的都会失败,所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller,其他的Kafka broker叫Kafka Broker follower。
例如:一旦有一个broker宕机了,这个kafka broker controller会读取该宕机broker上所有的partition在zookeeper上的状态,并选取ISR列表中的一个replica作为partition leader(如果ISR列表中的replica全挂,选一个幸存的replica作为leader; 如果该partition的所有的replica都宕机了,则将新的leader设置为-1,等待恢复,等待ISR中的任一个Replica“活”过来,并且选它作为Leader;或选择第一个“活”过来的Replica(不一定是ISR中的)作为Leader),这个broker宕机的事情,kafka controller也会通知zookeeper,zookeeper就会通知其他的kafka broker。
-  Consumergroup:各个consumer(consumer 线程)可以组成一个组(Consumer group ),partition中的每个message只能被组(Consumer group )中的一个consumer(consumer 线程)消费,如果一个message可以被多个consumer(consumer 线程)消费的话,那么这些consumer必须在不同的组。
Kafka不支持一个partition中的message由两个或两个以上的同一个consumer group下的consumer thread来处理,除非再启动一个新的consumer group。所以如果想同时对一个topic做消费的话,启动多个consumer group就可以了,但是要注意的是,这里的多个consumer的消费都必须是顺序读取partition里面的message,新启动的consumer默认从partition队列最头端最新的地方开始阻塞的读message。
- Consumer Rebalance的触发条件:(1)Consumer增加或删除会触发 Consumer Group的Rebalance(2)Broker的增加或者减少都会触发 Consumer Rebalance
- Consumer: Consumer处理partition里面的message的时候是o(1)顺序读取的。所以必须维护着上一次读到哪里的offsite信息。
- Topic & Partition:Topic相当于传统消息系统MQ中的一个队列queue,producer端发送的message必须指定是发送到哪个topic,但是不需要指定topic下的哪个partition,因为kafka会把收到的message进行load balance,均匀的分布在这个topic下的不同的partition上( hash(message) % [broker数量]  )。物理上存储上,这个topic会分成一个或多个partition,每个partiton相当于是一个子queue。在物理结构上,每个partition对应一个物理的目录(文件夹),文件夹命名是[topicname]_[partition]_[序号],一个topic可以有无数多的partition,根据业务需求和数据量来设置。在kafka配置文件中可随时更高num.partitions参数来配置更改topic的partition数量,在创建Topic时通过参数指定parittion数量。Topic创建之后通过Kafka提供的工具也可以修改partiton数量。
一般来说,(1)一个Topic的Partition数量大于等于Broker的数量,可以提高吞吐率。(2)同一个Partition的Replica尽量分散到不同的机器,高可用。

- Partition Replica:每个partition可以在其他的kafka broker节点上存副本,以便某个kafka broker节点宕机不会影响这个kafka集群。存replica副本的方式是按照kafka broker的顺序存。例如有5个kafka broker节点,某个topic有3个partition,每个partition存2个副本,那么partition1存broker1,broker2,partition2存broker2,broker3。。。以此类推(replica副本数目不能大于kafka broker节点的数目,否则报错。这里的replica数其实就是partition的副本总数,其中包括一个leader,其他的就是copy副本)。这样如果某个broker宕机,其实整个kafka内数据依然是完整的。但是,replica副本数越高,系统虽然越稳定,但是回来带资源和性能上的下降;replica副本少的话,也会造成系统丢数据的风险。
- Partition leader与follower:partition也有leader和follower之分。leader是主partition,producer写kafka的时候先写partition leader,再由partition leader push给其他的partition follower。partition leader与follower的信息受Zookeeper控制,一旦partition leader所在的broker节点宕机,zookeeper会冲其他的broker的partition follower上选择follower变为parition leader。
- Topic分配partition和partition replica的算法:(1)将Broker(size=n)和待分配的Partition排序。(2)将第i个Partition分配到第(i%n)个Broker上。(3)将第i个Partition的第j个Replica分配到第((i + j) % n)个Broker上

kafka在所有broker中选出一个controller,所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式(比Zookeeper Queue的方式更高效)通知需为此作出响应的Broker。同时controller也负责增删Topic以及Replica的重新分配。

为何高吞吐量?
它不能像AMQ那样可以多个BET作为consumer去互斥的(for update悲观锁)并发处理message,这是因为多个BET去消费一个Queue中的数据的时候,由于要保证不能多个线程拿同一条message,所以就需要行级别悲观所(for update),这就导致了consume的性能下降,吞吐量不够。而kafka为了保证吞吐量,只允许同一个consumer group下的一个consumer线程去访问一个partition。如果觉得效率不高的时候,可以加partition的数量来横向扩展,那么再加新的consumer thread去消费。如果想多个不同的业务都需要这个topic的数据,起多个consumer group就好了,大家都是顺序的读取message,offsite的值互不影响。这样没有锁竞争,充分发挥了横向的扩展性,吞吐量极高。这也就形成了分布式消费的概念。
当启动一个consumer group去消费一个topic的时候,无论topic里面有多个少个partition,无论我们consumer group里面配置了多少个consumer thread,这个consumer group下面的所有consumer thread一定会消费全部的partition;即便这个consumer group下只有一个consumer thread,那么这个consumer thread也会去消费所有的partition。因此,最优的设计就是,consumer group下的consumer thread的数量等于partition数量,这样效率是最高的。
同一partition的一条message只能被同一个Consumer Group内的一个Consumer消费。不能够一个consumer group的多个consumer同时消费一个partition。

转载于:https://www.cnblogs.com/jay763190097/p/10996851.html

kafka原理概念提炼相关推荐

  1. python使用kafka原理详解真实完整版_史上最详细Kafka原理总结

    Kafka Kafka是最初由Linkedin公司开发,是一个分布式.支持分区的(partition).多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实 ...

  2. Kafka基本概念与术语

    本文来说下kafka的基本概念与术语 文章目录 消息队列 kafka架构图 Kafka相关概念及术语 本文小结 消息队列 把数据放到消息队列叫做生产者.从消息队列里边取数据叫做消费者. 消息队列,我们 ...

  3. Kafka原理——fabric1.0版本中的节点排序方法

    Kafka原理 可参考Zookeeper一起理解,后续自己在项目中实现,会再来补充一些实践的内容. Zookeeper整理:https://blog.csdn.net/yangwei256/artic ...

  4. Kafka原理+操作+实战

    Kafka原理+操作+实战 前面我和大家交流了kafka的部署安装.对于部署安装这都是小意思,不值得太多的提及.重点还是需要知道kafka原理.熟练掌握kafka命令以及灵活用于kafka场景. 干货 ...

  5. Kafka原理篇:图解kakfa架构原理

    我想很多同学之前可能已经看过很多 Kafka 原理相关的文章,但往往看时"牛逼"声连连,激情满满,总觉得自己又学习到了各种"吊炸天"的技术.但很多同学往往是不觉 ...

  6. Kafka从入门到精通(八)Kafka原理

    1. 监控工具Kafka-eagle介绍 省略 2. Kafka原理 2.1 分区的leader与follower 2.1.1 Leader和Follower 在Kafka中,每个topic都可以配置 ...

  7. Kafka原理--时间轮(延时操作)

    原文网址:Kafka原理--时间轮(延时操作)_IT利刃出鞘的博客-CSDN博客 简介 说明         本文介绍Kafka的时间轮的原理. Kafka没有延迟队列功能供用户使用,本文介绍的延时操 ...

  8. Kafka原理篇:图解kafka架构原理

    今天我们来深入讲解 Kafka 的架构和实现原理.[码哥]将从架构和细节入手,以生动的图深入讲解 Kafka 的实现原理. 我想很多同学之前可能已经看过很多 Kafka 原理相关的文章,但往往看时&q ...

  9. kafka(一)--概念理解

    目录 第一篇文章部分信息 什么是卡夫卡? 卡夫卡术语 Kafka 主题剖析 分区和代理 生产者 消费者和消费者团体 第二篇文章部分信息 2.Kafka文件存储机制 第一篇文章部分信息 原文:https ...

最新文章

  1. 浙江大学计算机研究生分数线初试单科学科,2016年浙江大学计算机考研复试分数线_浙江大学考研分数线...
  2. 定位城市_北方城市如何利用GPS定位器减轻铲雪工作压力?
  3. javascript函数上的prototype属性的理解
  4. java new url 带密码_获取密码重置URL
  5. IJ-java-com-util-common:
  6. 工作187:表单校验规则
  7. 寻找链表中值域最小的节点并移到链表的最前面
  8. GraphQL从入门到实战
  9. 【2017-2018 ACM-ICPC, Central Europe Regional Contest (CERC 17)】Justified Jungle【树上思维题】
  10. 【数据结构 严蔚敏版】 循环队列 基本操作
  11. 学习sift算法的原理和步骤_大白话人工智能算法-第32节集成学习之通俗理解XGBoost原理和过程
  12. QCC3071与QCC3072有什么区别?
  13. Zbrush curve Tube ,Move topologica笔刷的使用
  14. 基于单幅图像Patch Map的稳健除雾(PMS-Net: Robust Haze Removal Based on Patch Map for Single Images_CVPR_2019)
  15. 设置swiper中的高度
  16. 沉痛悼念张孝祥老师逝世
  17. git 创建关联远程分支报错Did you intend to checkout ‘origin/branchName‘ which can not be resolved as commit?
  18. VisualDMIS 6.5探测误差程序(25点球)
  19. Python机器学习基础
  20. android:很抱歉,XXX已停止运行

热门文章

  1. ureport2 + spring boot 搭建
  2. bzoj 1026: [SCOI2009]windy数
  3. ssm整合spring,springmvc,mybatis-day12
  4. [学习OpenCV攻略][001][Ubuntu安装及配置]
  5. 编程学习好去处:35 个快速学习的编程网站
  6. 将Windows日志转换为Syslog
  7. protel中PCB板大小的自定义方法
  8. mysql执行脚本的方法
  9. impala的详细介绍--图文描述
  10. 【Scala】Scala中常见集合的使用---代码详解