Upload
baniuyao
View
137
Download
3
Embed Size (px)
DESCRIPTION
This slide briefly introduced the reason why kafka is so fast in performance.
Citation preview
Something about KafkaFrank Yao
@超⼤大杯摩卡星冰乐2013-06-29
13年7月5⽇日星期五
Agenda
• WHAT is Kafka?
• HOW we use it in Vipshop?
• WHY Kafka is so ‘fast’?
13年7月5⽇日星期五
WHAT is Kafka?
13年7月5⽇日星期五
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⽇日星期五
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⽇日星期五
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⽇日星期五
Batch Size
13年7月5⽇日星期五
Consumer Throughput
13年7月5⽇日星期五
Data Size?
13年7月5⽇日星期五
Producers thread?
13年7月5⽇日星期五
Topic Number?
13年7月5⽇日星期五
Tradition Queue
• ActiveMQ, RabbitMQ...
13年7月5⽇日星期五
13年7月5⽇日星期五
My Test
• Use Flume:
• In/Out ~= 30w message per second
13年7月5⽇日星期五
Kafka in Vipshop
13年7月5⽇日星期五
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⽇日星期五
How many Data?
• Peak Time(10:00~10:30):
• IN : 15k-20k msg per second
• OUT : 30k-40k msg per second
13年7月5⽇日星期五
13年7月5⽇日星期五
Apps depends on Kakfa
13年7月5⽇日星期五
Kibana(Elasticsearch)
13年7月5⽇日星期五
real-time pv uv
13年7月5⽇日星期五
HDFS
13年7月5⽇日星期五
Load use Kafka
13年7月5⽇日星期五
Replace RabbitMQRabbitMQ 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⽇日星期五
WHY Kafka ‘fast’
13年7月5⽇日星期五
Basics
• producers
• consumers
• consumer groups
• brokers
13年7月5⽇日星期五
Kafka Arch
13年7月5⽇日星期五
Kafka Arch
13年7月5⽇日星期五
Kafka Deployment
13年7月5⽇日星期五
Major Design Elements
• Persistent messages
• Throughput >>> features
• Consumers hold states
• ALL is distributed
13年7月5⽇日星期五
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⽇日星期五
Maximize Performance
13年7月5⽇日星期五
Filesystem vs. MemoryMaximize Performance
13年7月5⽇日星期五
Who is fast?
13年7月5⽇日星期五
Memory
Filesystem
13年7月5⽇日星期五
Disk
hardware linear writes random writes
6*7200rpm SATA RAID-5 300MB/sec 50k/sec
13年7月5⽇日星期五
ACM Pieces
13年7月5⽇日星期五
Let’s see something REAL
13年7月5⽇日星期五
Server Stats
13年7月5⽇日星期五
page cache
• use free memory for disk caching to make random write fast
13年7月5⽇日星期五
13年7月5⽇日星期五
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⽇日星期五
If JVM...
13年7月5⽇日星期五
13年7月5⽇日星期五
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⽇日星期五
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⽇日星期五
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⽇日星期五
Conclusion
• using the filesystem and relying on pagecache is superior to maintaining an in-memory cache or other structure
13年7月5⽇日星期五
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⽇日星期五
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⽇日星期五
BTreeMaximize Performance
13年7月5⽇日星期五
Background
• Messaging system meta is often a BTree.
• BTree operations are O(logN).
13年7月5⽇日星期五
BTree• O(logN) ~= constant time
13年7月5⽇日星期五
BTree is slow on Disk!
13年7月5⽇日星期五
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⽇日星期五
Lock
• Page or row locking to avoid lock the tree
13年7月5⽇日星期五
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⽇日星期五
Use Log file Structure!
13年7月5⽇日星期五
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⽇日星期五
zero-copyMaximize Performance
13年7月5⽇日星期五
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⽇日星期五
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⽇日星期五
13年7月5⽇日星期五
zerocopy performance
13年7月5⽇日星期五
End-to-end Batch CompressionMaximizing Performance
13年7月5⽇日星期五
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⽇日星期五
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⽇日星期五
Consumer State
13年7月5⽇日星期五
Facts
• No ACK
• Consumers maintain the message state
13年7月5⽇日星期五
Features
• Message is in a partition
• Stored and given out in the order they arrive
• ‘ watermark’ - ‘offset’ in Kafka
13年7月5⽇日星期五
track state
• write msg state in zookeeper
• in one transaction with writing data
• side benefit: ‘rewind’ msg
13年7月5⽇日星期五
Screenshot
13年7月5⽇日星期五
push vs. pullConsumer State
13年7月5⽇日星期五
push system
• if a consumer is <defunct>?
13年7月5⽇日星期五
Kafka use pull model
13年7月5⽇日星期五
MessageFormat & Data structure
13年7月5⽇日星期五
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⽇日星期五
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⽇日星期五
Kafka Log Implementation
13年7月5⽇日星期五
Screenshot
13年7月5⽇日星期五
Screenshot
13年7月5⽇日星期五
WritesMessage
13年7月5⽇日星期五
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⽇日星期五
ReadsMessage
13年7月5⽇日星期五
Buffer Reads
• auto double buffer size
• you can specify the max buffer size
13年7月5⽇日星期五
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⽇日星期五
Features
• Reset the offset
• OutOfRangeException(problem we met)
13年7月5⽇日星期五
DeletesMessage
13年7月5⽇日星期五
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⽇日星期五
Zookeeper
13年7月5⽇日星期五
Directory StructureZookeeper
13年7月5⽇日星期五
Broker Node
• /brokers/ids/[0...N] --> host:port (ephemeral node)
13年7月5⽇日星期五
Broker Topic
• /brokers/topics/[topic]/[0...N] --> nPartions (ephemeral node)
13年7月5⽇日星期五
Consumer Id
• /consumers/[group_id]/ids/[consumer_id] --> {"topic1": #streams, ..., "topicN": #streams} (ephemeral node)
13年7月5⽇日星期五
Consumer Offset Tracking
• /consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] --> offset_counter_value ((persistent node)
13年7月5⽇日星期五
Partition Owner
• /consumers/[group_id]/owners/[topic]/[broker_id-partition_id] --> consumer_node_id (ephemeral node)
13年7月5⽇日星期五
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⽇日星期五
Thank You!
13年7月5⽇日星期五