kafka 實戰

ps: 描述圖來自"Apache kafka 實戰"

創建topic

cd /usr/local/kafka

bin/kafka-topics.sh --create --zookeeper localhost:2181 --topic test --partitions 1 --replication-factor 1

控制臺顯示創建成功

kafka的日志

zookeeper的日志

查看topic的狀態

bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test

(PartitionCount)分區數

(ReplicationFactor)副本數

發送消息

bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

消費消息

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning

生產者:

消費者:

(message system) 消息引擎/消息隊列

消息引擎功能

解耦

異步

削峰

設計消息引擎的重要理念:

消息設計

傳輸協議設計

消息引擎的重要模型:

消息隊列模型(點到點/P2P)

發布/訂閱模型(pub/sub)

p2p模型,消息會向隊列一樣,消費掉的消息會從隊列中移除,一個消息只能被某個消費者消費,是點到點的消息傳輸.

pub/sub模型,消息會保存在topic(主題)容器中,一旦生產了新的消息,所有訂閱相同topic的消費者都會收到消息.

kafka 都支持以上兩種模型

Java消息服務(Java message service)JMS

一套API規范,kafka以及其他很多的消息引擎都支持了這套API規范,但是kafka沒有完全遵循這套規范

kafka優點

吞吐量/延時(batching思想,批處理)

消息持久化

負載均衡和故障轉移

伸縮性

怎么做到高吞吐/低延時?

然后kafka會持久化所有數據到磁盤，但本質上每次寫入操作其實都只是把數據寫入到操作系統的頁緩存(page cache)中，然后由操作系統自行決定什么時候把頁緩存中的數據寫回磁盤上。3個優勢

操作系統頁緩存是在內存中分配的,所以消息寫入的速度非?？?/p>

kafka不必和底層的文件系統打交道,所有煩瑣的I/O操作都jiaoyou操作系統來處理

kafka寫入操作采用追加寫入(append)的方式,避免了磁盤隨機寫操作

磁盤順序訪問速度和內存隨機訪問速度差不多一樣快

kafka寫入/讀取消息都是先訪問操作系統頁緩存,如果命中,則把消息直接發送到網絡的socket上.

上面的過程是使用了Linux的sendfile系統調用做到的,而這種技術就是使用零拷貝技術(Zero Copy)

下面是傳統的Linux數據傳輸

下面是使用了零拷貝,使用零拷貝節省了內核緩沖區與用戶態應用程序緩沖區之間的數據拷貝,同時利用直接存儲器訪問技術(DMA)執行I/O操作,因此也避免了OS內核緩沖區的數據拷貝

總結一下:

訪問消息大量使用操作系統頁緩存,內存操作速度快且命中率高

kafka不直接參與物理I/O操作,而是交給操作系統執行

持久化消息采用追加寫入方式,摒棄緩慢磁盤的隨機訪問操作

網絡消息發送使用sendfile的技術加快網絡傳輸的效率

為什么要持久化消息?

解耦消息發送與消息消費

實現靈活消息處理(消息重演)

kafka所有數據都會立即寫入文件系統的持久化日志,之后kafka服務器才會返回結果通知他們消息已經被成功寫入,保證了實時保存數據

(load-balancing)負載均衡 (fail-over)故障轉移

負載均衡

分區leader選舉

故障轉移

心跳機制

會話機制

伸縮性

kafka的狀態統一交由zookeeper管理,擴展kafka集群只需要增加新的kafka服務器即可

kafka架構圖

kafka名詞

消息

消息的格式:

key: 消息建,對于消息做分區(partition)時使用,即決定消息存放在那個topic的哪個partition下

value: 消息體,保存實際的數據

timestamp: 消息發送時間戳

屬性字段: 目前共一個字節(8位),目前用了3位,用于保存數據的壓縮的類型.

topic partition

topic 主題

partition 分區

邏輯概念,代表一類消息,通常用來劃分業務,一個topic由多個partition組成

offset

通過上邊的topic partition offset 可以查詢到唯一對應的消息

replica

replica partition的副本,唯一目的就是防止數據丟失

副本分兩類: leader replica 領導者副本 和 follower replica 追隨者副本

leader follower

leader副本負責提供服務給客戶端,而follower副本不提供服務給客戶端,follower 負責從leader中獲取數據,一旦leader副本所在的broker宕機了,kafka會從剩余的follower中選舉一個leader副本出來繼續給客戶端提供服務

ISR

全稱: in-sync replica,與 leader replica 保持同步的 replica的集合

kafka 使用場景

消息傳輸

日志行為追蹤

審計數據收集

日志收集

event source

流失處理

producer 生產者工作流程

版本:1.0.0

集群環境規劃

磁盤

追求性價比的可以考慮使用JOBD(just bunch of disks:一堆普通硬盤)

使用機械硬盤(HDD)可以滿足kafka集群的使用,ssd更好

kafka需要多大的磁盤容量?

可以從以下幾點考慮容量規劃:

新增消息數

消息留存時間

平均消息大小

副本數

是否啟用壓縮

內存

盡可能的分配更多內存給操作系統的page cache

不要為broker設置過大的堆內存,最好不要超過6GB

page cache 大小至少大于一個日志段的大小

CPU

使用多核系統,CPU核數最好大于8

帶寬

總結

以上是生活随笔為你收集整理的java 状态迁移图_kafka 实战笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。