Kafka-01 kafka的概述

     Apache Kafka 是 Apache 软件基金会的开源的流处理平台，该平台提供了消息的订阅与发布的消息队列，一般用作系统间解耦、异步通信、消峰填谷等作用。同时Kafka又提供了Kafka streaming插件包实现了实时在线流处理。相比较一些专业的流处理框架不同，Kafka streaming计算是运行在应用端，具有简单、入门要求低、部署方便等优点。

主要功能：

1.消息队列message queue。

2.Kafka stream 流处理。

Kafka集群

Kafka生产上一般都是以集群来运行的，集群以Topic形式负责分类集群中的Record，每一个Record属于同一个topic。每个topic底层都会对应一组分区的日志用于持久化topic中的record。同时在kafka集群中，topic中的每一个日志的分区都一定会有一个broker担当该分区的leader，其他的broker担当该分区的follower，leader负责分区的读写操作，follower负责同步该分区的数据。这样如果该分区的leader宕机，该分区的其他follower回选出新的leader继续负责该分区数据的读写。其中集群中的leader的监控和topic的部分元数据是存储在Zookeeper中。

Kafka中所有消息是通过Topic为单位进行管理，每个Kafka中的Topic通常会有多个订阅者，负责订阅发送到该Topic中的数据。Kafka负责管理集群中每个Topic的一组日志分区数据。

生产者将数据发布到相应的Topic。负责选择将哪个记录发送到Topic中的哪个分区。例如可以以round-robin方式完成此操作，然而这种仅是为了平衡负载。也可以根据某些语义分区功能（例如基于记录中的key）进行此操作。

每组日志分区是一个有序的不可变的日志序列，分区中的每一个Record都被分配了唯一序列编号称为是offset，Kafka集群会持久化所有发布到Topic中的Record信息，该Record的持久化时间是通过配置文件指定，默认是168小时。

log.retentioon.hours=168

Kafka底层会定期的检查日志文件，然后将过期的数据从log中移除，由于kafka使用硬盘存储日志文件，因此使用Kafka长期环村一些日志文件是不存在问题的。

Kafka在Topic内部要为什么要采用分区？

1. 分区多能存储海量的数据。

2. 分区多能够提升队列写入的并发量。

在消费者消费Topic中数据的时候，每个消费者会维护本次消费对应分区的偏移量，消费者会在消费完一个批次的数据之后，会将本次消费的偏移量提交给Kafka集群，因此对于每个消费者而言可以随意的控制改消费者的偏移量。因此在Kafka中，消费者可以从一个topic分区中的任意位置读取队列数据，由于每个消费者控制了自己的消费的偏移量，因此多个消费者之间彼此相互独立。每个分区的数据被消费者消费后，消费者会记录数据在分区中的偏移量offset，分区并不会删除被消费的数据，所以这个分区有多个消费者时，消费者消费数据是相互独立，互不影响的。

Kafka中对Topic实现日志分区的有以下目的：

- 首先，它们允许日志扩展到超出单个服务器所能容纳的大小。每个单独的分区都必须适合托管它的服务器，但是一个Topic可能有很多分区，因此它可以处理任意数量的数据。

- 其次每个服务器充当其某些分区的Leader，也可能充当其他分区的Follwer，因此群集中的负载得到了很好的平衡。

Kafka中分区-消费组-消费者实例之间的关系

kafka集群是由多个broker组成，每个broker上能管理多个分区，每个分区都有归属的topic，我们可以认为每个分区是一个队列，每个分区的数据能广播给多个订阅的消费组，但是每个数据只能被每一个订阅消费组的其中一个消费者实例消费。

消费者使用Consumer Group名称标记自己，并且发布到Topic的每条记录都会传递到每个订阅Consumer Group中的一个消费者实例。如果所有Consumer实例都具有相同的Consumer Group，那么Topic中的记录会在该ConsumerGroup中的Consumer实例进行均分消费；如果所有Consumer实例具有不同的ConsumerGroup，则每条记录将广播到所有Consumer Group进程。

更常见的是，我们发现Topic具有少量的Consumer Group，每个Consumer Group可以理解为一个“逻辑的订阅者”。每个Consumer Group均由许多Consumer实例组成，以实现可伸缩性和容错能力。这无非就是发布-订阅模型，其中订阅者是消费者的集群而不是单个进程。这种消费方式Kafka会将Topic按照分区的方式均分给一个Consumer Group下的实例，如果ConsumerGroup下有新的成员介入，则新介入的Consumer实例会去接管ConsumerGroup内其他消费者负责的某些分区，同样如果一下ConsumerGroup下的有其他Consumer实例宕机，则由该ConsumerGroup其他实例接管。

由于Kafka的Topic的分区策略，因此Kafka仅提供分区中记录的有序性，也就意味着相同Topic的不同分区记录之间无顺序。因为针对于绝大多数的大数据应用和使用场景， 使用分区内部有序或者使用key进行分区策略已经足够满足绝大多数应用场景。但是，如果您需要记录全局有序，则可以通过只有一个分区Topic来实现，尽管这将意味着每个ConsumerGroup只有一个Consumer进程。

Kafka的高性能之道

Kafka的特性之一就是高吞吐率，但是Kafka的消息是保存或缓存在磁盘上的，一般认为在磁盘上读写数据是会降低性能的，但是Kafka即使是普通的服务器，Kafka也可以轻松支持每秒百万级的写入请求，超过了大部分的消息中间件，这种特性也使得Kafka在日志处理等海量数据场景广泛应用。Kafka会把收到的消息都写入到硬盘中，防止丢失数据。为了优化写入速度Kafka采用了两个技术顺序写入和MMFile 。

因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最讨厌随机I/O，最喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。这样省去了大量的内存开销以及节省了IO寻址的时间。但是单纯的使用顺序写入，Kafka的写入性能也不可能和内存进行对比，因此Kafka的数据并不是实时的写入硬盘中 。

Kafka充分利用了现代操作系统分页存储来利用内存提高I/O效率。Memory Mapped Files(后面简称mmap)也称为内存映射文件，在64位操作系统中一般可以表示20G的数据文件，它的工作原理是直接利用操作系统的Page实现文件到物理内存的直接映射。完成MMP映射后，用户对内存的所有操作会被操作系统自动的刷新到磁盘上，极大地降低了IO使用率。