1.
Something about Kafka
Frank Yao
@超⼤大杯摩卡星冰乐
2013-06-29
13年7月5⽇日星期五

2.
Agenda
• WHAT is Kafka?
• HOW we use it in Vipshop?
• WHY Kafka is so ‘fast’?
13年7月5⽇日星期五

3.
WHAT is Kafka?
13年7月5⽇日星期五

4.
WHAT
• “Kafka is a messaging system that was
originally developed at LinkedIn to
serve as the foundation for LinkedIn's
activity stream and operational data
processing pipeline.”
13年7月5⽇日星期五

5.
User cases
• Operational monitoring: real-time, heads-up
monitoring
• Reporting and Batch processing: load data into
a data warehouse or Hadoop system
13年7月5⽇日星期五

6.
Performance
(Below test is from Kafka website)
• Parameters:
• message size = 200 bytes
• batch size = 200 messages
• fetch size = 1MB
• flush interval = 600 messages
13年7月5⽇日星期五

7.
Batch Size
13年7月5⽇日星期五

8.
Consumer Throughput
13年7月5⽇日星期五

9.
Data Size?
13年7月5⽇日星期五

10.
Producers thread?
13年7月5⽇日星期五

11.
Topic Number?
13年7月5⽇日星期五

12.
Tradition Queue
• ActiveMQ, RabbitMQ...
13年7月5⽇日星期五

13.
13年7月5⽇日星期五

14.
My Test
• Use Flume:
• In/Out ~= 30w message per second
13年7月5⽇日星期五

15.
Kafka in Vipshop
13年7月5⽇日星期五

16.
Data ‘in’ Kafka
• Operational monitoring
• Nginx access log
• PHP error log, slow log
• Reporting and Batch processing:
• Nginx access log
• PHP error log, slow log
• App log
• b2c
• Recommend
• Pay
• Passport
13年7月5⽇日星期五

17.
How many Data?
• Peak Time(10:00~10:30):
• IN : 15k-20k msg per second
• OUT : 30k-40k msg per second
13年7月5⽇日星期五

18.
13年7月5⽇日星期五

19.
Apps depends on Kakfa
13年7月5⽇日星期五

20.
Kibana(Elasticsearch)
13年7月5⽇日星期五

21.
real-time pv uv
13年7月5⽇日星期五

22.
HDFS
13年7月5⽇日星期五

23.
Load use Kafka
13年7月5⽇日星期五

24.
Replace RabbitMQ
RabbitMQ Kafka
Servers
Load
Language
Deployment
Client
Management
RabbitMQ Kafka
6 1
>10 <2.5
Erlang Scala
Difficult Easy
A lot Not Many
Web-console JMX
13年7月5⽇日星期五

25.
WHY Kafka ‘fast’
13年7月5⽇日星期五

26.
Basics
• producers
• consumers
• consumer groups
• brokers
13年7月5⽇日星期五

27.
Kafka Arch
13年7月5⽇日星期五

28.
Kafka Arch
13年7月5⽇日星期五

29.
Kafka Deployment
13年7月5⽇日星期五

30.
Major Design Elements
• Persistent messages
• Throughput >>> features
• Consumers hold states
• ALL is distributed
13年7月5⽇日星期五

31.
Detail Agenda
• Maximizing Performance
• Filesystem vs. Memory
• BTree?
• Zero-copy
• End-to-end Batch Compression
• Consumer state
• Message delivery semantics
• Consumer state
• Push vs. Pull
• Message
• Message format
• Disk structure
• Zookeeper
• Directory Structure
13年7月5⽇日星期五

32.
Maximize Performance
13年7月5⽇日星期五

33.
Filesystem vs. Memory
Maximize Performance
13年7月5⽇日星期五

34.
Who is fast?
13年7月5⽇日星期五

35.
Memory
Filesystem
13年7月5⽇日星期五

36.
Disk
hardware linear writes random writes
6*7200rpm SATA
RAID-5
300MB/sec 50k/sec
13年7月5⽇日星期五

37.
ACM Pieces
13年7月5⽇日星期五

38.
Let’s see something REAL
13年7月5⽇日星期五

39.
Server Stats
13年7月5⽇日星期五

40.
page cache
• use free memory for disk caching to make
random write fast
13年7月5⽇日星期五

41.
13年7月5⽇日星期五

42.
Drawbacks
• All disk reads and writes will go through this
unified cache. This feature cannot easily be
turned off without using direct I/O, so even if
a process maintains an in-process cache of the
data, this data will likely be duplicated in OS
pagecache, effectively storing everything
twice.
13年7月5⽇日星期五

43.
If JVM...
13年7月5⽇日星期五

44.
13年7月5⽇日星期五

45.
If we use memory(JVM)
• The memory overhead of objects is very
high, often doubling the size of the data
stored (or worse).
• Java garbage collection becomes
increasingly sketchy and expensive as
the in-heap data increases.
13年7月5⽇日星期五

46.
cache size
• at least double the available cache by
having automatic access to all free
memory, and likely double again by
storing a compact byte structure rather
than individual objects. Doing so will
result in a cache of up to 28-30GB on a
32GB machine.
13年7月5⽇日星期五

47.
comparison
in-disk in-memory
GC
Initialization
Logic
no GC stop the world
stay warm even if
restarted
rebuilt slow(10min for
10GB) and cold cache
handle by OS handle by programs
13年7月5⽇日星期五

48.
Conclusion
• using the filesystem and relying on
pagecache is superior to maintaining an
in-memory cache or other structure
13年7月5⽇日星期五

49.
Go Extreme!
• Write to filesystem DIRECTLY!
• (In effect this just means that it is transferred
into the kernel's pagecache where the OS
can flush it later.)
13年7月5⽇日星期五

50.
Furthermore
• You can configure: every N messages or
every M seconds. It is to put a bound on
the amount of data "at risk" in the event
of a hard crash.
• Varnish use pagecache-centric design as
well.
13年7月5⽇日星期五

51.
BTree
Maximize Performance
13年7月5⽇日星期五

52.
Background
• Messaging system meta is often a BTree.
• BTree operations are O(logN).
13年7月5⽇日星期五

53.
BTree
• O(logN) ~= constant time
13年7月5⽇日星期五

54.
BTree is slow on Disk!
13年7月5⽇日星期五

55.
BTree for Disk
• Disk seeks come at 10 ms a pop
• each disk can do only one seek at a time
• parallelism is limited
• the observed performance of tree
structures is often super-linear
13年7月5⽇日星期五

56.
Lock
• Page or row locking to avoid lock the
tree
13年7月5⽇日星期五

57.
Two Facts
• no advantage of driver density because
of the heavy reliance on disk seek
• need small (< 100GB) high RPM SAS
drives to maintain a sane ratio of data
to seek capacity
13年7月5⽇日星期五

58.
Use Log file Structure!
13年7月5⽇日星期五

59.
Feature
• One queue is one log file
• Operations is O(1)
• Reads do not block writes or each other
• Decouple with data size
• Retain messages after consumption
13年7月5⽇日星期五

60.
zero-copy
Maximize Performance
13年7月5⽇日星期五

61.
1. The operating system reads data from the disk
into pagecache in kernel space
2. The application reads the data from kernel
space into a user-space buffer
3. The application writes the data back into
kernel space into a socket buffer
4. The operating system copies the data from the
socket buffer to the NIC buffer where it is sent
over the network
13年7月5⽇日星期五

62.
zerocopy
• data is copied into pagecache exactly
once and reused on each consumption
instead of being stored in memory and
copied out to kernel space every time it
is read
13年7月5⽇日星期五

63.
13年7月5⽇日星期五

64.
zerocopy performance
13年7月5⽇日星期五

65.
End-to-end Batch
Compression
Maximizing Performance
13年7月5⽇日星期五

66.
Consider that
C1
C2
C3
P1
P2
2*compression+
3*de-compression
M=num(P)
N=num(C)
M*compression+
N*de-compression
13年7月5⽇日星期五

67.
Key point
• End-to-end: compress by producers and
de-compress by consumers
• Batch: compression aims to compress a
‘message set’
• Kafka supports GZIP and Snappy
protocols
13年7月5⽇日星期五

68.
Consumer State
13年7月5⽇日星期五

69.
Facts
• No ACK
• Consumers maintain the message state
13年7月5⽇日星期五

70.
Features
• Message is in a partition
• Stored and given out in the order they
arrive
• ‘ watermark’ - ‘offset’ in Kafka
13年7月5⽇日星期五

71.
track state
• write msg state in zookeeper
• in one transaction with writing data
• side benefit: ‘rewind’ msg
13年7月5⽇日星期五

72.
Screenshot
13年7月5⽇日星期五

73.
push vs. pull
Consumer State
13年7月5⽇日星期五

74.
push system
• if a consumer is <defunct>?
13年7月5⽇日星期五

75.
Kafka use pull model
13年7月5⽇日星期五

76.
Message
Format & Data structure
13年7月5⽇日星期五

77.
Msg Format
• N byte message:
• If magic byte is 0
1. 1 byte "magic" identifier to allow format changes
2. 4 byte CRC32 of the payload
3. N - 5 byte payload
• If magic byte is 1
1. 1 byte "magic" identifier to allow format changes
2. 1 byte "attributes" identifier to allow annotations on the message independent of the
version (e.g. compression enabled, type of codec used)
3. 4 byte CRC32 of the payload
4. N - 6 byte payload
13年7月5⽇日星期五

78.
Log format on-disk
• On-disk format of a message
• message length : 4 bytes (value: 1+4+n)
• ‘magic’ value : 1 byte
• crc : 4 bytes
• payload : n bytes
• partition id and node id to uniquely identify a
message
13年7月5⽇日星期五

79.
Kafka Log Implementation
13年7月5⽇日星期五

80.
Screenshot
13年7月5⽇日星期五

81.
Screenshot
13年7月5⽇日星期五

82.
Writes
Message
13年7月5⽇日星期五

83.
Writes
• Append-write
• When rotate:
• M : M messages in a log file
• S : S seconds after last flush
• Durability guarantee: losing at most M
messages or S seconds of data in the
event of a system crash
13年7月5⽇日星期五

84.
Reads
Message
13年7月5⽇日星期五

85.
Buffer Reads
• auto double buffer size
• you can specify the max buffer size
13年7月5⽇日星期五

86.
Offset Search
• Search steps:
1. locating the log segment file in which
the data is stored
2. calculating the file-specific offset from
the global offset value
3. reading from that file offset
• Simple binary in memory
13年7月5⽇日星期五

87.
Features
• Reset the offset
• OutOfRangeException(problem we
met)
13年7月5⽇日星期五

88.
Deletes
Message
13年7月5⽇日星期五

89.
Deletes
• Policy: N days ago or N GB
• Deleting while reading?
• a copy-on-write style segment list
implementation that provides
consistent views to allow a binary
search to proceed on an immutable
static snapshot view of the log
segments
13年7月5⽇日星期五

90.
Zookeeper
13年7月5⽇日星期五

91.
Directory Structure
Zookeeper
13年7月5⽇日星期五

92.
Broker Node
• /brokers/ids/[0...N] --> host:port (ephemeral node)
13年7月5⽇日星期五

93.
Broker Topic
• /brokers/topics/[topic]/[0...N] --> nPartions (ephemeral node)
13年7月5⽇日星期五

94.
Consumer Id
• /consumers/[group_id]/ids/[consumer_id] --> {"topic1":
#streams, ..., "topicN": #streams} (ephemeral node)
13年7月5⽇日星期五

95.
Consumer Offset Tracking
• /consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] -->
offset_counter_value ((persistent node)
13年7月5⽇日星期五

96.
Partition Owner
• /consumers/[group_id]/owners/[topic]/[broker_id-partition_id] -->
consumer_node_id (ephemeral node)
13年7月5⽇日星期五

97.
Why Kafka fast?
• Maximizing Performance
• Filesystem vs. Memory
• BTree?
• Zero-copy
• End-to-end Batch Compression
• Consumer state
• Message delivery semantics
• Consumer state
• Push vs. Pull
• Message
• Message format
• Disk structure
• Zookeeper
• Directory Structure
13年7月5⽇日星期五

98.
Thank You!
13年7月5⽇日星期五