diff --git a/doc/kafka-100-doc-zh/documentation.html b/doc/kafka-100-doc-zh/documentation.html index d105defb4d86a3b4b0b42c0820d347ca4ab87645..aa9944d982ef29f47b54c1cff9b24ca06aaec735 100644 --- a/doc/kafka-100-doc-zh/documentation.html +++ b/doc/kafka-100-doc-zh/documentation.html @@ -482,7 +482,7 @@ var context={
  • The Streams API 允许一个应用程序作为一个流处理器，消费一个或者多个topic产生的输入流，然后生产一个输出流到一个或多个topic中去，在输入输出流中进行有效的转换。
  • The Connector API 允许构建并运行可重用的生产者或者消费者，将Kafka topics连接到已存在的应用程序或者数据系统。比如，连接到一个关系型数据库，捕捉表（table）的所有变更内容。 - +

    在Kafka中，客户端和服务器使用一个简单、高性能、支持多语言的 TCP 协议.此协议版本化并且向下兼容老版本， 我们为Kafka提供了Java客户端，也支持许多其他语言的客户端。

    @@ -491,14 +491,14 @@ var context={

    让我们首先深入了解下Kafka的核心概念:提供一串流式的记录— topic 。

    Topic 就是数据主题，是数据记录发布的地方,可以用来区分业务系统。Kafka中的Topics总是多订阅者模式，一个topic可以拥有一个或者多个消费者来订阅它的数据。

    对于每一个topic， Kafka集群都会维持一个分区日志，如下所示：

    - +

    每个分区都是有序且顺序不可变的记录集，并且不断地追加到结构化的commit log文件。分区中的每一个记录都会分配一个id号来表示顺序，我们称之为offset，offset用来唯一的标识分区中每一条记录。

    Kafka 集群保留所有发布的记录—无论他们是否已被消费—并通过一个可配置的参数——保留期限来控制. 举个例子， 如果保留策略设置为2天，一条记录发布后两天内，可以随时被消费，两天过后这条记录会被抛弃并释放磁盘空间。Kafka的性能和数据大小无关，所以长时间存储数据没有什么问题.

    - +

    事实上，在每一个消费者中唯一保存的元数据是offset（偏移量）即消费在log中的位置.偏移量由消费者所控制:通常在读取记录后，消费者会以线性的方式增加偏移量，但是实际上，由于这个位置由消费者控制，所以消费者可以采用任何顺序来消费记录。例如，一个消费者可以重置到一个旧的偏移量，从而重新处理过去的数据；也可以跳过最近的记录，从"现在"开始消费。

    @@ -533,7 +533,7 @@ var context={

    如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程.

    - +

    如图，这个 Kafka 集群有两台 server 的，四个分区(p0-p3)和两个消费者组。消费组A有两个消费者，消费组B有四个消费者。

    @@ -3190,7 +3190,7 @@ ISR 副本同步完成，就会返回消息已经写入。例如，一个 topic

    日志压缩基础

    这是一个高级别的日志逻辑图，展示了kafka日志的每条消息的offset逻辑结构。

    - +

    Log head中包含传统的Kafka日志，它包含了连续的offset和所有的消息。 日志压缩增加了处理tail Log的选项。 @@ -3206,7 +3206,7 @@ ISR 副本同步完成，就会返回消息已经写入。例如，一个 topic 压缩操作通过在后台周期性的拷贝日志段来完成。 清除操作不会阻塞读取，并且可以被配置不超过一定IO吞吐来避免影响Producer和Consumer。实际的日志段压缩过程有点像这样：

    - +

    What guarantees does log compaction provide?

    日志压缩的保障措施如下： @@ -3447,7 +3447,7 @@ Log Cleaner默认启用。这会启动清理的线程池。如果要开始特定

    消息的偏移量用作消息 id 是不常见的.我们最开始的想法是使用 producer 自增的 GUID ,并维护从 GUID 到每个 broker 的 offset 的映射.这样的话每个消费者需要为每个服务端维护一个 ID,提供全球唯一的 GUID 没有意义.而且,维护一个从随机 ID 到偏移量映射的复杂度需要一个重度的索引结构,它需要与磁盘进行同步,本质上需要一个完整的持久随机访问数据结构.因此为了简化查找结构,我们决定针对每个分区使用一个原子计数器,它可以利用分区id和节点id唯一标识一条消息.虽然这使得查找结构足够简单,但每个消费者的多个查询请求依然是相似的.一旦我们决定使用使用计数器,直接跳转到对应的偏移量显得更加自然-毕竟对于每个分区来说它们都是一个单调递增的整数.由于消费者API隐藏了偏移量，所以这个决定最终是一个实现细节，我们采用了更高效的方法。

    - +

    Writes

    日志允许序列化的追加到最后一个文件中.当文件大小达到配置的大小(默认 1G)时,会生成一个新的文件.日志中有两个配置参数: M 是在 OS 强制写文件到磁盘之前的消息条数, S 是强制写盘的秒数.这提供了一个在系统崩溃时最多丢失 M 条或者 S 秒消息的保证. diff --git a/doc/kafka-100-doc-zh/documentation/streams/architecture.html b/doc/kafka-100-doc-zh/documentation/streams/architecture.html index cf682a5dee5b37ffeafae89ff305d5ae0c5865c5..eb715e55daf1c3b8cda55539c2bc11e6310bffc6 100644 --- a/doc/kafka-100-doc-zh/documentation/streams/architecture.html +++ b/doc/kafka-100-doc-zh/documentation/streams/architecture.html @@ -53,7 +53,7 @@ var context={

    下图展示了使用Kafka Streams库的应用程序的解剖结构。让我们来看看一些细节。

    - +

    Stream Partitions and Tasks

    @@ -87,7 +87,7 @@ var context={

    下图显示了两个任务，每个任务分配 input stream 的 一个 partition。

    - +

    Threading Model

    @@ -96,7 +96,7 @@ var context={ Kafka Streams 允许用户配置应用程序实例中可并行的线程数量。 每个线程都可以按照处理器拓扑结构独立执行一个或多个任务。 例如，下图显示了一个运行两个流任务的流线程。

    - +

    启动更多流线程或更多的应用程序实例仅仅意味着可以复制更多的拓扑结构来处理不同的Kafka分区子集，从而有效地并行处理。 @@ -125,7 +125,7 @@ var context={

    下图中的两个流任务都具有专用的 local state stores 。

    - +

    Fault Tolerance

    diff --git a/doc/kafka-100-doc-zh/documentation/streams/core-concepts.html b/doc/kafka-100-doc-zh/documentation/streams/core-concepts.html index 299b8cf218cea990338e6ae233e6f6f14e3bc4bb..5000d0ee41ce2c2a40a3c8d6135ac197e67f153f 100644 --- a/doc/kafka-100-doc-zh/documentation/streams/core-concepts.html +++ b/doc/kafka-100-doc-zh/documentation/streams/core-concepts.html @@ -101,7 +101,7 @@ var context={ 注意：一个正常的处理器节点在处理记录的同时是可以访问其他远程系统。因此，它的处理结果既可以写入到其他远程系统，也可以回流到 Kafka 系统中。 - +

    Kafka Streams 提供两种定义流处理拓扑结构的方式： Kafka Streams DSL 提供 diff --git a/doc/kafka-100-doc-zh/documentation/streams/developer-guide.html b/doc/kafka-100-doc-zh/documentation/streams/developer-guide.html index 9c0b5e17b9864473bf62f4a421f1e2e0f895265a..2c395584b1258d3d50c19be8b85a68ceb6d330e3 100644 --- a/doc/kafka-100-doc-zh/documentation/streams/developer-guide.html +++ b/doc/kafka-100-doc-zh/documentation/streams/developer-guide.html @@ -534,7 +534,7 @@ Note that in the WordCountProcessor implementation, users need to r

    A simple form of a table is a collection of key-value pairs, also called a map or associative array. Such a table may look as follows:

    - + The stream-table duality describes the close relationship between streams and tables. - +

    在Kafka中，客户端和服务器使用一个简单、高性能、支持多语言的 TCP 协议.此协议版本化并且向下兼容老版本， 我们为Kafka提供了Java客户端，也支持许多其他语言的客户端。

    @@ -245,14 +245,14 @@ var context={

    让我们首先深入了解下Kafka的核心概念:提供一串流式的记录— topic 。

    Topic 就是数据主题，是数据记录发布的地方,可以用来区分业务系统。Kafka中的Topics总是多订阅者模式，一个topic可以拥有一个或者多个消费者来订阅它的数据。

    对于每一个topic， Kafka集群都会维持一个分区日志，如下所示：

    - +

    每个分区都是有序且顺序不可变的记录集，并且不断地追加到结构化的commit log文件。分区中的每一个记录都会分配一个id号来表示顺序，我们称之为offset，offset用来唯一的标识分区中每一条记录。

    Kafka 集群保留所有发布的记录—无论他们是否已被消费—并通过一个可配置的参数——保留期限来控制. 举个例子， 如果保留策略设置为2天，一条记录发布后两天内，可以随时被消费，两天过后这条记录会被抛弃并释放磁盘空间。Kafka的性能和数据大小无关，所以长时间存储数据没有什么问题.

    - +

    事实上，在每一个消费者中唯一保存的元数据是offset（偏移量）即消费在log中的位置.偏移量由消费者所控制:通常在读取记录后，消费者会以线性的方式增加偏移量，但是实际上，由于这个位置由消费者控制，所以消费者可以采用任何顺序来消费记录。例如，一个消费者可以重置到一个旧的偏移量，从而重新处理过去的数据；也可以跳过最近的记录，从"现在"开始消费。

    @@ -287,7 +287,7 @@ var context={

    如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程.

    - +

    如图，这个 Kafka 集群有两台 server 的，四个分区(p0-p3)和两个消费者组。消费组A有两个消费者，消费组B有四个消费者。