一. Kafka介绍

1. 概述

Kafka最先是由Linkedin公司开发，是一个分布式的、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当作MQ系统），常见可用于web/nginx日志、访问日志、消息服务等等。于2010年贡献给了Apache基金会并成为顶级开源项目。

• 主要应用场景：日志收集系统、消息系统
  • 设计目标
    • 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
    • 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
    • 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
    • 同时支持离线数据处理和实时数据处理。
    • Scale out:支持在线水平扩展

1.2 消息系统介绍

一个消息系统负责将数据从一个应用传递到另外一个应用，应用只需要关系数据，不需要关心数据之间是如何传递的。

分布式消息传递基于可靠的消息队列，在客户端和消息系统之间异步传递消息。

消息的传递模式：

• 点对点传递

• 发布-订阅模式（大部分消息系统选用此种方式）

1.3 Kafka的优点

• 解耦

• 我们在项目开始的时候预测将来可能出现的需求是十分困难的。但是消息系统不用关心其内部处理过程，只需要遵循其约定好的消息的接口。这就允许你方便的扩展或修改其两边的处理过程，只需要保证其双方均遵循同样的接口约束。

• 冗余（副本）

  • 有些情况下处理消息数据的过程或许会失败，除非消息数据被持久化了，否则就会丢失。消息队列通常会把消息数据持久化直到确保他们已经被完全处理之后，通过这一方式避免消息丢失的风险。许多消息队列采取“插入-获取-删除”的策略模式，把一个消息删除之前需要你的系统明确的指定改条消息已经被处理完毕，从而保证了你的数据被安全的保存到你使用完毕。

• 扩展性

  • 消息队列解耦了我们的处理过程，所以我们消息的入队和处理速率是很容易的，只需要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。

• 灵活性&峰值处理能力

  • 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

• 可恢复性

  • 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

• 顺序保证

  • 在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。

• 缓冲

  • 在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。

• 异步通信

  • 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

1.4 Kafka中的术语解释

在深入理解Kafka之前，先介绍一下Kafka中的术语。下图展示了Kafka的相关术语以及之间的关系：

上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。

如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。

1.4.1 Broker

Kafka 集群包含一个或多个服务器，服务器节点称为broker。

broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。

如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。

如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

1.4.2 Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

类似于数据库的表名

1.4.3 Partition

topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

1.4.4 Producer

生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

1.4.5 Consumer

消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。

1.4.6 Consumer Group

每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。

1.4.7 Leader

每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。

1.4.8 Follower

Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。