架構(gòu)
https://github.com/apache/rocketmq/blob/master/docs/cn/architecture.md rocketmq/docs/cn at master · apache/rocketmq · GitHub
RocketMQ & Kafka 對(duì)比
1. 文件結(jié)構(gòu)
首先都是順序?qū)懭耄贿^ RocketMQ 是把消息都存一個(gè)文件中也殖，而 Kafka 是一個(gè)分區(qū)一個(gè)文件土思。 每個(gè)分區(qū)一個(gè)文件在遷移或者數(shù)據(jù)復(fù)制層面上來說更加得靈活。但是分區(qū)多了的話，寫入需要頻繁的在多個(gè)文件之間來回切換浪漠，對(duì)于每個(gè)文件來說是順序?qū)懭氲纳孪埃菑娜挚雌鋵?shí)算隨機(jī)寫入，并且讀取的時(shí)候也是一樣址愿，算隨機(jī)讀该镣。而就一個(gè)文件的 RocketMQ 就沒這個(gè)問題。 消息存儲(chǔ)整體架構(gòu)：
[圖片上傳失敗...(image-8002c1-1677753939472)]
| kafka | rocket | |
|---|---|---|
| 概念區(qū)分 | Topic : 主題响谓，可以理解為一個(gè)隊(duì)列 损合，只是一個(gè)邏輯概念，真正存在的是分區(qū)娘纷。 | |
| 一個(gè)topic多個(gè)Partition（分區(qū)） | ||
| Partation: 隊(duì)列Topic的分區(qū)嫁审，一個(gè)Topic可以分為多個(gè)分區(qū)，用于高并發(fā)場景的負(fù)載功能赖晶； | 一個(gè)topic多個(gè)Queue（分片） | |
| Queue是Topic在一個(gè)Broker上的分片等分為指定份數(shù)后的其中一份律适，是負(fù)載均衡過程中資源分配的基本單元。 | ||
| 文件存儲(chǔ) | 以 Partition 為單位遏插，每個(gè) Partition 包含一組消息文件（Segment file）和一組索引文件（Index） | 只有一個(gè)CommitLog文件 |
| 以 Broker 為單位捂贿，存儲(chǔ)消息文件和索引文件，每個(gè) Broker 只有一組消息文件胳嘲，它把在這個(gè) Broker 上的所有主題的消息都存在這一組消息文件中厂僧。 | ||
| 索引文件 | ||
| ConsumerQueue消息消費(fèi)隊(duì)列索引文件：是按照主題和隊(duì)列分別建立的，每個(gè)隊(duì)列對(duì)應(yīng)一組索引文件 | ||
| 存儲(chǔ)路徑為：$HOME/store/consumequeue/{topic}/{queueId}/{fileName} | ||
| IndexFile索引文件：一種可以通過key或時(shí)間區(qū)間來查詢消息的方法 | ||
| 存儲(chǔ)位置是：HOME\store\index{fileName} | ||
| “按照Message Key查詢消息”了牛，主要是基于RocketMQ的IndexFile索引文件來實(shí)現(xiàn)的颜屠。RocketMQ的索引文件邏輯結(jié)構(gòu)，類似JDK中HashMap的實(shí)現(xiàn)鹰祸。 | ||
| 索引文件 | 稀疏索引甫窟，為了節(jié)省存儲(chǔ)空間，它不會(huì)為每一條消息都創(chuàng)建索引福荸，而是每隔幾條消息創(chuàng)建一條索引蕴坪。 | RocketMQ 中的索引是定長稠密索引，它為每一條消息都建立索引敬锐，每個(gè)索引的長度（注意不是消息長度）是固定的 20 個(gè)字節(jié) |
| 文件存儲(chǔ)的優(yōu)缺點(diǎn) | Kafka 以分區(qū)為單位背传，粒度更細(xì)，優(yōu)點(diǎn)是更加靈活台夺，很容易進(jìn)行數(shù)據(jù)遷移和擴(kuò)容径玖。 | |
| RocketMQ 以 Broker 為單位，較粗的粒度犧牲了靈活性颤介，帶來的好處是梳星，在寫入的時(shí)候赞赖，同時(shí)寫入的文件更少，有更好的批量（不同主題和分區(qū)的數(shù)據(jù)可以組成一批一起寫入）冤灾，更多的順序?qū)懭肭坝颍绕涫窃?Broker 上有很多主題和分區(qū)的情況下，有更好的寫入性能韵吨。 |
2. 零拷貝優(yōu)化
從發(fā)送消息來說 RocketMQ 用到了 mmap + write 的方式匿垄，并且通過預(yù)熱來減少大文件 mmap 因?yàn)槿表撝袛喈a(chǎn)生的性能問題。而 Kafka 則用了 sendfile归粉，相對(duì)而言我覺得 kafka 發(fā)送的效率更高椿疗，因?yàn)樯倭艘淮雾摼彺娴?SocketBuffer 中的拷貝。并且 swap 問題也可以通過系統(tǒng)參數(shù)來設(shè)置糠悼。
| 中間件 | 實(shí)現(xiàn)方式 | 具體 |
|---|---|---|
| RocketMQ | mmap+write | 發(fā)送和消費(fèi)消息時(shí)（針對(duì)CommitLog届榄、ConsumeQueue）使用 mmap + write |
| Kafka | mmap | Producer生產(chǎn)的數(shù)據(jù)持久化到broker，采用mmap文件映射倔喂，實(shí)現(xiàn)順序的快速寫入 |
| sendfile | Customer從broker讀取數(shù)據(jù)铝条，采用sendfile，將磁盤文件讀到OS內(nèi)核緩沖區(qū)后滴劲，直接轉(zhuǎn)到socket buffer進(jìn)行網(wǎng)絡(luò)傳輸 |
kafka 為什么快攻晒？為什么rocketmq不用sendfile技術(shù)？
性能：Kafka吞吐量更高班挖，單機(jī)百萬/秒；RocketMQ單機(jī)10萬/秒芯砸。
rocketmq使用了mmap萧芙，沒有使用sendfile，但為什么rocketmq不使用sendfile假丧， 因?yàn)閞ocketmq可以處理消息的順序双揪，消息的過濾，而Kafka不能有這些功能包帚。 kafka中渔期，sendfile壓根就沒有到達(dá)數(shù)據(jù)應(yīng)用層，數(shù)據(jù)只在內(nèi)核中中渴邦，不會(huì)進(jìn)入用戶進(jìn)程的疯趟，也就是不會(huì)進(jìn)入java程序，無法對(duì)數(shù)據(jù)進(jìn)行操作（修改谋梭、排序）信峻。
其中：MMap三次拷貝 sendfile兩次拷貝，多出的一次是CPU拷貝 從內(nèi)核拷貝到用戶進(jìn)程瓮床。
內(nèi)存映射
總結(jié)：
- java nio實(shí)現(xiàn)：FileChannel.transferTo
執(zhí)行順序：sendfile-> mmap->傳統(tǒng)的 I/O 方式
- sendfile只有兩次DMA copy盹舞，MMAP有兩次DMA copy,外加一次CPU copy
MMAP（內(nèi)存映射）
MMAP（內(nèi)存映射）：將一個(gè)文件或者其它對(duì)象映射到進(jìn)程的地址空間产镐，實(shí)現(xiàn)文件磁盤地址和進(jìn)程虛擬地址空間中一段虛擬地址的一一對(duì)映關(guān)系。簡單來說踢步，就是實(shí)現(xiàn)磁盤文件到虛擬內(nèi)存的直接傳輸癣亚，減少了內(nèi)核態(tài)到用戶態(tài)的數(shù)據(jù)拷貝。 另外這里給大家說明白的一點(diǎn)是获印，這個(gè) mmap 技術(shù)在進(jìn)行文件映射的時(shí)候逃糟，一般有大小限制，在 1.5GB~2GB 之間蓬豁。所以 RocketMQ 才讓CommitLog單個(gè)文件在1GB绰咽，ConsumeQueue文件在5.72MB，不會(huì)太大地粪。 [圖片上傳失敗...(image-52fb1d-1677753939472)]
MMAP有兩次DMA copy,外加一次CPU copy
DMA 輔助的 sendfile
sendfile只有兩次DMA copy取募， cup拷貝不再拷貝數(shù)據(jù)，而是拷貝緩沖區(qū)描述符蟆技。實(shí)現(xiàn)真正意義上的零拷貝玩敏，在 Java 中FileChannal.transferTo()底層用的就是sendfile。 DMA 輔助的 sendfile缺點(diǎn)是：只適用于將數(shù)據(jù)從文件拷貝到套接字上质礼。
頁緩存
PageCache（頁緩存）：文件系統(tǒng)緩存旺聚，加速文件的讀寫速度。我們都知道磁盤 IO 和內(nèi)存 IO 的速度可是相差了好幾個(gè)數(shù)量級(jí)眶蕉。加入頁緩存的目的就是為了使程序?qū)ξ募M(jìn)行順序讀寫的速度接近于內(nèi)存的讀寫速度砰粹。所以簡單來說，對(duì)于數(shù)據(jù)的寫入造挽，OS 會(huì)先寫入至 Cache 內(nèi)碱璃，隨后通過異步的方式由 pdflush 內(nèi)核線程將 Cache 內(nèi)的數(shù)據(jù)刷盤至物理磁盤上。對(duì)于數(shù)據(jù)的讀取饭入，如果一次讀取文件時(shí)出現(xiàn)未命中 PageCache 的情況嵌器，OS 從物理磁盤上訪問讀取文件的同時(shí)，會(huì)順序?qū)ζ渌噜弶K的數(shù)據(jù)文件進(jìn)行預(yù)讀取谐丢。
首先了解一下頁緩存爽航，頁緩存是操作系統(tǒng)用來作為磁盤的一種緩存，減少磁盤的I/O操作乾忱。 在寫入磁盤的時(shí)候其實(shí)是寫入頁緩存中讥珍，使得對(duì)磁盤的寫入變成對(duì)內(nèi)存的寫入。寫入的頁變成臟頁饭耳，然后操作系統(tǒng)會(huì)在合適的時(shí)候?qū)⑴K頁寫入磁盤中串述。 在讀取的時(shí)候如果頁緩存命中則直接返回，如果頁緩存 miss 則產(chǎn)生缺頁中斷寞肖，從磁盤加載數(shù)據(jù)至頁緩存中纲酗，然后返回?cái)?shù)據(jù)衰腌。 頁緩存存在數(shù)據(jù)丟失的風(fēng)險(xiǎn)，例如機(jī)器突然斷電觅赊，那些還未刷盤的臟頁就丟失了右蕊。不過可以調(diào)用 fsync 強(qiáng)制刷盤，但是這樣對(duì)于性能的損耗較大吮螺。因此一般建議通過多副本機(jī)制來保證消息的可靠饶囚，而不是同步刷盤。
引用
https://baijiahao.baidu.com/s?id=1673444160125100503&wfr=spider&for=pc
