大数据-52 Kafka 基础概念和根本架构 核心API介绍 应用场景等 ...

打印 上一主题 下一主题

主题 527|帖子 527|积分 1581

点一下关注吧!!!非常感谢!!持续更新!!!

现在已经更新到了:



  • Hadoop(已更完)
  • HDFS(已更完)
  • MapReduce(已更完)
  • Hive(已更完)
  • Flume(已更完)
  • Sqoop(已更完)
  • Zookeeper(已更完)
  • HBase(已更完)
  • Redis (已更完)
  • Kafka (正在更新…)
章节内容

上节我们完成了如下的内容:


  • Redis高可用 CAP-AP
  • Redis主从模式
  • Redis一主一从 一主多从
  • Redis哨兵模式
  • Redis哨兵模式 docker-compose测试
终于!我们更新完了Redis!现在我们开始更新Kafka。
Kafka介绍

Kafka最初是由Linkedin公司开发,是一个分布式、分区的、多副本、多生产者、多消费者、基于ZK的。
常见用于 Nginx 日志、消息服务。在2010年贡献给了Apache基金会成为顶级开源项目。
Kafka主要设计目标如下:


  • 以时间复杂度为O(1)的方式提供消息恒久化的本领,即使TB级数据也能包管常数访问。
  • 高吞吐率,即使在非常便宜的机器上也可以有每秒100K条消息的传输
  • 支持KafkaServer间的消息分区,及分布式消费,同时包管每个Partition内的消息顺序传输。
  • 同时支持离线数据处置惩罚和实时数据处置惩罚
  • 支持在线水平扩展

生产消费图


消息模式

主流的消息转达有两种方式:点对点和发布订阅,Kafka属于 发布-订阅 模式的一种
对于消息中间件,消息会分为:拉、推。Kafka消息只有拉取,没有推送。(可以用轮询实现推送)


  • Kafka在一个或多个可以跨域多个数据中心的服务器上作为集群运行
  • Kafka集群按照主题分类管理,一个主题可以多个分区,一个分区可以有多个副天职区
  • 每个记录由一个键,一个值和一个时间戳组成。
核心API



  • ProducerAPI:允许应用步伐记录流发布到一个或者多个Kafka主题
  • ConsumerAPI:允许应用步伐订阅一个或多个主题并处置惩罚并生成记录流
  • StreamAPI:允许应用步伐充当流处置惩罚器,使用一个或多个主题的输入流,并生成一个或者多个输出流。从而有效的将输入流转换为输出流。
  • ConnectorAPI:允许构建和运行将Kafka主题毗连到现有应用步伐或数据体系的可重用生产者或使用者
Kafka优势



  • 高吞吐:单机每秒处置惩罚几十百万的消息量,即使存储了TB消息,也可以或许稳定运行
  • 高性能:单节点支持上千个客户端,并包管零停机和零数据丢失。
  • 恒久化数据存储:将消息恒久化,通过数据恒久化到磁盘以及replication防止数据丢失。
  • 分布式体系,易于向外扩展。所有Producer和Consumer等都可以有多个,分布式的,无需停机扩展。
  • Kafka是分布式、分区、复制、容错的
  • 客户端状态维护:消息被处置惩罚的状态在Consumer端维护,而不是由Server维护,失败可以或许自动平衡
  • 支持online和offline场景
  • 支持多种语言
应用场景



  • 日志网络:可以用Kakfa进行日志的网络
  • 消息体系:解耦生产者和消费者
  • 用户活动跟踪:用户举动被记录到Kafka中,消费者取到之后对用户的数据进行分析处置惩罚
  • 运营指标:记录运营监控数据、报警和报告
  • 流式处置惩罚:好比SparkStream、Storm
根本架构

消息和批次



  • Kafka的数据单位称为消息,可以把消息看成是数据库里的一个数据行或者一条记录。消息由字节组组成。
  • 消息由键,键也是一个字节数组,当消息以一种可控的方式写入不同的分区时,会用到键。
  • 为了进步效率,消息被分批写入Kafka,批次就是一组消息,这些消息属于同一个主题和分区。
  • 把消息分批次可以减少网络开销,批次越大,单位时间内处置惩罚的消息就越多,单个消息传输的时间久越长。
消息模式



  • 消息模式(schema)有很多可用的选项。如 JSON、XML,他们缺乏强类型的处置惩罚本领。
  • Kafka的开发者喜好使用ApacheAvro,提供了一种紧凑序列格式化,模式和消息体分开。当模式发生变化时,不需要重新生成代码,它还支持强类型和模式进化。
  • 数据格式一致性对Kafka很紧张,由于它消除了消息读写利用之间的耦合性。
主题和分区

Kafka的消息通过主题进行分类,主题可比数据库表或者文件体系里的文件夹。主题可以被分为多少区域,一个主题通过分区分布于Kafka集群中,提供了横向扩展的本领。

生产和消费者

生产者创建消息,消费者消费消息。
生产者在默认的情况下会把消息均衡的发布到主题的所有分区上:


  • 直接指定消息的分区
  • 根据消息的key散列取模得出分区
  • 轮询指定分区
消费者通过偏移量来区分已经读过的消息,从而消费消息。
消费者是消费组的一部门,消费组包管每个分区只有一个消费者使用,避免重复消费。

Broker 和 集群

一个独立的Kafka服务器成为Broker,Broker担当来自生产者的消息,为消息设置偏移量,并提交到磁盘进行保存。
Broker为消费者提供服务,对读取分区的哀求做出响应,返回已提交到磁盘上的消息。
单个Broker可以轻松处置惩罚数千个分区以及每秒百万的消息量。

每一个集群都有一个Broker是集群控制器(自动从集群的活跃成员中推举出来)
控制器负责管理工作:


  • 将分区分配给Broker
  • 监控Broker
集群中一个分区属于一个Broker,该Broker称为分区首领。


  • 一个分区可以分配给多个Broker,此时会发生分区复制。
  • 分区的复制进步了消息冗余、高可用。
  • 副天职区不负责处置惩罚消息的读写。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

用户国营

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表