文章目录

kafka官方文档
使用场景
Kafka基本概念
- 消息( Message )相关术语
- 主题Topic & 消息日志Log
- 分布式Distribution
- Producers
- Consumers
消费顺序

kafka官方文档

官网： https://kafka.apache.org/

快速开始： https://kafka.apache.org/documentation/#quickstart

Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统 .

Kafka的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等.

Kafka用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

使用场景

日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种 consumer，例如hadoop、Hbase、ES等
消息系统：解耦和生产者和消费者、缓存消息等
用户活动跟踪：记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到 hadoop、数据仓库中做离线分析和挖掘
运营指标：收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告

我们来看个常见的系统架构图

Kafka基本概念

kafka是一个分布式的，分区的消息(官方称之为 commit log )服务。

它提供一个消息系统应该具备的功能，但是确有着独特的设计，Kafka借鉴了JMS规范的思想，但是确并没有完全遵循JMS规范。

消息( Message )相关术语

首先，我们来看一下基础的消息( Message )相关术语：

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

因此，从一个较高的层面上来看，producer通过网络发送消息到Kafka集群，然后consumer来进行消费,如下图：

服务端(brokers)和客户端(producer、consumer)之间通信通过TCP协议来完成。

主题Topic & 消息日志Log

让我们首先深入理解Kafka提出一个高层次的抽象概念-Topic。

Topic是一个类别的名称，同类消息发送到同一个Topic下面。对于每一个Topic，下面可以有多个分区(Partition)日志文件.

Partition是一个有序的message序列，这些message按顺序添加到一个叫做commit log的文件中。

每个partition中的消息都有一个唯一的编号，称之为offset，用来唯一标示某个分区中的message。

注：每个partition，都对应一个commit log文件。一个partition中的message的offset都是唯一的，但是不同的partition中的message的offset可能是相同的

可以这么来理解Topic，Partition和Broker：

一个topic，代表逻辑上的一个业务数据集，比如按数据库里不同表的数据操作消息区分放入不同topic，订单相关操作消息放入订单topic，用户相关操作消息放入用户topic.

对于大型网站来说，后端数据都是海量的，订单消息很可能是非常巨量的，比如有几百个G甚至达到TB级别，如果把这么多数据都放在一台机器上可定会有容量限制问题，那么就可以topic内部划分多个partition来分片存储数据，不同的partition可以位于不同的机器上，每台机器上都运行一个Kafka的进程Broker.

kafka集群，在配置的时间范围内，维护所有的由producer生成的消息，而不管这些消息有没有被消费.

例如日志保留(log retention )时间被设置为2天。kafka会维护最近2天生产的所有消息，而2天前的消息会被丢弃。kafka的性能与保留的数据量的大小没有关系，因此保存大量的数据(日志信息)不会有什么影响。

每个consumer是基于自己在commit log中的消费进度(offset)来进行工作的。在kafka中，消费offset由consumer自己来维护；一般情况下我们按照顺序逐条消费commit log中的消息，当然我可以通过指定offset来重复消费某些消息，或者跳过某些消息。

这意味kafka中的consumer对集群的影响是非常小的，添加一个或者减少一个consumer，对于集群或者其他consumer来说，都是没有影响的，因为每个consumer维护各自的offset。所以说kafka集群是无状态的，性能不会因为consumer数量受太多影响。kafka还将很多关键信息记录在zookeeper里，保证自己的无状态，从而在水平扩容时非常方便。

为什么要对Topic下数据进行分区存储？

commit log文件会受到所在机器的文件系统大小的限制，分区之后，理论上一个topic可以处理任意数量的数据。
为了提高并行度。

分布式Distribution

log的partitions分布在kafka集群中不同的broker上，每个broker可以请求备份其他broker上partition上的数据。kafka集群支持配置一个partition备份的数量。

针对每个partition，都有一个broker起到“ leader ”的作用，0个或多个其他的broker作为“ follwers ”的作用。

leader处理所有的针对这个partition的读写请求，而followers被动复制leader的结果。如果这个leader失效了，其中的一个follower将会自动的变成新的leader。

Producers

生产者将消息发送到topic中去，同时负责选择将message发送到topic的哪一个partition中。通过 round-robin 做简单的负载均衡。也可以根据消息中的某一个关键字来进行区分。通常第二种方式使用的更多。

Consumers

传统的消息传递模式有2种：队列( queue) 和（publish-subscribe）

queue模式：多个consumer从服务器中读取数据，消息只会到达一个consumer。
publish-subscribe模式：消息会被广播给所有的consumer。

Kafka基于这2种模式提供了一种consumer的抽象概念： consumer group 。

queue模式：所有的consumer都位于同一个consumer group 下。
publish-subscribe模式：所有的consumer都有着自己唯一的consumer group。

图例说明：由2个broker组成的kafka集群，总共有4个partition(P0-P3)。这个集群由2个Consumer Group， A有2个consumer instances ，B有四个。

可以看到，每个Consumer属于一个特定的ConsumerGroup，一条消息可以被多个不同的Consumer Group消费，但是一个Consumer Group中只能有一个Consumer能够消费该消息。

通常一个topic会有几个consumer group，每个consumer group都是一个逻辑上的订阅者（ logicalsubscriber ）。每个consumer group由多个consumer instance组成，从而达到可扩展和容灾的功能。

消费顺序

Kafka比传统的消息系统有着更强的顺序保证。

一个partition同一个时刻在一个consumer group中只有一个consumer instance在消费，从而保证顺序。 consumer group中的consumer instance的数量不能比一个Topic中的partition的数量多，否则，多出来的consumer消费不到消息。

Kafka只在partition的范围内保证消息消费的局部顺序性，不能在同一个topic中的多个partition中保证总的消费顺序性。

如果有在总体上保证消费顺序的需求，那么我们可以通过将topic的partition数量设置为1，将consumer group中的consumer instance数量也设置为1。

从较高的层面上来说的话，Kafka提供了以下的保证：

发送到一个Topic中的message会按照发送的顺序添加到commit log中。意思是，如果消息 M1，M2由同一个producer发送，M1比M2发送的早的话，那么在commit log中，M1的offset就会比commit 2的offset小。
一个consumer在commit log中可以按照发送顺序来消费message。
如果一个topic的备份因子设置为N，那么Kafka可以容忍N-1个服务器的失败，而存储在commit log中的消息不会丢失。

Apache Kafka-初体验Kafka(01)-入门整体认识kafka相关推荐

【Spark深入学习 -15】Spark Streaming前奏-Kafka初体验
----本节内容------- 1.Kafka基础概念 1.1 出世背景 1.2 基本原理 1.2.1.前置知识 1.2.2.架构和原理 1.2.3.基本概念 1.2.4.kafka特点 2.Kafk ...
Java开发 - 消息队列之Kafka初体验
目录前言 Kafka 什么是Kafka Kafka软件结构 Kafka的特点怎么启动Kafka 下载Kafka 配置Kafka Zookeeper 启动Kafka Kafka案例添加依赖添加配 ...
php的swoole教程,PHP + Swoole2.0 初体验（swoole入门教程）
PHP + Swoole2.0 初体验(swoole入门教程) 环境:centos7 + PHP7.1 + swoole2.0 准备工作: 一. swoole 扩展安装 1 .下载swoole cd/ ...
kafka java api 删除_Kafka入门系列—6. Kafka 常用命令及Java API使用
常用命令启动Zookeeper ./zkServer.sh start-foreground 可选参数: ./zkServer.sh {start|start-foreground|stop|res ...
Apache Mahout初体验
1.Mahout是什么? Mahout是一个算法库,集成了很多算法. Apache Mahout 是 Apache Software Foundation(ASF)旗下的一个开源项目,提供一些可扩展的 ...
Confluent之Kafka Connector初体验
概述背景 Apache Kafka 是最大.最成功的开源项目之一,可以说是无人不知无人不晓,在前面的文章<Apache Kafka分布式流处理平台及大厂面试宝典>我们也充分认识了Kafk ...
源码系列第1弹 | 带你快速攻略Kafka源码之旅入门篇
大家过年好,我是华仔, 又跟大家见面了. 从今天开始我将为大家奉上 Kafka 源码剖析系列文章,正式开启「Kafka的源码之旅」,跟我一起来掌握 Kafka 源码核心架构设计思想吧. 今天这篇我 ...
《KAFKA官方文档》入门指南（二）
把功能组合起来消息的传输,存储和流处理的组合看似不寻常却是Kafka作为流处理平台的关键. 像HDFS分布式文件系统,允许存储静态文件进行批量处理.像这样的系统允许存储和处理过去的历史数据. 传统的 ...
光速入门消息队列Kafka
文章目录光速入门消息队列Kafka 消息队列知识要点 2.1 背景.问题的产生 2.2 消息队列应运而生 2.3 消息队列的特点认识kafka 知识要点 2.1 认识kafka 2.2 kafk ...

Apache Kafka-初体验Kafka(01)-入门整体认识kafka