最近公司接触到了kafka,简单翻译了一下kafka的文档

Getting Started

简介:

Kafka 是一个分布式的,有分区的重复提交的日志记录服务,为系统开发者提供了一个消息中间件。

首先介绍一些基本的消息用语:

1.        Kafka 包含一系列的消息目录,命名为 topics(主题)

2.        我们把发布消息的进程叫做kafkatopic producers(topic 生产者)

3.        我们把订阅topic和消费消息的进程叫做consumer(消费者)

4.        Kafka是由一组叫做broker的机器组成的分布式集群.

从高层看,生产者通过网络发送消息到kafka集群,kafka集群为消费者提供消息。如图:

producer_consumer.png               

         图片1-1

客户端和服务端的联系通过TCP协议传输,同时提供多种语言的client

topic and log(主题和日志)

Topic(主题)

Topic 是一个目录或名称,用于提供消息的发布,对于每一个主题,卡夫卡集群保持分区日志,像这样:

log_anatomy.png

                            图片2-1

每个分区是一个有序的不可变的序列信息,可以不断的追加提交的日志。每个分区的消息都分配一个序列号唯一标识(offset)称为分区中的偏移量,可以区分中的每个消息。

在一个可配置的时间内,卡夫卡集群保留所有发布的消息,而不论消息是否已为消耗。例如,如果日志保留设置为两天,然后对两天前发布的消息是可供消费的,之后它将被丢弃释放空间。卡夫卡的性能相对于数据的大小实际上是恒定的,所以保持大量的数据是没有问题的。

事实上,每一个消费者保留的元数据是消费者在日志中的位置,被称为“offset(偏移)”。这个偏移量是由消费者控制:一般消费者将在它读取消息后递增偏移,但事实上的位置是由消费者的控制,它可以在任何位置它喜欢使用消息。例如,消费者可以重置一个旧的偏移重新处理消息。

结合这个特点意味着卡夫卡的消费者都可以方便自由的变化,而不会对群集或其他消费者造成太大的影响。例如,您可以使用命令行工具的“tail”查看主题而不会改变任何现有的消费者消费的内容。

日志中的分区有多种用途。首先,他们允许日志规模超出一个单一服务器的大小。每个分区必须适合于服务器主机,但一个topic可能有许多分区,它可以处理任意数量的数据。其次是并行性更高。

Distribution(分布式)

日志分区是分布式的,分布在卡夫卡集群每个服务器. 每个服务器处理一个共享的分区的数据。每个分区根据配置被复制在一系列的服务器容错。

每个分区都有一个服务器作为“领袖(leader)”和零个或多个服务器作为“追随者(followers)”。领导者处理所有读和写的分区要求,而追随者被动复制领导。如果领导者失败,追随者之一将自动成为新的领袖。每个服务器作为的一些分区领袖和其他分区的追随者,这样集群可以很好的负载均衡。

译者注:此处用到的是zookeeper的leader推举,有兴趣的同学可以去参考一下。

Producers(生产者)

生产者发布数据到自己选择的topic。生产者是负责选择哪些消息发送到主题的某个分区。这可以通过轮回调度实现简单地负载均衡或可以根据一些语义分区函数实现(根据消息中的一些关键key)。(更常用的是第二种)

Consumers(消费者)

传统上消息有两种模式:消息队列和发布订阅。在队列中,池中的消费者可以从一个服务器读取消息且每个消息被一个消费者读;发布订阅消息被广播到所有的消费者。卡夫卡只提供了一个消费者的抽象包含两者--消费群体(consumer group)。

消费者需要提供消费者组的名称,每个消息发布到主题然后分发到每个订阅组群体(group)的一个消费者的实例。消费者的实例可以在单独的进程或单独的机器上。

如果所有的消费者的情况下具有相同的消费群体(group),那么这个就像一个传统的队列(queue)的负载平衡。

如果所有的消费者的情况下都有不同的消费群体(group),那么这是发布-订阅,所有的消息都被广播到所有的消费者。

更常见的是,然而,我们发现,主题有小数量的消费群体,每一个都是”逻辑用户”。每个组由许多消费者的情况下,可扩展性和容错性。这无非是发布-订阅的语义的用户是消费者群而不是一个单一的进程。

 

consumer-groups.png

A two server Kafka cluster hosting four partitions (P0-P3) with two consumergroups. Consumer group A has two consumer instances and group B has four.

卡夫卡比传统的消息传递系统有较强的顺序保证机制.

传统的队列消息为有序的保留在服务器上,如果多的消费者消费从队列服务器取消息,则按存储顺序获取。然而,虽然服务器把消息顺序发出,消息通过异步传递给消费者,所以他们可能到达消费者的顺序不同。这意味着存在并行时消费信息失去了排序。通讯系统经常工作在这有一个“独家消费”,仅允许一个进程从一个队列的消费消息,当然,这意味着有没有并行处理。

卡夫卡做的更好。通过概念并行性--主题中的分区,卡夫卡是能够同时提供消费者进程池排序保证和负载平衡。这是通过指定主题(topic)的分区给消费者的消费群,使每个分区由一个使用者群组中的一个消费者来消费。通过这样做,我们确保消费者的是分区的唯一阅读器和数据的顺序。因为有许多的分区,这仍然可以平衡负载很多消费者情况。但是请注意,消费者的实例不能多于分区的数量.

    卡夫卡在消息中只提供了分区的总的顺序,在一个主题的不同分区之间是不存在顺序的。每个分区的顺序结合通过按键来分割数据的能力是足以满足大多数应用。不过,如果你需要一个topic的一个总顺序消息可以用只有一个分区的topic实现,尽管这将意味着只有一个消费者进程。

Guarantees(保证因素)

从kafka的高层看,kafka提供一下几点保证:

由生产者发送到一个特定的主题分区的消息将按照他们发送的顺序增加 。例如,如果相同的生产者发送消息M1,M2,M1先发送,则 M1会比M2拥有较低偏移且出现在日志之前。

消费者将能顺序的看到存储在log中的信息.

对于一个topic复制N份,如果有N-1台server失败,将不会有信息丢失。