第一章 KafKa简介  1.1 Kafka概述 Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。  1.2 Kafka产生背景 当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工厂一样不断的生产出各种信息，在大数据时代，我们面临如下几个挑战： 如何收集这些巨大的信息 如何分析它 如何及时做到如上两点 以上几个挑战形成了一个业务需求模型，即生产者生产（produce）各种信息，消费者消费（consume）（处理分析）这些信息，而在生产者与消费者之间，需要一个沟通两者的桥梁-消息系统。从一个微观层面来说，这种需求也可理解为不同的系统之间如何传递消息。 Kafka是一个消息系统，原本开发自LinkedIn，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。现在它已被多家不同类型的公司 作为多种类型的数据管道和消息系统使用。 　　活动流数据是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。活动数据包括页面访问量（Page View）、被查看内容方面的信息以及搜索情况等内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。运营数据指的是服务器的性能数据（CPU、IO使用率、请求时间、服务日志等等数据)。运营数据的统计方法种类繁多。 　　近年来，活动和运营数据处理已经成为了网站软件产品特性中一个至关重要的组成部分，这就需要一套稍微更加复杂的基础设施对其提供支持。   1.3 Kafka的特性 分区 分区(partition)是卡夫卡保证高吞吐的基本保证，一个topic通常会有多个partition，可以分别部署在一台或多台主机上。 每个partition只能对应一个consumer，而一个consumer可以对应多个partition（多出的consumer会闲置）。 每个partition可以有多个replicas，且必须部署在不同的主机上（部署在同一主机上是没有意义的）。 副本 replicas只负责备份数据，并不能用于读写 replicas通过poll的方式从partition获取数据。 为什么要使用poll而不是用push？因为拉可以减少leader的消耗，并且可以批量获取数据。 当partition失效时，某个replica晋升为leader才能继续提供读写。 日志形式消息文件存储 kafka的日志文件形式是其区别于其他MQ的最关键因素，也是其保证吞吐量的核心。 分段日志 kafka的日志文件是分段的，每个分段文件包含一个索引文件(index)，一个日志文件(log)，一个时间戳索引文件(timestamp)；以该段的第一条消息的偏移量(offset)作为文件名存储消息日志，文件名长度为20位，不足的补0。 日志文件是怎么分割的？ （1）按照配置的日志文件大小分割，默认1G； （2）按照日志对应的索引文件大小分割，默认索引文件大小10mb； （3）按时间分割，默认分割时间7天，即7天后会写入新文件； （4）按消息数量分割，当消息数量超过Integer.MAX_VALUE后会写入新文件。 索引文件 每个索引条目占8个字节，前4字节表示消息偏移量，后4字节表示物理位置（这也可以解释为什么上面写的消息数量不能超过Integer.MAX_VALUE） 注意，不是每条消息都会在索引里，而是每隔一定量的字节后写一条索引(log.index.interval.bytes)。 读日志 索引的每个条目包含了一条消息的序号(offset)和消息在文件中位置(position)。 注意，不是每条消息都会在索引里，而是每隔一段字节保存(这个字节数不是很清楚)。 如何读取offset=7的消息？ 首先根据偏移量就能找到对应的日志文件 根据日志索引再使用二分查找法找到之前最近的一条日志索引offset=6 再根据offset=6的position找到文件中位置，再遍历到offset=7的消息 生产者策略 批量拉取数据，以java client为例： producer会先将消息存储在一个队列里，然后由Sender轮询去批量拉取。  1.4 Kafka应用场景 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。 消息系统：解耦和生产者和消费者、缓存消息等。 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。 流式处理：比如spark streaming和storm。 1.5为何使用消息系统 解耦 　　在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 冗余 　　有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 扩展性 　　因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。 灵活性 & 峰值处理能力 　　在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 可恢复性 　　系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 顺序保证 　　在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。 缓冲 　　在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。 异步通信 　　很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。