kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject kafka git commit: MINOR: Some images should be centered in the documentation
Date Fri, 14 Oct 2016 17:04:18 GMT
Repository: kafka
Updated Branches:
  refs/heads/trunk d09043637 -> 9662e466d

MINOR: Some images should be centered in the documentation

Author: Jason Gustafson <jason@confluent.io>

Reviewers: Ismael Juma <ismael@juma.me.uk>

Closes #2029 from hachikuji/center-some-images

Project: http://git-wip-us.apache.org/repos/asf/kafka/repo
Commit: http://git-wip-us.apache.org/repos/asf/kafka/commit/9662e466
Tree: http://git-wip-us.apache.org/repos/asf/kafka/tree/9662e466
Diff: http://git-wip-us.apache.org/repos/asf/kafka/diff/9662e466

Branch: refs/heads/trunk
Commit: 9662e466d90093c9bc5315d0b9949dfbf353b988
Parents: d090436
Author: Jason Gustafson <jason@confluent.io>
Authored: Fri Oct 14 10:04:13 2016 -0700
Committer: Jason Gustafson <jason@confluent.io>
Committed: Fri Oct 14 10:04:13 2016 -0700

 docs/design.html         | 4 ++--
 docs/implementation.html | 2 +-
 docs/introduction.html   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/design.html b/docs/design.html
index 9e53faf..a666487 100644
--- a/docs/design.html
+++ b/docs/design.html
@@ -464,7 +464,7 @@ situations where the upstream data source would not otherwise be replayable.
 Here is a high-level picture that shows the logical structure of a Kafka log with the offset
for each message.
-<img src="images/log_cleaner_anatomy.png">
+<img class="centered" src="images/log_cleaner_anatomy.png">
 The head of the log is identical to a traditional Kafka log. It has dense, sequential offsets
and retains all messages. Log compaction adds an option for handling the tail of the log.
The picture above shows a log
 with a compacted tail. Note that the messages in the tail of the log retain the original
offset assigned when they were first written&mdash;that never changes. Note also that
all offsets remain valid positions in
@@ -478,7 +478,7 @@ marked as the "delete retention point" in the above diagram.
 The compaction is done in the background by periodically recopying log segments. Cleaning
does not block reads and can be throttled to use no more than a configurable amount of I/O
throughput to avoid impacting
 producers and consumers. The actual process of compacting a log segment looks something like
-<img src="images/log_compaction.png">
+<img class="centered" src="images/log_compaction.png">
 <h4><a id="design_compactionguarantees" href="#design_compactionguarantees">What
guarantees does log compaction provide?</a></h4>

diff --git a/docs/implementation.html b/docs/implementation.html
index c22f4cf..60ca0a1 100644
--- a/docs/implementation.html
+++ b/docs/implementation.html
@@ -201,7 +201,7 @@ value          : V bytes
 The use of the message offset as the message id is unusual. Our original idea was to use
a GUID generated by the producer, and maintain a mapping from GUID to offset on each broker.
But since a consumer must maintain an ID for each server, the global uniqueness of the GUID
provides no value. Furthermore, the complexity of maintaining the mapping from a random id
to an offset requires a heavy weight index structure which must be synchronized with disk,
essentially requiring a full persistent random-access data structure. Thus to simplify the
lookup structure we decided to use a simple per-partition atomic counter which could be coupled
with the partition id and node id to uniquely identify a message; this makes the lookup structure
simpler, though multiple seeks per consumer request are still likely. However once we settled
on a counter, the jump to directly using the offset seemed natural&mdash;both after all
are monotonically increasing integers unique to a partition. Since the off
 set is hidden from the consumer API this decision is ultimately an implementation detail
and we went with the more efficient approach.
-<img src="images/kafka_log.png">
+<img class="centered" src="images/kafka_log.png">
 <h4><a id="impl_writes" href="#impl_writes">Writes</a></h4>
 The log allows serial appends which always go to the last file. This file is rolled over
to a fresh file when it reaches a configurable size (say 1GB). The log takes two configuration
parameters: <i>M</i>, which gives the number of messages to write before forcing
the OS to flush the file to disk, and <i>S</i>, which gives a number of seconds
after which a flush is forced. This gives a durability guarantee of losing at most <i>M</i>
messages or <i>S</i> seconds of data in the event of a system crash.

diff --git a/docs/introduction.html b/docs/introduction.html
index e32ae7b..d034683 100644
--- a/docs/introduction.html
+++ b/docs/introduction.html
@@ -51,7 +51,7 @@ In Kafka the communication between the clients and the servers is done with
a si
 <p>Let's first dive into the core abstraction Kafka provides for a stream of records&mdash;the
 <p>A topic is a category or feed name to which records are published. Topics in Kafka
are always multi-subscriber; that is, a topic can have zero, one, or many consumers that subscribe
to the data written to it.</p>
 <p> For each topic, the Kafka cluster maintains a partitioned log that looks like this:
-<img src="images/log_anatomy.png">
+<img class="centered" src="images/log_anatomy.png">
 <p> Each partition is an ordered, immutable sequence of records that is continually
appended to&mdash;a structured commit log. The records in the partitions are each assigned
a sequential id number called the <i>offset</i> that uniquely identifies each
record within the partition.

View raw message