kafka文档翻译（一）

原文来自（http://kafka.apache.org/documentation.html）

本文只做简单的翻译，水平有限，仅供学习交流使用

如有错误，欢迎点评指正

1  准备开始

1.1 介绍
kafka是一个分布式的，分区的，复用的日志提交服务。它以一种独特的设计方式提供消息传递系统的功能。

首先让我们回顾一些基本的消息术语
* kafka在不同的类别中维持消息，这些类别被称为主题（topic）
* 我们把发布消息给kafka topic的程序称为生产者（producer）
* 我们称那些订阅topic和处理已发布的消息的程序叫做消费者（consumer）
* kafka作为一个集群运行，集群包含一个或多个服务器，我们称这些服务器为broker

总的来看，生产者（producer）通过网络发送message（消息）给kafka集群，kafka集群再提供（基于消息）服务给consumer（消费者），如下图

客户端与服务端的通信通过一个简单的，高性能的，无关语言（language agnostic）的TCP协议完成。我们提供一个kafka的java版客户端，kafka客户端可以用多种语言实现

主题和日志（Topics and Logs）
我们首先深入了解kafka提供的高级抽象--主题（topic），topic是已发布消息的类别或饲料（feed）名，对每个主题，卡夫卡维持一个分区日志如下图

每个分区都是一个有序的不可变的消息序列，提交日志时不断地追加到消息序列里，分区里的消息都被赋予了一个顺序的id号称为偏移量（offset），这些id号唯一标识了分区里的每条消息

kafka集群会在一段可配置的时间内保留已发布的消息，不管它们是否被消费了。比如你配置了保留日志的时间是2天，那么在消息发布后的2天，这条消息一直都是可用的，可以被消费的，超过这个时间，kafka会把它删除以释放空间。kafka的性能不会因数据大小而改变，所有保存一些日志并不是问题。

###
实际上保留在每个消费者基础的唯一的元数据是消费者在日志中的位置，被称为“偏移”。
The Kafka cluster retains all published messages—whether or not they have been consumed—for a configurable period of time. 
这个偏移由消费之控制，通常消费者在读完消息后会线性前置偏移量，但实际上这个位置由消费者自己控制，它可以消费信息在任何它喜欢的位置
比如消费者可以旧的偏移量重新处理

这种特性的结合意味着kafka消费者非常方便，他们的行为对集群或其他消费着无太多影响，例如，您可以使用我们的命令行工具“tail”的任何话题，而不改变什么是任何现有的消费者消费的内容。
###
在日志中的分区一举数得。首先，他们允许日志缩放到可以适应一个单服务器，每个分区必须满足承载它的服务器上，但一个topic可能有很多partition（分区），以便它可以处理任意数量的数据。其次，它们更多的是作为并行的一个单元，而不是单独的一位

分布式（distribution）
log的分区（partition）分配在kafka集群的每台机器上，并且kafka集群中的每台服务器都都处理请求和数据，因为它们共享这些分区（partitions）。每个partition可以配置共享它们的服务器的数量，并以此来解决容错问题。

每个partition有一台服务器作为老大（leader），然后会有零或多个服务器作为小弟（followers）。leader（老大）处理所有的读写请求，而followers（小弟们）被动地复制leader的操作。如果leader fail（老大萎了），小弟（follower）中有个会成为新老大（leader），每台服务器都会有一些分区（partitions），而服务器会作为这些本地partitions的老大，作为其他不在本地的partitions的小弟，以此来达到负载均衡

生产者（Producers）
生产者（producers）根据他们的选择发布（publish）数据到主题（topics），生产者负责选择分配哪个消息到topic的哪个partition，这会通过一种基于循环的简单负载均衡方式完成，或者通过一些语意分区功能（基于在message中的key），多数分区的使用在一秒内完成

消费者（Consumers）

传统消息系统有两种模型，队列和发布-订阅。在队列模型，消费者们会从服务端读取数据，读取的数据会从队列中删除。在发布-订阅模型，消息是广播的方式发送给所有消费者，kafka提供一个单一消费抽象，涵盖了上述两种模型--consumer group（消费组）

consumer用consumer group（组名）标识自己，每条发布给主题的消息都会传递给一个消费实例（consumer instance），消费实例包含所有订阅消息的消费组，消费实例可以是不同的进程，也可以在不同的机器上。如果所有的消费实例都有相同的消费者组，那它对于消费者来说就像是传统的负载均衡队列。如果所有的消费实例有不同的消费者组，那它的工作就像消息-订阅模式，所有的消息广播给所有的消费者。

一般来说，我们发现主题只有少数的消费者组，每一个都是一个“逻辑上的订阅（logical subscriber）”。每组都有多个消费者实例组成，这样更有利于可扩展性和容错。用消费者集群代替单一进程的用意就是在此。

kafka和传统的消息消息系统一样拥有强有力的数据顺序保证。

传统的队列在服务器上有序的保存消息，当有多个消费者需要从队列消费消息时，队列会按照之前存储的顺序有序的提供数据。然而，尽管服务器是有序的分发消息，但消息时异步传递给消费者，所以这些消息到达不同的消费者时可能就出现乱序。这意味着消息的顺序在并行消费时失去的意义。消息系统通常以一个“独立消费者”的概念来解决这种问题，它只允许一个进程消费队列中的消息，但这实际意味着它不再算是并行计算。

kafka在这方面做得很好，通过“parallelism”的概念，在topics里进行分区，kafka能够给一个消费者池（a pool of customer）提供数据有序保证以及负载均衡。这是通过分配topic里的partition给消费者组里的消费者实现的，所以每个分区是被组里的一个消费者消费。通过这我们确信消费者时分区里的唯一读者，并且有序的消费数据。因为有多个分区，他还能够在多个消费者实例间实现负载均衡，尽管是这样，分区的数量仍是大于消费者的。

####

可靠性（Guarantees）

kafka提供一下可靠性保证

* 消息会以生产者发送的顺序追加到主题的分区，也就是说，通一个生产者发送同一个消息两次分别称为M1，M2，M1先发，那么M1将会有一个更小的偏移量，并且也会比M2早出现在日志中。

* 消费者以存储在日志中的顺序看见消息。

* 对于复制N倍的主题，知道N-1台服务器出错，都不会使已经提交的日志丢失

更多请参考文档的设计章节

1.2 一些使用情况

下面介绍了一些Apache kafka比较流行的使用情况，详情请戳这里

消息系统

kafka可以更好地作为传统消息代理的替代者，消息代理因为各种原因被应用。相较于大多数的消息系统卡夫卡有更好的吞吐量，内置分区，复制和容错，而这些特性使得kafka成为大规模消息处理应用的理想解决方案。

以我们的经验，消息系统的吞吐量通常较低，但却需要端到端的低延迟，而kafka的可以基于较强的持久性提供延迟保证

在消息系统领域，kafka可以媲美于传统消息系统如ActiveMQ和RabbitMQ

网站活动跟踪

传统的kafka使用例是基于kafka重建用户活动跟踪管道作为实时的发布订阅系统，这意味着