点击蓝字
关注我们
Kafka
Kafka核心技术与实战
前言
本文将带你了解kafka基础设置
一、kafka消息引擎与概述
kafka概念:
官方版本:Kafka是一款开源的消息引擎系统,根据维基百科的定义,消息引擎系统是一组规范。企业利用这组规范在不同系统之间传递语义准确的消息,实现松耦合的异步式数据传递。
民间版本:系统A发送消息给消息引擎系统,系统B从消息引擎系统中读取A发送的消息。
kafka消息编码格式:
使用纯二进制的字节序列。当然消息还是结构化的,只是在使用之前都要将其转换成二进制的字节序列。
消息传输方式:
点对点模型(消息队列)。系统A发送的消息只能被系统B接收,其他任何系统都不能读取A发送的消息
发布\订阅模型。它是一个主题topic的概念。多个发布者向相同的主题发送消息, 订阅者也可能存在多个去接收相同主题的消息。
Kafka的作用:
数据缓冲。缓冲上下游瞬时突发流量,使其更平滑。
交互解耦。发送方与接收方的松耦合,在一定程度上简化了开发,减少了系统之间不必要的交互。
思维导图:
Kafka术语:
Topic:每个业务、每个应用、每类数据都创建专属的主题。
Broker:
* 一个Kafka集群由多个Broker组成。
* 负责接收和处理客户端发送过来的请求,以及对消息进行持久化。
Partition:一个有序不变的消息队列。每个主题下可以有多个分区。
Replica:Kafka中同一条消息能够被拷贝到多个地方以提供数据冗余,这些地方就是所谓的副本。副本还分为领导者副本和追随者副本,各自有不同的角色划分。副本是在分区层级下的,即每个分区可配置多个副本实现高可用。
Producer:向Topic发布消息的客户单个应用程序。
Offset(消息位移):表示分区中每条消息的位置信息,是一个单调递增且不变的值。
Comsumer:订阅消费topic的客户端应用程序。
Consumer Offset(消费者位移):表征消费者消费进度,每个消费者都有自己的消费者位移。
Consumer Group(消费者组):多个消费者实例共同吞吐组成的一个组,同时消费多个分区以实现高吞吐。
Reblalance(重平衡):消费者组内某个消费者实例挂掉后,其他消费者实例自动重新分配订阅主题分区的过程。Rebalance是Kafka消费者端实现高可用的重要手段。
Kafka集群服务->Broke->Partitio->副本:
1、副本类型:
领导者副本(Leader Replica)
追随者副本(Follower Replica)
2、副本工作机制:生产者总是向领导者副本写消息,而消费者总是从领导者副本读消息。追随者副本只做一件事:向领导者副本发送请求,请求领导者把最新生产的消息发给他,这样它能保持与领导同步。
Kafka三层消息架构:
主题层,每个主题可以配置M个分区,而每个分区又可以配置N个副本。
分区层,每个分区的N个副本中只能有一个充当领导者角色,对外提供服务;其他N-1个副本是追随者副本,只是提供数据冗余之用。
消息层,分区中包含若干条消息,每条消息的位移从0开始,依次递增。
思维导图:
二、Kafka版本选择
Kafka版本说明:
Apache Kafka:如果你仅仅需要一个消息引擎系统亦或是简单的流处理应用场景,同时需要对系统有较大把控度,那么我推荐你使用Apache Kafka。优势在于迭代速度快,社区响应度高,使用它可以让你有更高的把控度;缺陷在于仅提供基础核心组件,缺失一些高级的特性。
Confluent Kafka:Confluent Kafka目前分为免费版和企业版两种,企业版提供了很多功能,最有用的当属跨数据中心的备份和集群监控了。如果你需要用到Kafka的一些高级特性,那么推荐你使用Confluent Kafka;缺陷在于相关文档资料不全,普及率较低,没有太多可供参考的范例。
CDH/HDP Kafka:如果你需要快速地搭建消息引擎系统,或者你需要搭建的是多框架构成的数据平台且Kafka只是其中一个组件,那么我推荐你使用这些大数据云公司提供的Kafka。优势在于操作简单,节省运维成本;缺陷在于把控度低,演进速度较慢。
思维导图:
三、Kafka使用场景优势
Kafka不止是消息引擎,也是一个分布式流处理平台(Distributed Streaming Platform)。
Kafka在设计之初就旨在提供三个方面的特性:
提供一套API实现生产者和消费者
降低网络传输和磁盘存储开销
实现高伸缩性架构
Kafka与其他主流大数据流式计算框架相比的优势:
第一点是更容易实现端到端的正确性(Correctness)。
第二点是它自己对于流式计算的定位。Streams是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统。这就是说,你不能期望着Kafka提供类似于集群调度、弹性部署等开箱即用的运维特性,你需要自己选择适合的工具或系统来帮助Kafka流处理应用实现这些功能。
Kafka的优势:
消息引擎
流处理平台
分布式存储系统
思维导图:
四、Kafka线上集群部署方案
操作系统——Linux的表现更胜一筹的原因:
1.I/O模型的使用:
什么是I/O模型呢?你可以近似地认为I/O模型就是操作系统执行I/O指令的方法。
主流的I/O模型通常有5种类型:
-
阻塞式I/O:Java中Socket对象
非阻塞式I/O:Java中Socket对象
I/O多路复用:Linux中的系统调用select函数
信号驱动I/O:大名鼎鼎的epoll系统调用。I/O模型与Kafka的关系又是什么呢?实际上Kafka客户端底层使用了Java的selector,selector在Linux上的实现机制是epoll,而在Windows平台上的实现机制是select。通情况下第四模型比第三模型要高级,比如epoll就比select要好。因此在这一点上将Kafka部署在Linux上是有优势的,因为能够获得更高效的I/O性能。
异步I/O:Windows系统提供了一个叫做IOCP线程。
2.数据网络传输效率——Kafka需要在磁盘和网络间进行大量数据传输
如果你熟悉Linux,你肯定听过零拷贝(ZeroCopy) 技术,就是当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝从而实现快速地数据传输。Linux 平台实现了这样的零拷贝机制。所以,在Linux部署Kafka能够享受到零拷贝技术所带来的快速数据传输特性。
磁盘:
HDD机械磁盘——成本低且容量大,但易损坏
SSD固态硬盘——性能优势大,不过单价高
磁盘容量:规划磁盘容量时考虑的几个因素:
新增消息数
消息存留时间
平均消息大小
备份数
是否启用压缩
带宽:
对于Kafka这种通过网络大量进行数据传输的框架而言,带宽特别容易成为瓶颈。事实上,在我接触的真实案例当中,带宽资源不足导致Kafka出现性能问题的比例至少占60%以上。如果你的环境中还涉及跨机房传输,那么情况可能就更糟了。
带宽类型:
1Gbps的千兆网络
10Gbps的万兆网络
节点数评估:
假如我们要一个小时处理1TB的数据,单节点宽带使用70%(700Mb),则Kafka使用1/3(700/3)=240Mb。由此可以得出1秒需要处理多少数据:也就是1000*1000/(60*60)=277MB,记住这是MB不是Mb,277MB*8=2216Mb(MB与Mb之间的转化是1B=8b)。单节点能处理240Mb的数据,现在有2216Mb的数据,我们需要的节点数量为: 2216/240=10(大概需要10台服务)。如果消息要额外复制两份,那么总的服务器数据需要乘以3=30。
思维导图:
![cd2dacf161cd952eeff10a92267a764d.png](https://i-blog.csdnimg.cn/blog_migrate/4c3428a8a85113cb49d6f73bdbe1c0b1.jpeg)
微信号|BIGDT_IN
扫码关注我们