目录
[一, kafka的概述](#一, kafka的概述)
[二, 应用场景:](#二, 应用场景:)
[2.1 高性能](#2.1 高性能)
[2.2 高扩展性](#2.2 高扩展性)
[2.3 高可用](#2.3 高可用)
[2.4 持久化和过期策略](#2.4 持久化和过期策略)
[2.5 ZooKeeper](#2.5 ZooKeeper)
[三, Kafka是什么?](#三, Kafka是什么?)
[四, python中使用Kafka](#四, python中使用Kafka)
一,kafka的概述
Kafka传统定义： Kafka是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。
**发布/订阅：**消息的发布者不会将消息直接发布给特定的订阅者，而是将发布的消息分为不同的类别，订阅者只接收感兴趣的消息。
**Kafka最新定义：**Kafka是一个开源的分布式事件流平台（Event Streaming Platform），被数千家公司用于高性能的数据管道、流分析、数据集成和关键任务应用。
二, 应用场景:
比如我们程序员维护两个服务,一个服务A生产消息,另一个服务B消费消息,A服务每秒发送200个消息,B服务每秒只能处理100个消息,B服务哪里顶得住,分分钟就被压垮...,那么问题来了,怎么在B不被压垮的时候还能处理掉A的消息,那就是在A和B中间加一个中间层,我们的kafka消息队列就闪亮登场了。
什么是消息队列?如下图消息队列的好处就是AB服务互不影响,我们重启A或者B服务,并不会有任何影响
但这个消息队列实在太简陋,像高可用,高性能,高扩展性一个不沾边,来看看我们怎么优化
2.1 高性能
我们可以扩展更多的消费者,这样消费速度就上去了,相对的我们可以增加生产者,提升消息队列的吞吐量。
随着生产者和消费者同时增多,他们会争抢同一个消息队列,抢不到的一方就要等待,这不就是纯纯的浪费时间么?
有没有对这种浪费时间有解决方案?当然有的,我们对消息队列进行分类Topic,然后根据topic新增队列,生产者将不同的数据按照topic投递到队列中,消费者则根据需要订阅不同的topic,这样就大大降低了topic队列的压力
但是单个的topic的消息可能还是很多,我们可以将单个的topic队列拆成好几段,每段都是一个Partition分区,每个消费者负责一个Partition分区,这样就提升了消息队列的性能
2.2 高扩展性
随着Partition变多,所有Partition都在同一个机器上,就会导致单机CPU和内存过高,影响整体系统性能,于是我们可以申请更多的机器,将Partition分散部署在多台机器上,每一台机器就代表一个broker,我们可以通过增加broker,缓解机器CPU过高带来的性能问题
2.3 高可用
如果一个broker挂掉了,那broker里面的所有Partition消息都没有了,高可用还从何谈起?有解决方案么?
我们可以给Partition多增加几个副本,他们统称为replicas,将他们分为Leader和Follower
Leader负责生产者和消费者的读写请求,而follower只管同步leader的消息,将leader和follower分散道不同的brocker,这样leader所在的broker挂了,也不会影响到follower所在的broker,并且还能从follower中选举出一个新的leader的partition顶上这样就保证了消息队列的高可用
2.4 持久化和过期策略
上面2.3的场景中是挂掉了其中的一部分broker,那如果所有的broker全部都挂掉了,那数据不就是全部丢了?为了解决这个问题,我们不能光把数据放在内存里,还要持久化到内存中,这样哪怕全部的broker都挂了,数据也不会丢失,重启服务后也会在磁盘里读取数据继续工作
但问题又来了,磁盘总是有限的,这一直往里写数据,迟早有一天会爆炸,所以我们还可以给数据加上保留策略,也就是retention policy,比如磁盘数据超过一定大小或者消息放置超过一定时间就会被清理掉
2.5 ZooKeeper
相信我们也发现了,组件太多了,而且每个组件都有自己的数据和状态,所以我们还需要统一维护这些组件的状态信息,于是我们引入了ZooKeeper组件,它会定期和broker通信,获取整个kafka集群的状态,以此来判断某些broker是不是跪了,某些消费组消费到哪里了
三, Kafka是什么?
介绍到这里,我们就来说下kafka是什么?
当初这个简陋的消息队列
,通过上述的组件,就成为了一个高性能,高可用,高扩展性,支持持久化的超强消息队列,这就是我们常说的消息队列kafka
