最近我們的 Pulsar 存儲(chǔ)有很長(zhǎng)一段時(shí)間數(shù)據(jù)一直得不到回收,但消息確實(shí)已經(jīng)是 ACK 了,理論上應(yīng)該是會(huì)被回收的,隨著時(shí)間流逝不但沒(méi)回收還一直再漲,最后在沒(méi)找到原因的情況下就只有一直不停的擴(kuò)容。
最后磁盤(pán)是得到了回收,過(guò)程先不表,之后再討論。
為了防止類(lèi)似的問(wèn)題再次發(fā)生,我們希望可以監(jiān)控到磁盤(pán)維度,能夠列出各個(gè)日志文件的大小以及創(chuàng)建時(shí)間。
這時(shí)就需要對(duì) Pulsar 的存儲(chǔ)模型有一定的了解,也就有了這篇文章。
圖片
這里我利用 Pulsar 和 Bookkeeper 的 Admin API 列出了 Broker 和 BK 中 Ledger 分別占用的磁盤(pán)空間。
關(guān)于這個(gè)如何獲取和計(jì)算的,后續(xù)也準(zhǔn)備提交給社區(qū)。
但和我們實(shí)際 kubernetes 中的磁盤(pán)占用量依然對(duì)不上,所以就想看看在 BK 中實(shí)際的存儲(chǔ)日志和 Ledger 到底差在哪里。
知道 Ledger 就可以通過(guò) Ledger 的元數(shù)據(jù)中找到對(duì)應(yīng)的 topic,從而判斷哪些 topic 的數(shù)據(jù)導(dǎo)致統(tǒng)計(jì)不能匹配。
Bookkeeper 有提提供一個(gè)Admin API 可以返回當(dāng)前 BK 所使用了哪些日志文件的接口:https://bookkeeper.apache.org/docs/admin/http#endpoint-apiv1bookielist_disk_filefile_typetype
圖片
從返回的結(jié)果可以看出,落到具體的磁盤(pán)上只有一個(gè)文件名稱(chēng),是無(wú)法知道具體和哪些 Ledger 進(jìn)行關(guān)聯(lián)的,也就無(wú)法知道具體的 topic 了。
此時(shí)只能大膽假設(shè),應(yīng)該每個(gè)文件和具體的消息 ID 有一個(gè)映射關(guān)系,也就是索引。所以需要搞清楚這個(gè)索引是如何運(yùn)行的。
圖片
我查閱了一些網(wǎng)上的文章和源碼大概梳理了一個(gè)存儲(chǔ)流程:
簡(jiǎn)單來(lái)說(shuō) BK 在存儲(chǔ)數(shù)據(jù)的時(shí)候會(huì)進(jìn)行雙寫(xiě),Journal 目錄用于存放寫(xiě)的數(shù)據(jù),對(duì)消息順序沒(méi)有要求,寫(xiě)完后就可以清除了。
而 Entry 目錄主要用于后續(xù)消費(fèi)消息進(jìn)行讀取使用,大部分場(chǎng)景都是順序讀,畢竟我們消費(fèi)消息的時(shí)候很少會(huì)回溯,所以需要充分利用磁盤(pán)的 PageCache,將順序的消息盡量的存儲(chǔ)在一起。
同一個(gè)日志文件中可能會(huì)存放多個(gè) Ledger 的消息,這些數(shù)據(jù)如果不排序直接寫(xiě)入就會(huì)導(dǎo)致亂序,而消費(fèi)時(shí)大概率是順序的,但具體到磁盤(pán)的表現(xiàn)就是隨機(jī)讀了,這樣讀取效率較低。
所以我們使用 Helm 部署 Bookkeeper 的時(shí)候需要分別指定 journal 和 ledgers 的目錄
volumes: # use a persistent volume or emptyDir persistence: true journal: name: journal size: 20Gi local_storage: false multiVolumes: - name: journal0 size: 10Gi # storageClassName: existent-storage-class mountPath: /pulsar/data/bookkeeper/journal0 - name: journal1 size: 10Gi # storageClassName: existent-storage-class mountPath: /pulsar/data/bookkeeper/journal1 ledgers: name: ledgers size: 50Gi local_storage: false storageClassName: sc # storageClass: # ... useMultiVolumes: false multiVolumes: - name: ledgers0 size: 1000Gi # storageClassName: existent-storage-class mountPath: /pulsar/data/bookkeeper/ledgers0 - name: ledgers1 size: 1000Gi # storageClassName: existent-storage-class mountPath: /pulsar/data/bookkeeper/ledgers1
圖片
每次在寫(xiě)入和讀取數(shù)據(jù)的時(shí)候都需要通過(guò)消息 ID 也就是 ledgerId 和 entryId 來(lái)獲取索引信息。
也印證了之前索引的猜測(cè)。
所以借助于 BK 讀寫(xiě)分離的特性,我們還可以單獨(dú)優(yōu)化存儲(chǔ)。
比如寫(xiě)入 Journal 的磁盤(pán)因?yàn)槭琼樞驅(qū)懭?,所以即便是普通?nbsp;HDD 硬盤(pán)速度也很快。
大部分場(chǎng)景下都是讀大于寫(xiě),所以我們可以單獨(dú)為 Ledger 分配高性能 SSD 磁盤(pán),按需使用。
因?yàn)樵谧畹讓拥娜罩疚募袩o(wú)法直接通過(guò) ledgerId 得知占用磁盤(pán)的大小,所以我們實(shí)際的磁盤(pán)占用率對(duì)不上的問(wèn)題依然沒(méi)有得到解決,這個(gè)問(wèn)題我還會(huì)持續(xù)跟進(jìn),有新的進(jìn)展再繼續(xù)同步。
本文鏈接:http://www.www897cc.com/showinfo-26-62359-0.html白話(huà) Pulsar Bookkeeper 的存儲(chǔ)模型
聲明:本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。郵件:2376512515@qq.com
上一篇: 零基礎(chǔ)入門(mén)Python與MongoDB:輕松實(shí)現(xiàn)數(shù)據(jù)管理