背景

          Kafka是分布式发布-订阅消息系统，它最初是由LinkedIn公司开发的，之后成为Apache项目的一部分，Kafka是一个分布式，可划分的，冗余备份的持久性的日志服务，它主要用于处理活跃的流式数据

作用

       kafka的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存

架构

  如图所示:

角色描述

        Topic:指kafka处理消息源的不同分类，或称为一个主题，可以理解为MQ(消息队列)的一个名字

        Broker:缓存代理，kafka集群中的一台或多台服务器统称为broker,一个broker可以容纳多个topic

        Producer:消息的生产者,就是向kafka broker发消息的客户端(push)

       Consumer:消息消费者，就是向kafak broker取消息的客户端(通过pull进行取)

       Message:消息，是通信的基本单位，每个producer可以向topic(主题)发布一些消息

      Offset(起始偏移量):kafka的存储文件都是按照offset.kafka来命名,用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka

      Partition:Topic物理上的分组，为了实现扩展性，一个非常大的topic可以分布到多个broker(服务器)上，一个topic可以分为多个partition,每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的Id(offset).kafka只保证一个partition中的顺序将消息发送给consumer，不保证一个topic的整体(多个partition间)的顺序，也就是说，一个topic在集群中可以有多个partition,那么分区的策略是什么？(消息发送到哪个分区上，有两种策略，一是采用Key Hash算法，二是采用Round Robin算法)(两种算法请自行Google)

消息发送流程

  如图所示：

     1.Producer根据指定的partition方法(round-robin,hash等)，将消息发布到指定的topic的partition里面

     2.Kafka集群接收到Producer发过来的消息后，将其持久化到硬盘，并保留消息指定时长(可配置)，而不关注消息是否被消费

     3.Consumer从Kafka集群pull数据，并控制获取消息的offset

消息系统

    消息系统分为两种:

                1.消息广播

                            广播是把消息发送给所有的consumer

                2.订阅-发布(消息单播)

                           订阅发布是把消息发送给订阅者

        kafka是通过Consumer Grouping(CG)来实现这两种机制：

                       一个topic可以有多个CG,topic的消息会复制(只是概念上的复制)到所有的CG,但每个CG只是把消息发送给该CG中的一个consumer(这是实现一个Topic上多Consumer的关键点)：为一个topic定义一个CG，一个CG有多个consumer，用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic

    如果要实现广播:只要每个consumer有一个独立 的CG即可

   如果要实现单播:只要所有的consumer在同一个CG中

   典型的应用情景:

       多个consumer来读取一个Topic(理想情况下是一个consumer读取Topic的一个partition),那么可以让这些Consumer属于同一个CG即可实现消息的多Consumer并行处理，原理是kafka将一个消息发布出去，CG中的Consumers可以通过Round Robin的方式进行消费(consumers之间的负载均衡由zookeeper来实现)

负载均衡

       Kafka将元数据存储在zookeeper中，但Topic本身的数据是不会发送到zookeeper中的

       Kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端(producer和consumer)的配置，broker会在zookeeper注册并保持相关的元数据(topic,partition信息等)更新

       客户端会在zookeeper上注册相关的watcher,一旦zookeeper发生变化，客户端能及时感知并作出相应的调整，这样就保证了添加或去除Broker时，各broker间仍能自动实现负载均衡，这里的客户端指的是Kafka的消息生产端和消息消费端

       Broker端使用zookeeper来注册broker信息，以及监测partition leader的存活性

       Consumer端使用zookeeper用来注册consumer信息，其中包括consumer消费的partition列表等，同时也用来发现broker列表，并和partition leader建立socket连接，并获取消息

       Zookeeper和Producer没有建立关系，只和Brokers,Consumers建立关系以实现负载均衡，即同一个Consumer Group中的Consumers可以实现负载均衡

     消费者分组的意义：

              组内的消费者可以共同处理一个topic的所有消息，而且不会产生冲突，这种协调是通过借助zookeeper来实现的，而且这个协调逻辑已经被封装在kafka提供的api中

设计要点

    1、直接使用linux 文件系统的cache，来高效缓存数据。

    2、采用linux Zero-Copy提高发送性能。传统的数据发送需要发送4次上下文切换，采用sendfile系统调用之后，数据直接在内核态交换，系统上下文切换减少为2次。根据测试结果，可以提高60%的数据发送性能。Zero-Copy详细的技术细节可以参考：https://www.ibm.com/developerworks/linux/library/j-zerocopy/

    3、数据在磁盘上存取代价为O(1)。kafka以topic来进行消息管理，每个topic包含多个part（ition），每个part对应一个逻辑log，有多个segment组成。每个segment中存储多条消息（见下图），消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。发布者发到某个topic的消息会被均匀的分布到多个part上（随机或根据用户指定的回调函数进行分布），broker收到发布消息往对应part的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。

    4、显式分布式，即所有的producer、broker和consumer都会有多个，均为分布式的。Producer和broker之间没有负载均衡机制。broker和consumer之间利用zookeeper进行负载均衡。所有broker和consumer都会在zookeeper中进行注册，且zookeeper会保存他们的一些元数据信息。如果某个broker和consumer发生了变化，所有其他的broker和consumer都会得到通知。

应用场景

    1.消息队列

            比起大多数的消息系统来说，Kafka有更好的吞吐量，内置的分区，冗余及容错性，这让Kafka成为了一个很好的大规模消息处理应用的解决方案。消息系统一般吞吐量相对较低，但是需要更小的端到端延时，并尝尝依赖于Kafka提供的强大的持久性保障。在这个领域，Kafka足以媲美传统消息系统，如ActiveMR或RabbitMQ

    2.行为跟踪

              Kafka的另一个应用场景是跟踪用户浏览页面、搜索及其他行为，以发布-订阅的模式实时记录到对应的topic里。那么这些结果被订阅者拿到后，就可以做进一步的实时处理，或实时监控，或放到hadoop/离线数据仓库里处理。

    3.元信息监控

            作为操作记录的监控模块来使用，即汇集记录一些操作信息，可以理解为运维性质的数据监控吧。

    4.日志收集

            日志收集方面，其实开源产品有很多，包括Scribe、Apache Flume。很多人使用Kafka代替日志聚合（log aggregation）。日志聚合一般来说是从服务器上收集日志文件，然后放到一个集中的位置（文件服务器或HDFS）进行处理。然而Kafka忽略掉文件的细节，将其更清晰地抽象成一个个日志或事件的消息流。这就让Kafka处理过程延迟更低，更容易支持多数据源和分布式数据处理。比起以日志为中心的系统比如Scribe或者Flume来说，Kafka提供同样高效的性能和因为复制导致的更高的耐用性保证，以及更低的端到端延迟。

    5.流处理

          这个场景可能比较多，也很好理解。保存收集流数据，以提供之后对接的Storm或其他流式计算框架进行处理。很多用户会将那些从原始topic来的数据进行阶段性处理，汇总，扩充或者以其他的方式转换到新的topic下再继续后面的处理。例如一个文章推荐的处理流程，可能是先从RSS数据源中抓取文章的内容，然后将其丢入一个叫做“文章”的topic中；后续操作可能是需要对这个内容进行清理，比如回复正常数据或者删除重复数据，最后再将内容匹配的结果返还给用户。这就在一个独立的topic之外，产生了一系列的实时数据处理的流程。Strom和Samza是非常著名的实现这种类型数据转换的框架。

    6.事件源

          事件源是一种应用程序设计的方式，该方式的状态转移被记录为按时间顺序排序的记录序列。Kafka可以存储大量的日志数据，这使得它成为一个对这种方式的应用来说绝佳的后台。比如动态汇总（News feed）。

    7.持久性日志（commit log）

          Kafka可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据回复提供一种重新同步的机制。Kafka中日志压缩功能为这种用法提供了条件。在这种用法中，Kafka类似于Apache BookKeeper项目。

特点

  1、同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。

2、可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。

3、分布式系统，易于向外扩展。所有的producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。

4、消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。

5、支持online和offline的场景

快速进入安装部署以及API使用:Kafka介绍之安装配置API