Kafka笔记 (二) Kafka一些基础的概念与设计

1. 事件、生产者和消费者

事件(Event)、生产者(Producer)和消费者(Consumer)是Kafka最基础的三个元素，Event就是要传递的数据，不同语境下也可以说成是记录或者消息；生产者就是产生事件的应用，而消费者就是接收并处理事件的应用。生产者到事件到消费者的模式，就是发布\订阅模型的一个实现，不过和常见的发布\订阅系统相比较，Kafka最大的特点在于消息(事件)并非是生产者推送(Push)给消费者的，而是消费者自己根据需要进行拉取(Pull)的，事件将生产者和消费者完全解耦

事件的内容

目前一个Kafka事件的内容由三部分构成：

• Data. 就是实际要传递的数据，它是一个key-value结构，消息的key可以自由指定，而value存储实际的数据
  
• Header. 这是Apache Kafka 0.11标准之后加入的内容，其实就是可以自定义的键值对，用来扩展事件记录的元数据，例如生产者的id，方便下游应用进行路由等操作。Header一般用的不多。
• Metadata. 是Kafka自动给事件生成的元数据，其中最关键的信息就是时间戳Timestamp
  
  对于Kafka事件的内容组成，你可能会比较困惑为什么把要把Data设计出key-value，这里的key有什么作用。其实key最主要的作用是用于分区Partition，下面的小节会详细描述；在大部分简单的kafka应用里，可以把key置空

典型的消费过程

可以用下面的示意图来大致描述默认情况下事件如何被消费者消费。在那之前先得了解几个概念：

• 事件在Kafka里的储存方式可以就看成是日志文件，也就是说每个事件就是日志文件里的一条记录；
• Topic是事件的组织单位，每条事件归属于某个Topic，可以把一个Topic看成是一个日志文件
• 因为事件相当于日志文件里的记录，而每条记录在文件里都有一个偏移量offset，所以这个offset也就是这个事件的索引，要读取某个事件，就是根据它的offset直接从文件中读取数据

现在我们来看下事件的消费过程，以及过程中存在的一些情况:

首先生产者Producer向指定的Topic生产数据，正如上面所说的，存储事件的数据，就是在日志文件上添加记录，事件依次追加到日志文件末尾，每条事件有一个递增的偏移量

对于消费者Consumer，它读取数据同样按照偏移量依次从订阅的Topic中读取数据

因为消费者是主动去获取数据的，为了追溯它读取数据的位置，消费者需要定期对这个Topic进行提交Commit操作，其实就是记录当前读取到的事件的偏移量；下面的图里，在消费到记录4的时候，进行了Commit操作；消费者默认的Commit行为是周期性Commit，所以它下一次Commit，应该发生在读取记录9的时候（当然也可以手动Commit，不过不太推荐，因为太频繁的手动Commit也比较影响性能）

现在我们假设消费者程序在读取到记录7的时候崩溃停止了，而生产者则继续在生产数据

当生产者生产到记录10的时候，消费者程序恢复了运行
恢复运行的消费者程序会查询到之前的Commit记录，知道最近的偏移量是4，所以将从记录4开始恢复读取数据

但是消费程序奔溃前其实是消费到记录6的，而重启后从记录5开始恢复读取数据，这也就意味着将存在重复读取的数据，既图中标红的5和6

存在这种情况并非是Kafka的设计缺陷，而是体现它的设计思想，即数据的使用权在消费者自身，消费者需要自己按照合适的应用场景来决定如何消费数据：

• 如果这是一个工业数据采集的场景，事件里的数据是传感器的采样数据，而消费者程序的目的就是记录所有的采样数据，那么为了保证数据的完整性，它就只能按照上面的示意图的消费方式进行，来避免有数据遗失，而重复数据的问题则需要它自己处理
• 如果这是一个实时数据在线显示的场景，消费者程序的目的只是为了在网页端实时显示最新的数据，它对数据完整性没有要求，那么它可以不采用上面这种默认的消费模式；事实上，默认的消费模式叫做earliest模式，如果改成latest模式，那么消费程序则只会读取最新的消息，忽略中间可能漏掉的数据

还有个问题是消费者的Commit记录在哪里，记录消费者最近的事件偏移量不会存在于消费端，而是由Kafka集群来记录。事实上，在Kafka中有个特殊的Topic叫