提交 e43ebbe3 编写于 作者: W wizardforcel

2021-05-08 11:17:55

上级 99c486a5
......@@ -482,7 +482,7 @@ var context={
<li>The <a href="documentation/streams">Streams API</a> 允许一个应用程序作为一个<i>流处理器</i>消费一个或者多个topic产生的输入流然后生产一个输出流到一个或多个topic中去在输入输出流中进行有效的转换
<li>The <a href="documentation.html#connect">Connector API</a> 允许构建并运行可重用的生产者或者消费者,将Kafka topics连接到已存在的应用程序或者数据系统。比如,连接到一个关系型数据库,捕捉表(table)的所有变更内容
</ul>
<img src="{{version}}/images/kafka-apis.png" style="float: right; width: 50%;">
<img src="images/kafka-apis.png" style="float: right; width: 50%;">
</div>
<p>
在Kafka中客户端和服务器使用一个简单高性能支持多语言的 <a href="https://kafka.apache.org/protocol.html">TCP 协议</a>.此协议版本化并且向下兼容老版本, 我们为Kafka提供了Java客户端,也支持许多<a href="https://cwiki.apache.org/confluence/display/KAFKA/Clients">其他语言的客户端</a>。</p>
......@@ -491,14 +491,14 @@ var context={
<p>让我们首先深入了解下Kafka的核心概念:提供一串流式的记录&mdash; topic 。</p>
<p>Topic 就是数据主题,是数据记录发布的地方,可以用来区分业务系统。Kafka中的Topics总是多订阅者模式,一个topic可以拥有一个或者多个消费者来订阅它的数据。</p>
<p>对于每一个topic, Kafka集群都会维持一个分区日志,如下所示: </p>
<img class="centered" src="{{version}}/images/log_anatomy.png">
<img class="centered" src="images/log_anatomy.png">
<p>每个分区都是有序且顺序不可变的记录集,并且不断地追加到结构化的commit log文件。分区中的每一个记录都会分配一个id号来表示顺序,我们称之为offset,<i>offset</i>用来唯一的标识分区中每一条记录。
</p>
<p>
Kafka 集群保留所有发布的记录&mdash;无论他们是否已被消费&mdash;并通过一个可配置的参数——保留期限来控制. 举个例子, 如果保留策略设置为2天,一条记录发布后两天内,可以随时被消费,两天过后这条记录会被抛弃并释放磁盘空间。Kafka的性能和数据大小无关,所以长时间存储数据没有什么问题.
</p>
<img class="centered" src="{{version}}/images/log_consumer.png" style="width:400px">
<img class="centered" src="images/log_consumer.png" style="width:400px">
<p>
事实上,在每一个消费者中唯一保存的元数据是offset(偏移量)即消费在log中的位置.偏移量由消费者所控制:通常在读取记录后,消费者会以线性的方式增加偏移量,但是实际上,由于这个位置由消费者控制,所以消费者可以采用任何顺序来消费记录。例如,一个消费者可以重置到一个旧的偏移量,从而重新处理过去的数据;也可以跳过最近的记录,从"现在"开始消费。
</p>
......@@ -533,7 +533,7 @@ var context={
<p>
如果所有的消费者实例在不同的消费组中,每条消息记录会广播到所有的消费者进程.
</p>
<img class="centered" src="{{version}}/images/consumer-groups.png">
<img class="centered" src="images/consumer-groups.png">
<p>
如图,这个 Kafka 集群有两台 server 的,四个分区(p0-p3)和两个消费者组。消费组A有两个消费者,消费组B有四个消费者。
</p>
......@@ -3190,7 +3190,7 @@ ISR 副本同步完成,就会返回消息已经写入。例如,一个 topic
<h4><a id="design_compactionbasics" href="#design_compactionbasics">日志压缩基础</a></h4>
这是一个高级别的日志逻辑图展示了kafka日志的每条消息的offset逻辑结构
<p>
<img class="centered" src="{{version}}/images/log_cleaner_anatomy.png">
<img class="centered" src="images/log_cleaner_anatomy.png">
<p>
Log head中包含传统的Kafka日志它包含了连续的offset和所有的消息
日志压缩增加了处理tail Log的选项
......@@ -3206,7 +3206,7 @@ ISR 副本同步完成,就会返回消息已经写入。例如,一个 topic
压缩操作通过在后台周期性的拷贝日志段来完成
清除操作不会阻塞读取并且可以被配置不超过一定IO吞吐来避免影响Producer和Consumer实际的日志段压缩过程有点像这样
<p>
<img class="centered" src="{{version}}/images/log_compaction.png">
<img class="centered" src="images/log_compaction.png">
<p>
<h4><a id="design_compactionguarantees" href="#design_compactionguarantees">What guarantees does log compaction provide?</a></h4>
日志压缩的保障措施如下
......@@ -3447,7 +3447,7 @@ Log Cleaner默认启用。这会启动清理的线程池。如果要开始特定
<p>
消息的偏移量用作消息 id 是不常见的.我们最开始的想法是使用 producer 自增的 GUID ,并维护从 GUID 到每个 broker offset 的映射.这样的话每个消费者需要为每个服务端维护一个 ID,提供全球唯一的 GUID 没有意义.而且,维护一个从随机 ID 到偏移量映射的复杂度需要一个重度的索引结构,它需要与磁盘进行同步,本质上需要一个完整的持久随机访问数据结构.因此为了简化查找结构,我们决定针对每个分区使用一个原子计数器,它可以利用分区id和节点id唯一标识一条消息.虽然这使得查找结构足够简单,但每个消费者的多个查询请求依然是相似的.一旦我们决定使用使用计数器,直接跳转到对应的偏移量显得更加自然-毕竟对于每个分区来说它们都是一个单调递增的整数.由于消费者API隐藏了偏移量所以这个决定最终是一个实现细节我们采用了更高效的方法
</p>
<img class="centered" src="{{version}}/images/kafka_log.png">
<img class="centered" src="images/kafka_log.png">
<h4><a id="impl_writes" href="#impl_writes">Writes</a></h4>
<p>
日志允许序列化的追加到最后一个文件中.当文件大小达到配置的大小(默认 1G),会生成一个新的文件.日志中有两个配置参数: <i>M</i> 是在 OS 强制写文件到磁盘之前的消息条数, <i>S</i> 是强制写盘的秒数.这提供了一个在系统崩溃时最多丢失 <i>M</i> 条或者 <i>S</i> 秒消息的保证.
......
......@@ -53,7 +53,7 @@ var context={
<p>
下图展示了使用Kafka Streams库的应用程序的解剖结构让我们来看看一些细节
</p>
<img class="centered" src="{{version}}/images/streams-architecture-overview.jpg" style="width:750px">
<img class="centered" src="images/streams-architecture-overview.jpg" style="width:750px">
<h3><a id="streams_architecture_tasks" href="#streams_architecture_tasks">Stream Partitions and Tasks</a></h3>
......@@ -87,7 +87,7 @@ var context={
<p>
下图显示了两个任务每个任务分配 input stream 一个 partition
</p>
<img class="centered" src="{{version}}/images/streams-architecture-tasks.jpg" style="width:400px">
<img class="centered" src="images/streams-architecture-tasks.jpg" style="width:400px">
<br>
<h3><a id="streams_architecture_threads" href="#streams_architecture_threads">Threading Model</a></h3>
......@@ -96,7 +96,7 @@ var context={
Kafka Streams 允许用户配置应用程序实例中可并行的<b>线程数量</b>
每个线程都可以按照处理器拓扑结构独立执行一个或多个任务 例如下图显示了一个运行两个流任务的流线程
</p>
<img class="centered" src="{{version}}/images/streams-architecture-threads.jpg" style="width:400px">
<img class="centered" src="images/streams-architecture-threads.jpg" style="width:400px">
<p>
启动更多流线程或更多的应用程序实例仅仅意味着可以复制更多的拓扑结构来处理不同的Kafka分区子集从而有效地并行处理
......@@ -125,7 +125,7 @@ var context={
<p>
下图中的两个流任务都具有专用的 local state stores 。
</p>
<img class="centered" src="{{version}}/images/streams-architecture-states.jpg" style="width:400px">
<img class="centered" src="images/streams-architecture-states.jpg" style="width:400px">
<br>
<h3><a id="streams_architecture_recovery" href="#streams_architecture_recovery">Fault Tolerance</a></h3>
......
......@@ -101,7 +101,7 @@ var context={
注意一个正常的处理器节点在处理记录的同时是可以访问其他远程系统因此它的处理结果既可以写入到其他远程系统也可以回流到 Kafka 系统中
<img class="centered" src="{{version}}/images/streams-architecture-topology.jpg" style="width:400px">
<img class="centered" src="images/streams-architecture-topology.jpg" style="width:400px">
<p>
Kafka Streams 提供两种定义流处理拓扑结构的方式 <a href="{{version}}/documentation/streams/developer-guide#streams_dsl"><b>Kafka Streams DSL</b></a> 提供
......
......@@ -534,7 +534,7 @@ Note that in the <code>WordCountProcessor</code> implementation, users need to r
<p>
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:
</p>
<img class="centered" src="{{version}}/images/streams-table-duality-01.png">
<img class="centered" src="images/streams-table-duality-01.png">
The <b>stream-table duality</b> describes the close relationship between streams and tables.
<ul>
......@@ -545,12 +545,12 @@ Note that in the <code>WordCountProcessor</code> implementation, users need to r
<p>
Let's illustrate this with an example. Imagine a table that tracks the total number of pageviews by user (first column of diagram below). Over time, whenever a new pageview event is processed, the state of the table is updated accordingly. Here, the state changes between different points in time - and different revisions of the table - can be represented as a changelog stream (second column).
</p>
<img class="centered" src="{{version}}/images/streams-table-duality-02.png" style="width:300px">
<img class="centered" src="images/streams-table-duality-02.png" style="width:300px">
<p>
Interestingly, because of the stream-table duality, the same stream can be used to reconstruct the original table (third column):
</p>
<img class="centered" src="{{version}}/images/streams-table-duality-03.png" style="width:600px">
<img class="centered" src="images/streams-table-duality-03.png" style="width:600px">
<p>
The same mechanism is used, for example, to replicate databases via change data capture (CDC) and, within Kafka Streams, to replicate its so-called state stores across machines for fault-tolerance.
......@@ -1178,7 +1178,7 @@ Note that in the <code>WordCountProcessor</code> implementation, users need to r
The following diagram shows their relationships:
</p>
<figure>
<img class="centered" src="{{version}}/images/streams-stateful_operations.png" style="width:500pt;">
<img class="centered" src="images/streams-stateful_operations.png" style="width:500pt;">
<figcaption style="text-align: center;"><i>Stateful transformations in the DSL</i></figcaption>
</figure>
......@@ -2104,13 +2104,13 @@ Note that in the <code>WordCountProcessor</code> implementation, users need to r
<figure>
<img class="centered" src="{{version}}/images/streams-interactive-queries-01.png" style="width:600pt;">
<img class="centered" src="images/streams-interactive-queries-01.png" style="width:600pt;">
<figcaption style="text-align: center;"><i>Without interactive queries: increased complexity and heavier footprint of architecture</i></figcaption>
</figure>
<figure>
<img class="centered" src="{{version}}/images/streams-interactive-queries-02.png" style="width:500pt;">
<img class="centered" src="images/streams-interactive-queries-02.png" style="width:500pt;">
<figcaption style="text-align: center;"><i>With interactive queries: simplified, more application-centric architecture</i></figcaption>
</figure>
......@@ -2147,7 +2147,7 @@ Note that in the <code>WordCountProcessor</code> implementation, users need to r
It is important to understand that the state of your application -- to be extra clear, we might call it "the full state of the entire application" -- is typically split across many distributed instances of your application, and thus across many state stores that are managed locally by these application instances.
</p>
<img class="centered" src="{{version}}/images/streams-interactive-queries-03.png" style="width:400pt; height:400pt;">
<img class="centered" src="images/streams-interactive-queries-03.png" style="width:400pt; height:400pt;">
<p>
Accordingly, the API to let you interactively query your application's state has two parts, a <i>local</i> and a <i>remote</i> one:
......@@ -2202,7 +2202,7 @@ Note that in the <code>WordCountProcessor</code> implementation, users need to r
</p>
<figure>
<img class="centered" src="{{version}}/images/streams-interactive-queries-api-01.png" style="width:500pt;">
<img class="centered" src="images/streams-interactive-queries-api-01.png" style="width:500pt;">
<figcaption style="text-align: center;"><i>Every application instance can directly query any of its local state stores</i></figcaption>
</figure>
......@@ -2495,7 +2495,7 @@ Note that in the <code>WordCountProcessor</code> implementation, users need to r
</ol>
<figure>
<img class="centered" src="{{version}}/images/streams-interactive-queries-api-02.png" style="width:500pt;">
<img class="centered" src="images/streams-interactive-queries-api-02.png" style="width:500pt;">
<figcaption style="text-align: center;"><i>Discover any running instances of the same application as well as the respective RPC endpoints they expose for interactive queries</i></figcaption>
</figure>
......@@ -2735,7 +2735,7 @@ Note that in the <code>WordCountProcessor</code> implementation, users need to r
Third, the number of records output has been reduced (here: from 15 to 8).
</p>
<img class="centered" src="{{version}}/images/streams-cache-and-commit-interval.png" style="width:500pt;height:400pt;">
<img class="centered" src="images/streams-cache-and-commit-interval.png" style="width:500pt;height:400pt;">
<h4><a id="streams_developer-guide_memory-management_state-store-cache" href="#streams_developer-guide_memory-management_state-store-cache">State store caches in the Processor API</a></h4>
<p>
......
......@@ -338,8 +338,8 @@ summit 1
第二列显示从KTable的状态更新以及发送到Kafka output topic <b>streams-wordcount-output</b> 的更改记录。
</p>
<img src="{{version}}/images/streams-table-updates-02.png" style="float: right; width: 25%;">
<img src="{{version}}/images/streams-table-updates-01.png" style="float: right; width: 25%;">
<img src="images/streams-table-updates-02.png" style="float: right; width: 25%;">
<img src="images/streams-table-updates-01.png" style="float: right; width: 25%;">
<p>
首先,当第一行文本 "all streams lead to kafka" 开始被处理。
......
......@@ -236,7 +236,7 @@ var context={
<li>The <a href="documentation/streams">Streams API</a> 允许一个应用程序作为一个<i>流处理器</i>消费一个或者多个topic产生的输入流然后生产一个输出流到一个或多个topic中去在输入输出流中进行有效的转换
<li>The <a href="documentation.html#connect">Connector API</a> 允许构建并运行可重用的生产者或者消费者,将Kafka topics连接到已存在的应用程序或者数据系统。比如,连接到一个关系型数据库,捕捉表(table)的所有变更内容
</ul>
<img src="{{version}}/images/kafka-apis.png" style="float: right; width: 50%;">
<img src="images/kafka-apis.png" style="float: right; width: 50%;">
</div>
<p>
在Kafka中客户端和服务器使用一个简单高性能支持多语言的 <a href="https://kafka.apache.org/protocol.html">TCP 协议</a>.此协议版本化并且向下兼容老版本, 我们为Kafka提供了Java客户端,也支持许多<a href="https://cwiki.apache.org/confluence/display/KAFKA/Clients">其他语言的客户端</a>。</p>
......@@ -245,14 +245,14 @@ var context={
<p>让我们首先深入了解下Kafka的核心概念:提供一串流式的记录&mdash; topic 。</p>
<p>Topic 就是数据主题,是数据记录发布的地方,可以用来区分业务系统。Kafka中的Topics总是多订阅者模式,一个topic可以拥有一个或者多个消费者来订阅它的数据。</p>
<p>对于每一个topic, Kafka集群都会维持一个分区日志,如下所示: </p>
<img class="centered" src="{{version}}/images/log_anatomy.png">
<img class="centered" src="images/log_anatomy.png">
<p>每个分区都是有序且顺序不可变的记录集,并且不断地追加到结构化的commit log文件。分区中的每一个记录都会分配一个id号来表示顺序,我们称之为offset,<i>offset</i>用来唯一的标识分区中每一条记录。
</p>
<p>
Kafka 集群保留所有发布的记录&mdash;无论他们是否已被消费&mdash;并通过一个可配置的参数——保留期限来控制. 举个例子, 如果保留策略设置为2天,一条记录发布后两天内,可以随时被消费,两天过后这条记录会被抛弃并释放磁盘空间。Kafka的性能和数据大小无关,所以长时间存储数据没有什么问题.
</p>
<img class="centered" src="{{version}}/images/log_consumer.png" style="width:400px">
<img class="centered" src="images/log_consumer.png" style="width:400px">
<p>
事实上,在每一个消费者中唯一保存的元数据是offset(偏移量)即消费在log中的位置.偏移量由消费者所控制:通常在读取记录后,消费者会以线性的方式增加偏移量,但是实际上,由于这个位置由消费者控制,所以消费者可以采用任何顺序来消费记录。例如,一个消费者可以重置到一个旧的偏移量,从而重新处理过去的数据;也可以跳过最近的记录,从"现在"开始消费。
</p>
......@@ -287,7 +287,7 @@ var context={
<p>
如果所有的消费者实例在不同的消费组中,每条消息记录会广播到所有的消费者进程.
</p>
<img class="centered" src="{{version}}/images/consumer-groups.png">
<img class="centered" src="images/consumer-groups.png">
<p>
如图,这个 Kafka 集群有两台 server 的,四个分区(p0-p3)和两个消费者组。消费组A有两个消费者,消费组B有四个消费者。
</p>
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册