Kafka是啥?用Kafka官方的话来说就是:

Kafka is used for building real-time data pipelines and streaming apps. It is horizontally scalable, fault-tolerant, wicked fast, and runs in production in thousands of companies.

大致的意思就是,这是一个实时数据处理系统,可以横向扩展、高可靠,而且还变态快,已经被很多公司使用。

那么什么是实时数据处理系统呢?顾名思义,实时数据处理系统就是数据一旦产生,就要能快速进行处理的系统。

对于实时数据处理,我们最常见的,就是消息中间件了,也叫MQ(Message Queue,消息队列),也有叫Message Broker的。

这篇文章,我将从消息中间件的角度,带大家看看Kafka的内部结构,看看它是如何做到横向扩展、高可靠的同时,还能变态快的。

为什么需要消息中间件

消息中间件的作用主要有两点:

  • 解耦消息的生产和消费。
  • 缓冲。

想象一个场景,你的一个创建订单的操作,在订单创建完成之后,需要触发一系列其他的操作,比如进行用户订单数据的统计、给用户发送短信、给用户发送邮件等等,就像这样:

createOrder(...){
...
statOrderData(...);
sendSMS();
sendEmail();
}

代码这样写似乎没什么问题,可是过了一段时间,你给系统引进了一个用户行为分析服务,它也需要在订单创建完成之后,进行一个分析用户行为的操作,而且随着系统的逐渐壮大,创建订单之后要触发的操作也就越来越多,代码也渐渐膨胀成这样:

createOrder(...){
...
statOrderData(...);
sendSMS();
sendEmail();
// new operation
statUserBehavior(...);
doXXX(...);
doYYY(...);
// more and more operations
...
}

导致代码越来越膨胀的症结在于,消息的生产和消费耦合在一起了。createOrder方法不仅仅要负责生产“订单已创建”这条消息,还要负责处理这条消息。

这就好比BBC的记者,在知道皇马拿到欧冠冠军之后,拿起手机,翻开皇马球迷通讯录,给球迷一个一个打电话,告诉他们,皇马夺冠了。

事实上,BBC的记者只需要在他们官网发布这条消息,然后球迷自行访问BBC,去上面获取这条新闻;又或者球迷订阅了BBC,那么订阅系统会主动把发布在官网的消息推送给球迷。

同样,createOrder也需要一个像BBC官网那样的载体,也就是消息中间件,在订单创建完成之后,把一条主题为“orderCreated”的消息,放到消息中间件去就ok了,不必关心需要把这条消息发给谁。这就完成了消息的生产。

至于需要在订单创建完成之后触发操作的服务,则只需要订阅主题为“orderCreated”的消息,在消息中间件出现新的“orderCreated”消息时,就会收到这条消息,然后进行相应的处理。

因此,通过使用消息中间件,上面的代码也就简化成了:

createOrder(...){
...
sendOrderCreatedMessage(...);
}

以后如果在订单创建之后有新的操作需要执行,这串代码也不需要修改,只需要给对消息进行订阅即可。

另外,通过这样的解耦,消费者在消费数据时更加的灵活,不必每次消息一产生就要马上去处理(虽然通常消费者侧也会有线程池等缓冲机制),可以等自己有空了的时候,再过来消息中间件这里取数据进行处理。这就是消息中间件带来的缓冲作用。

Kafka一代 - 消息队列

从上面的描述,我们可以看出,消息中间件之所以可以解耦消息的生产和消费,主要是它提供了一个存放消息的地方——生产者把消息放进来,消费者在从中取出消息进行处理。

那么这个存放消息的地方,应该采用什么数据结构呢?

在绝大多数情况下,我们都希望先发送进来的消息,可以先被处理(FIFO),这符合大多数的业务逻辑,少数情况下我们会给消息设置优先级。不管怎样,对于消息中间件来说,一个先进先出的队列,是非常合适的数据结构:

图片来源:LinkedIn.com

那么要怎样保证消息可以被顺序消费呢?

消费者过来获取消息时,每次都把index=0的数据返回过去,然后再删除index=0的那条数据?

很明显不行,因为订阅了这条消息的消费者数量,可能是0,也可能是1,还可能大于1。如果每次消费完就删除了,那么其他订阅了这条消息的消费者就获取不到这条消息了。

事实上,Kafka会对数据进行持久化存储(至于存放多长时间,这是可以配置的),消费者端会记录一个offset,表明该消费者当前消费到哪条数据,所以下次消费者想继续消费,只需从offset+1的位置继续消费就好了。

消费者甚至可以通过调整offset的值,重新消费以前的数据。

那么这就是Kafka了吗?不,这只是一条非常普通的消息队列,我们姑且叫它为Kafka一代吧。

这个Kafka一代用一条消息队列实现了消息中间件,这样的简单实现存在不少问题:

  • Topic鱼龙混杂。想象一下,一个只订阅了topic为“A”的消费者,却要在一条有ABCDEFG…等各种各样topic的队列里头去寻找topic为A的消息,这样性能岂不是很慢?
  • 吞吐量低。我们把全部消息都放在一条队列了,请求一多,它肯定应付不过来。

由此就引申出了Kafka二代

Kafka二代 - Partition

要解决Kafka一代的那两个问题,很简单——分布存储

二代Kafka引入了Partition的概念,也就是采用多条队列, 每条队列里面的消息都是相同的topic:

图片来源:LinkedIn.com

Partition的设计解决了上面提到的两个问题:

  • 纯Topic队列。一个队列只有一种topic,消费者再也不用担心会碰到不是自己想要的topic的消息了。
  • 提高吞吐量。不同topic的消息交给不同队列去存储,再也不用以一敌十了。

一个队列只有一种topic,但是一种topic的消息却可以根据自定义的key值,分散到多条队列中。也就是说,上图的p1和p2,可以都是同一种topic的队列。不过这是属于比较高级的应用了,以后有机会再和大家讨论。

Kafka二代足够完美了吗?当然不是,我们虽然通过Partition提升了性能,但是我们忽略了一个很重要的问题——高可用

万一机器挂掉了怎么办?单点系统总是不可靠的。我们必须考虑备用节点和数据备份的问题。

Kafka三代 - Broker集群

很明显,为了解决高可用问题,我们需要集群

Kafka对集群的支持也是非常友好的。在Kafka中,集群里的每个实例叫做Broker,就像这样:

图片来源:sookocheff.com

每个partition不再只有一个,而是有一个leader(红色)和多个replica(蓝色),生产者根据消息的topic和key值,确定了消息要发往哪个partition之后(假设是p1),会找到partition对应的leader(也就是broker2里的p1),然后将消息发给leader,leader负责消息的写入,并与其余的replica进行同步。

一旦某一个partition的leader挂掉了,那么只需提拔一个replica出来,让它成为leader就ok了,系统依旧可以正常运行。

通过Broker集群的设计,我们不仅解决了系统高可用的问题,还进一步提升了系统的吞吐量,因为replica同样可以为消费者提供数据查找的功能。

链接:https://zhuanlan.zhihu.com/p/37405836
来源:知乎

kafka 实战,包含安装使用 ,在java程序中使用kafka

https://www.cnblogs.com/hei12138/p/7805475.html

kafka 基本原理简介的更多相关文章

  1. Kafka 基本原理

    Kafka 基本原理   来源:阿凡卢 , www.cnblogs.com/luxiaoxun/p/5492646.html 简介 Apache Kafka是分布式发布-订阅消息系统.它最初由Link ...

  2. kafka原理简介并且与RabbitMQ的选择

    kafka原理简介并且与RabbitMQ的选择 kafka原理简介,rabbitMQ介绍,大致说一下区别 Kafka是由LinkedIn开发的一个分布式的消息系统,使用Scala编写,它以可水平扩展和 ...

  3. 替代Flume——Kafka Connect简介

    我们知道过去对于Kafka的定义是分布式,分区化的,带备份机制的日志提交服务.也就是一个分布式的消息队列,这也是他最常见的用法.但是Kafka不止于此,打开最新的官网. 我们看到Kafka最新的定义是 ...

  4. 最简单流处理引擎——Kafka Streaming简介

    Kafka在0.10.0.0版本以前的定位是分布式,分区化的,带备份机制的日志提交服务.而kafka在这之前也没有提供数据处理的顾服务.大家的流处理计算主要是还是依赖于Storm,Spark Stre ...

  5. Kafka Connect简介

    Kafka Connect简介 http://colobu.com/2016/02/24/kafka-connect/#more Kafka 0.9+增加了一个新的特性Kafka Connect,可以 ...

  6. Kafka基本原理

    简介 Apache Kafka是分布式发布-订阅消息系统.它最初由LinkedIn公司开发,之后成为Apache项目的一部分.Kafka是一种快速.可扩展的.设计内在就是分布式的,分区的和可复制的提交 ...

  7. Kafka学习之路 (一)Kafka的简介

    一.简介 1.1 概述 Kafka是最初由Linkedin公司开发,是一个分布式.分区的.多副本的.多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/ng ...

  8. Kafka(一)Kafka的简介与架构

    一.简介 1.1 概述 Kafka是最初由Linkedin公司开发,是一个分布式.分区的.多副本的.多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/ng ...

  9. Kafka学习笔记(1)----Kafka的简介和Linux下单机安装

    1. Kafka简介 Kafka is a distributed,partitioned,replicated commit logservice.它提供了类似于JMS的特性,但是在设计实现上完全不 ...

随机推荐

  1. 从linux和ucos的比较中来看进程这个概念

    这种问题就要和ucos结合起来嘛. 程序和进程: 程序:存放在磁盘上的一些列代码和数据的可执行映像,是一个静止的实体. 进程:是一个执行中的程序,它是动态的实体. linux进程的四要素: 1. 有一 ...

  2. 4.NIO的非阻塞式网络通信

    /*阻塞 和 非阻塞 是对于 网络通信而言的*/ /*原先IO通信在进行一些读写操作 或者 等待 客户机连接 这种,是阻塞的,必须要等到有数据被处理,当前线程才被释放*/ /*NIO 通信 是将这个阻 ...

  3. 自适应高度文本框 react contenteditable

    import React, { Component } from 'react'; import PropTypes from 'prop-types'; const reduceTargetKeys ...

  4. Flutter——CircleAvatar组件(圆形头像组件)

    import 'package:flutter/material.dart'; import 'res/listData.dart'; void main() { runApp(MaterialApp ...

  5. 02 WIndows编程——危险的sizeof

    C语言中,对 sizeof() 的处理都是在编译阶段进行. 下面代码,注意可变参数是怎么使用的 #include<Windows.h> #include<stdio.h> in ...

  6. Octave(控制语句)

    for循环遍历 >> v = zeros(,) v = >> v() ans = >> :, v(i) = ^i; end; >> v v = 或者: ...

  7. css实现背景全透明样式

    background-color:transparent; filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#26FFF ...

  8. libcurl 上传文件,不管文件什么格式 libcurl开发指南

    libcurl 上传文件,不管文件什么格式 libcurl开发指南 上传文件 https://curl.haxx.se/download.html curl命令参数很多,这里只列出我曾经用过.特别是在 ...

  9. 大数据之路week05--day01(I/O流阶段一 之File)

    众所周知,我们电脑中有许许多多的文件夹和文件,文件的形式也有许多不同的格式,文件夹中也可以新建文件夹的存在,也就是多层的一步一步的嵌套. 我们想要实现I/O操作,就必须知道硬盘上文件的表现形式. 而J ...

  10. spring-mybatis+spring整合

    整合之前回忆一下spring和mybatis分别做了什么: spring 通过注解/xml配置,实现AOP和DI DI: 接口实现类中, 将接口私有化,从容器中读取,而不是new一个 UserDao ...