kafka初学

kafka官方文档中文版：http://kafka.apachecn.org/documentation.html

kafka是一个分布式消息系统，使用scala语言编写。被用作构建实时数据管道及数据流的应用，它可以横向扩展（横向扩展：比较典型的就是分布式，多台机器通过网络串联起来对外提供服务，每台机器都有自己的能力，组合起来提高综合能力。优点是成本低。缺点是不好维护。纵向扩展：在一台机器上，不断加配置，即在单个节点上（服务器）不断增加网络传输能力或计算能力、存储能力等。优点是就一台机器，好维护。缺点是成本太高。一般公司承担不了。）、容错（大数据平台的几乎所有框架都容错）。它以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布处理系统如Cloudera、Apache Storm、Spark都支持与kafka的集成。

数据分析中处理的一般是批量数据和流数据，分别对应批量处理和流处理。

批量数据：定期产生；数据量相对较大；有特定的生成周期。

数据来源：定期产生的文件（日志）；定期传输的文件（从别的地方传过来的大数据）；定期数据库导出（会产生一个导出文件）

数据流向：分布式存储系统。

如：1.日志文件数据。是已经生成好的，不再继续往里写数据。达到某个时间点或达到某个体量才会滚动，继续生成新的文件，此时被滚动的文件不再继续写数据，那么就可以被采集。从业务角度上来说，仍在被写数据的文件是不能被采集的因为每时每刻的数据都在更新。

2.业务数据。比如说按天统计日报表，当天九点去统计当天的日志报表这是不可以的，我们必须到当天结束时才可以得出当天的日志报表。

流数据：随时都可能产生；搜集流数据的工具7*24小时运行（必须时刻不能停机）；数据量相对比较小；实时性强。在kafka的流处理中，SQL语句是事先已经写好的，这样，只要有新数据来了，就会立刻进行运算，这样提前写好SQL的弊端就是只能满足一个application的业务逻辑，如果你想处理其他的逻辑，即使是有一点差异，也需要重新建立。流处理的优势就是一边进数据，一边出数据，实时处理。

数据来源：一般都是网络端口；少数来自文件（比如说有一个监听文件的程序，需要时刻监听该文件，监听到文件中的内容发生变化，就可以将变化的内容发送到网络端口，发送到网络端口，那么流采集工具就能接收到。由于文件更新是随时的，那么流数据采集工具就必须得无停机工作）。

数据流向：1.分布式文件系统。2.发送到流计算应用程序。如spark streaming.

如：统计广告的点击量。随时查看的都是当前的数据。用户点了广告，那么搜集工具就得进行收集，而我们无法预测用户何时点击，所以搜集数据的工具必须不间断工作。

以上分析可以看出，流数据的数据来源渠道较多，而批量数据的数据来源几乎都是来自于定期的文件。

kafka的特点：

kafka是一种分布式的，基于发布/订阅的消息系统。（其实所有的消息系统都是基于发布/订阅的，Redis也是基于此）主要设计目标如下：

1.以时间复杂度为O(1)的方式提供消息持久化能力（时间复杂度为O（1）简单来说就是以比较简单的方式提供数据的写入，按照磁盘存储的顺序写，就是说文件创立之后，按照顺序依次写入，只需记住当前已写的位置，下次写数据时只需要知道上次写数据的位置继续往后写即可。所有按顺序写数据的时间复杂度都为O(1)。时间复杂度为O（n）：按照特定的顺序写数据，比如说文件中已存储了内容为1,2,3,4,5,7这些内容的数据，现在存储6，要想让他们按照内容的顺序存储，也就是说让6存储在5和7之间，那么就需要将6和所有数据依次遍历比较才能找到位置，这样的时间复杂度就是O（n）。  持久化就是把数据保存下来，也就是把数据写入存储系统，存储系统可以是数据库也可以是文件系统，此处kafka的写入实际上是写入文件系统。），即使对TB级以上数据也能保证常数时间复杂度的访问性能。读写速度非常快。

2.高吞吐率（接收数据的能力）。即使在非常廉价的商用机器上也能做到单机支持每秒100k条以上消息的传输。

3.支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。

这里的消息分区其实就是一种分布式存储。

4.同时支持离线数据处理和实时数据处理。主要用于实时数据处理。

5.Scale out:支持水平扩展。

kafka架构：

在kafka中，使用zookeeper保存broker、主题、分区等元数据信息。通过zookeeper管理broker与consumer的动态加入与离开。

kafka集群接收到producer发过来的消息后，将其持久化到硬盘，并保留消息指定时长，而不关注消息是否被消费。

数据磁盘持久化：消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写功能。

Broker:kafka集群包含一个或多个服务器（节点），一个一个的节点就是broker。专门提供消息的读和写，并且可以保存消息。

Topic:每条发布到kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上，但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）。因为不同的消息有不同的内容，具有不同的数据结构，所以不同的消息类型应该放在不同的broker中。（比如订单行为和网页操作行为，这两种消息进入到kafka中，应该由Topic来划分这两种消息应该进入到哪个Topic中。可以把数据库理解为broker，那么表就是Topic对数据进行分类）。作为分布式系统，就有多个broker。同一个topic可以在多个broker中，每一个topic中可以有多个partition。producer和consumer可以同时从多个topic读写数据。

Partition：是物理上的概念，每个Topic包含一个或多个partition。遇到瓶颈时，可以通过增加partition的数量来进行横向扩容。单个partition内是保证消息有序，因为消息是按照时间顺序不断append的。逻辑相关的消息应该放在同一个partition中，比如做count++，不同的消费者在处理时都是相互独立的，如果count有一条消息分配到了其他的partition中，那么就会产生错误信息。所以在这种情况下我们可以在producer端指定partition。如果没有指定partition，那么分区器会根据该条消息的key生成hash值分配到指定的partition，同一个partition中的消息具有相同的key。在partition中消息是顺序写入和读入的，这样就可以提高读写效率。partition中的消息被消费后，不是立即删除的，而是根据配置的参数来删除的。有两种方式可以指定消息删除机制：1.设置删除时间，达到多长时间之后就会被删除。2.设置字节数，文件达到某个字节数时，就会删除。这两个机制只要满足了其中一个，就会执行删除。每个主题的每个分区都有一个主副本和0个或多个备份副本（副本称为replicas，副本数量可以通过参数进行配置）。这些副本放在不同的broker中可以容错，所以在有n个副本（指的就是主副本加备份副本）的时候，允许有n-1个副本挂掉。通常，分区的数量要大于broker的数量，这样每个broker就既是某个partition的主副本，也是另外一些分区的备份副本。主副本所在的broker就是这个partition的leader，负责该partition的消息读写，由此可见，有多少个partition，就有多少个leader。备份副本所在的broker就是follower，follower就是保持和leader的消息同步，如果follower的消息与leader之间同步差距太大，就会从ISR（In Sync Replicas）中被移除掉。为了保持均衡，leader会被均衡地分布在不同的broker上。如果leader挂掉了，那么就会由follower一起去zookeeper中注册，谁注册成功了，就会成为新的leader。

Producer：发送消息者。每个partition可以当做是一个日志文件，消息不断地向该文件末尾append。分区中的每条消息都会按照时间顺序分配到一个单调递增的顺序编号，叫做偏移量（offset），offset是一个long的整数，相当于Id,可以唯一标识一条消息。消费者在读取消息时，读取到哪一条消息都会在消费者端自己保存offset的信息，也就是自己记着自己读到哪儿了。

Consumer：消费者。同一个application的consumer放在同一个consumer group中，如果consumer数量不能满足消费速度时，可以在该consumer group中新增consumer，这样横向扩展。消费者订阅了某个Topic后，就可以消费该Topic的消息。但是，同一个consumer group中只能有一个消费者来消费某一个partition中的消息。不能在同一个consumer group中有多个consumer来消费同一个partition中的消息。如果要想有多个consumer来消费同一个partition中的消息，那么consumer就要放在不同的consumer group中。同一个consumer group中可以有同一个consumer消费多个partition，但是不能有一个partition被多个consumer消费的情况。所以，在同一个consumer group中，consumer的数量不能大于partition的数量，否则就会存在某个consumer没有对应的partition可供消费。

消息确认机制：

生产者通过指定acks来确定在什么情况下才会确认消息是发送成功的。

acks的三个取值：

all/-1:所有ISR中的副本全部收到消息时，服务器才会向producer发出成功的响应。这样可以保证同步的副本中的所有副本都接收到了消息，所以在这种情况下，即使宕机了也没有关系。但是这样就是有了较高的延迟，因为要等所有副本同步消息。

0：producer只管发送消息，不管是否发送成功，这样就会导致如果数据发送失败了，那么producer也是无从得知的，也没法重新发送消息。造成数据丢失的风险。但是这种情况就会有较高的吞吐率。

1：只要leader收到消息就会响应成功，如果leader没有收到消息，那么服务器就会给producer一个错误的响应，然后producer进行重发。这种机制可能会导致在leader挂掉的时候，新的leader选举出来后没有收到消息，就会导致数据丢失。

消息传送机制：

at most once：最多一次，消息只发送一次，无论是否成功。先保存offset，再处理消息。如果保存了offset之后，消息处理过程中出现异常，那么消息就算是丢失了。

at least once：最少一次，先处理消息，再保存offset。如果处理完消息，在保存offset时出现异常，那么该条消息会被重复消费，因为offset保存的是这次消费之前的值，所以就要重新读一遍。在业务中常用这种机制，因为重复读取消息比丢失数据更能接受。

exactly once：仅一次。