kafka消息服务器设计文档,kafka官方文档-简介-Go语言中文社区

如上图，两台服务器的kafka集群上分布四个partition(P0-P3)，两个消费群，消费群A有两个消费者实例，消费群B有四个

通常，我们会发现Topic有少量的消费群，每个消费群都是“逻辑上的订阅者”。每没消费群都是由很多消费者实例组成，从而实现可扩展性和容错性。这是Pub/Sub模式的再现，区别是这里的订阅者是一组消费者而不是一个单一的进程的消费者。

kafka实现消费群的方式是将分区分配给每个消费者实例，每个实例在任何时间点都能够公平分享独占的分区。维持消费群中的成员关系是通过kafka的动态协议处理的。如果有新的实例加入消费群中，它会接管该群中其他成员的一部分分区，如果一个实例挂掉，它管理的分区将被分配给其他的实例。

kafka只能保证一个分区内的记录有序，不能保证topic中不同的分区之间的记录也是有序的。对于多数应用程序来说，记录的排序和根据key进行数据分区的能力是足够的。但是，如果要让所有的记录都是有序的，可以通过只有一个分区的topic来实现，这意味着每个消费群同时只能有一个消费进程在消费。

保证

kafka提供以下高级别的保证：

一个生产者发送给一个topic的partition的消息将按发送顺序进行追加。也就是说，当一个生产者同时产生了M1和M2两个消息，M1先发送，那么M1在分区中的偏移量一定比M2小，在日志中出现的更早。

消费者按顺序处理存储在日志中的消息记录。

对于副本因子N的Topic，将承受最多N-1次服务器故障切换而不会损失任何的记录。

更多保证内容参见设计文档

kafka作为消息系统

相比传统的企业消息系统，kafka的设计理念是什么样的呢？

传统的消息系统有两个模式：队列和发布/订阅。队列模式，一个消费者池可以从服务器上读取数据，请求每个记录数据只会分配给其中一个消费者。发布/订阅模式，记录数据会广播给所有的消费者。这两种模式都有各种的优缺点，队列模式的优点是它可以将要的处理数据拆分，并发送到多个消费者上进行处理，这让你可以对处理进行扩展，但是队列模式不是多播的，一旦一个消费者进程读取了数据，这条数据在队列中就消失了。发布/订阅模式可以将数据广播到多个进程上，但是由于每个消息都会被所有的订阅者接收，因此无法进行扩展处理。

kafka的消费者群的概念包含了上面两个概念，队列模式，可以将要处理的数据分配给消费群上不同的消费者实例处理。作为发布订阅模式，kafka运行将消息广播到到多个消费群上。

kafka的topic兼具队列模式和发布/订阅模式-既可以进行扩展，也可以实现多订阅者，不需要专门制定某一种模式。

同时，kafka相比于传统的消息系统，具有更好有序性。

传统的队列模型，将记录有序的存储在服务器上，当多个消费者消费队列中的消息时，服务器会按照顺序处理这些记录。虽然，服务是是顺序的处理这些记录的，但是由于是传输数据给多个消费者，当消费者接收到服务器的时间是，顺序可能已经被打乱。也就是说，在并行消费的模式下，记录的有序性将无法保证。消息系统经常使用“专属消费者”的概念来解决这个问题，只允许一个进程从队列中消费消息，这样就无法实现并行处理。

通过一个并行处理的概念-主题(topic)中的分区(partition)，kafka在这方面做得更好，kafka可以同时支持有序性和负载均衡。这是通过将主题(topic)中的分区(partition)分配给消费群中的消费者来实现的，这样每个分区就会被群中的一个消费者所消费。以此来保证消费者是某个分区的唯一读者，并且按顺序消费数据。同时由于采用了多分区实现了消费者的负载均衡，需要注意的是，消费群中的消费者实例数量不能比分区数量多。

kafka作为存储系统

任何一个消息系统都可以实现生产者和消费者的解耦，也可以存储正在传输的消息。kafka与众不同，它是一个很好的存储系统。

数据写入kafka将被保存到磁盘上同时保持在副本中，kafka允许生产者等待返回确认，直到写入磁盘和副本都成功，才认为写入成功，否则认为写入失败。

kafka非常方便扩展，无论是的磁盘上有50KB还是50TB的持久化数据。

由于存储很重要，并允许客户控制读写位置，kafka可以被当作分布式文件系统使用，它是一个高性能、低延迟、高可靠可复制的日志存储系统。

kafka数据流处理

仅仅是读、写和存储数据是不够的，kafka的目的是能够实时处理数据。

在kafka中，流处理器可以从输入的主题(topic)中连续的获取数据流，并对输入进行一系列处理，同时产生连续的数据流到输出主题。

比如，零售的应用程序可能需要输入销售和出货量，根据输入数据计算出重新订购的数量和调整后的价格，然后输出到主题(topic)。

可以直接使用生产者和消费者的API进行简单的处理，但是，对于复杂的转换，kafka提供了一个完全集成的Stream API。这允许你构建程序，这些应用程序可以从流中把一些重要的计算分离出来，或者将流连接在一起。

这种机制可以解决这类应用程序的问题：复杂的数据处理，改变代码重新处理输入，有状态计算等。

Stream API建立在kafka核心单元之上：它使用生产者和消费者的API进行输入和输出，使用kafka存储有状态的数据，并使用组机制在一组流处理实例中容错。

综述

消息系统、数据存储和流处理的这种组合看起来很不一般，但是kafka作为流媒体平台来说这些都是必不可少的。像HDFS这样的分布式文件系统允许存储用于批处理的静态文件，实际上，这样的系统允许存储和处理过去的历史数据。

传统的企业消息系统可以处理在订阅后将到达的消息，以这种方式构建的应用程序可以处理即将到达的消息

kafka将这两种功能结合在一起，对于kafka的使用来说，这两种的结合对于流处理应用程序以及流数据管道来说都是非常重要的。

通过整合存储和低延迟订阅，流应用程序可以以相同的方式处理过去和将来的数据。这是一个单一的应用程序可以处理历史的，存储的数据，而不是在到达最后一个记录时结束，它可以随着未来数据的到达继续处理。这是一个广义的流处理概念，其中包含批处理以及消息驱动应用程序。同样，对于流数据管道，订阅到实时事件的组合使得可以用kafka处理非常低延迟的管道传输；可靠的存储数据的能力使得可以将其用于必须保证数据传输的关键数据，或者与离线系统集成，这些系统只能周期性的加载数据，或者可能会长时间停机以进行维护。流处理设备可以在数据到达时转换数据。有关kafka提供的保证，APIS和功能的更多信息，请参见文档其余部分。