大数据Kafka大话难点

大数据组件—Kafka

Kafka在大数据环境中是非常重要的，了解其工作原理也是大有必要的

• Kafka的文件存储机制

Kafka是一款高速响应，高吞吐，的分布式发布订阅消息系统，我们心抱着一个疑问来看Kafka的存储机制，这个疑问就是Kafka是高速响应的，但是它同时又会将我们的数据持久化，按平常的来讲，做了持久化一般就会很慢？带着这个问题我们来看

Kafka的存储是以topic为单位的，消费者和生产者面向的都是topic，其实topic是逻辑意义上的分区，物理上的分区其实是partition，topic在物理上都是一个一个的partition组成的，一个partition关历多个log文件，这些log文件就是生产的数据，生产的数据会不断的添加到log文件的末端，且每条数据都会有自己的offset，

我画了一张Kafka文件的基本图，以便更直观的了解其存储机制

      图上可以log文件下的是多个的（.log文件与.index文件）

现在我们在来看上面我给出的问题，为什么持久化的数据可以快速的响应？

Kafka是建立了数据索引的（文件.index就是索引文件）当要寻找消息时，Kafka先会找到想应的.index文件，在.index文件中得到数据在.log文件中的偏移量，从而很快的读取到数据

并且kafka还采用了零拷贝的技术

 

二.Kafka的高可靠保证

1.ACK验证机制

当生产者向partition发送数据时，partition的leader会给发送数据的生产者发送一个ack，当生产者得到这个ack，即证明该数据生产成功（当然这过程是异步的）

Kafka为我们的ack提供了多个级别的设置，我们一一观之

1. ack=0即生产者只管发送数据，partition的leader不会发送ack（数据是容易丢失的，生产环境不能使用）
2. ack=1即生产者发送数据，当partition的leader完成对数据的操作以后就可以发送给生产者表示数据生产成功，反之生产者将会认为此数据没有成功，进行补发（此级别基本不会丢失数据，但是当leader挂了，follower没有同步数据成功的话就会造成数据的丢失）
3. ack=-1即生产者发送数据，当partition的leader与ISR队列（文章等下会详细介绍）中的follower都完成对数据的操作即leader发送ack，表示数据生产成功（该种数据很安全，但是速度会有些下降，生产中重要数据推荐使用）

附：ISR队列：ISR队是当partition的leader的挂了以后，将从ISR的队列中的follower选举产生新的leader，ISR队列是怎么产生的，是由从follow中选举出来的优质follower，其选举的标准在老版本中是有俩个的一是follower完成拉取数据的完成的时间，还有一个就是拉取数据的完整性（就是拉取的数据条数越多完整度越高），但是在新的版本中取消了后者的选举标准，因为后者将会使ISR队列频繁的变动，消耗较大的资源

2.数据一致性

我们先来了解几个概念

LEO：leader end offset

HW（高水位）ISR中均有的offset

图解：

消费者只会读到HW之前的数据，当leader挂了以后其余的follower都会只有HW之前的数据多消少布，这样就保证了数据的一致，不重复

• Kafka生产者

Kafka生产数据的是自己拉取的，不是push来的，这样就适配了服务器，服务器根据自己当前的性能生产数据，不会造成数据的堆积产生网络拥堵，这也是Kafka为消息—订阅模式，而不是点对点的消息队列模式的原因

• 分区分配策略

首先一定要知道Kafka的一个分区时不可以同时被两个消费者消费的，只能是多个消费者或多个消费者组消费一个主题

Kafka有两种分区分配策略，一种是Round Robin（轮循）还有一种是Range(范围)

------------------------------------轮循策略-------------------------------

轮循就是这个消费者组订阅的所有的主题视为一个整体，将这些主题的各个分区经过算法打散然后给这这个消费者组一个一个的分配，这样分配的好处就是，这个消费者组中的各个消费者分配的分区数不会相差很多，但是这里有一个致命的点看图

如图中所示，那么TopicA的分区将分配给B消费者，而TopicB的分区将分配给A消费者，但是他们都为有订阅关系

那么该种分配策略使用就有有一个前提条件，那就是消费组中消费者所订阅的主题是一样的

 

--------------------------------范围策略-----------------------------------

首先此种策略划分分配的范围将不再是单纯的规定死的消费者组，而是将订阅同一个消费者划为为一个分配的范围

       根据这个范围中有多个消费者，将这个主题的分区均匀的分配给各个消费者

       如图：

Offset维护

Offset提交机制（消费者端）

一种为自动提交机制，但是开发人员无法得到准确的提交间隔时间，这是很危险的，一旦offset时间不准确就可能造成offset提交错过，从而导致数据的重复消费或者数据丢失，当逻辑处理完，offset还没提交时，机器故障，即重复消费，当逻辑还没处理完，offset已经提交，机器故障，即数据丢失，

一种为手动提交机制，分为异步提交，和同步提交，异步提交，先来讲讲同步提交，同步提交就是当offset没有提交成功就会阻塞线程一直等offset提交成功以后才会再去拉取数据进行消费，

异步提交，即主线程继续去拉取数据进行消费，offset也去提交，不会阻塞线程

但是无论是主动提交，还是手动提交的异步，或则同步，都会有数据丢失或者重复消费的问题存在，再这里Kafka为我们提供了自定义的offset提交接口，我们应该根据业务与offset提交形成事务才能保证数据的稳定

Offset的维护顺序为 消费者组-主题-分区