最近我們的 Pulsar 存儲有很長一段時(shí)間數(shù)據(jù)一直得不到回收，但消息確實(shí)已經(jīng)是 ACK 了，理論上應(yīng)該是會被回收的，隨著時(shí)間流逝不但沒回收還一直再漲，最后在沒找到原因的情況下就只有一直不停的擴(kuò)容。

最后磁盤是得到了回收，過程先不表，之后再討論。

為了防止類似的問題再次發(fā)生，我們希望可以監(jiān)控到磁盤維度，能夠列出各個(gè)日志文件的大小以及創(chuàng)建時(shí)間。

這時(shí)就需要對 Pulsar 的存儲模型有一定的了解，也就有了這篇文章。

圖片

講到 Pulsar 的存儲模型，本質(zhì)上就是 Bookkeeper 的存儲模型。

Pulsar 所有的消息讀寫都是通過 Bookkeeper 實(shí)現(xiàn)的。

Bookkeeper 是一個(gè)可擴(kuò)展、可容錯、低延遲的日志存儲數(shù)據(jù)庫，基于 Append Only 模型。（數(shù)據(jù)只能追加不能修改）

圖片

這里我利用 Pulsar 和 Bookkeeper 的 Admin API 列出了 Broker 和 BK 中 Ledger 分別占用的磁盤空間。

關(guān)于這個(gè)如何獲取和計(jì)算的，后續(xù)也準(zhǔn)備提交給社區(qū)。

背景

但和我們實(shí)際 kubernetes 中的磁盤占用量依然對不上，所以就想看看在 BK 中實(shí)際的存儲日志和 Ledger 到底差在哪里。

知道 Ledger 就可以通過 Ledger 的元數(shù)據(jù)中找到對應(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é)果可以看出，落到具體的磁盤上只有一個(gè)文件名稱，是無法知道具體和哪些 Ledger 進(jìn)行關(guān)聯(lián)的，也就無法知道具體的 topic 了。

此時(shí)只能大膽假設(shè)，應(yīng)該每個(gè)文件和具體的消息 ID 有一個(gè)映射關(guān)系，也就是索引。所以需要搞清楚這個(gè)索引是如何運(yùn)行的。

存儲模型

圖片

我查閱了一些網(wǎng)上的文章和源碼大概梳理了一個(gè)存儲流程：

1. BK 收到寫入請求，數(shù)據(jù)會異步寫入到 Journal/Entrylog
2. Journal 直接順序?qū)懭?，并且會快速清除已?jīng)寫入的數(shù)據(jù)，所以需要的磁盤空間不多（所以從監(jiān)控中其實(shí)可以看到 Journal 的磁盤占有率是很低的）。
3. 考慮到會隨機(jī)讀消息，EntryLog 在寫入前進(jìn)行排序，保證落盤的數(shù)據(jù)中同一個(gè) Ledger 的數(shù)據(jù)盡量挨在一起，充分利用 PageCache.
4. 最終數(shù)據(jù)的索引通過 LedgerId+EntryId 生成索引信息存放到 RockDB 中（Pulsar 的場景使用的是 DbLedgerStorage 實(shí)現(xiàn)）。
5. 讀取數(shù)據(jù)時(shí)先從獲取索引，然后再從磁盤讀取數(shù)據(jù)。
6. 利用 Journal 和 EntryLog 實(shí)現(xiàn)消息的讀寫分離。

簡單來說 BK 在存儲數(shù)據(jù)的時(shí)候會進(jìn)行雙寫，Journal 目錄用于存放寫的數(shù)據(jù)，對消息順序沒有要求，寫完后就可以清除了。

而 Entry 目錄主要用于后續(xù)消費(fèi)消息進(jìn)行讀取使用，大部分場景都是順序讀，畢竟我們消費(fèi)消息的時(shí)候很少會回溯，所以需要充分利用磁盤的 PageCache，將順序的消息盡量的存儲在一起。

同一個(gè)日志文件中可能會存放多個(gè) Ledger 的消息，這些數(shù)據(jù)如果不排序直接寫入就會導(dǎo)致亂序，而消費(fèi)時(shí)大概率是順序的，但具體到磁盤的表現(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

圖片

每次在寫入和讀取數(shù)據(jù)的時(shí)候都需要通過消息 ID 也就是 ledgerId 和 entryId 來獲取索引信息。

也印證了之前索引的猜測。

所以借助于 BK 讀寫分離的特性，我們還可以單獨(dú)優(yōu)化存儲。

比如寫入 Journal 的磁盤因?yàn)槭琼樞驅(qū)懭耄约幢闶瞧胀ǖ?nbsp;HDD 硬盤速度也很快。

大部分場景下都是讀大于寫，所以我們可以單獨(dú)為 Ledger 分配高性能 SSD 磁盤，按需使用。

因?yàn)樵谧畹讓拥娜罩疚募袩o法直接通過 ledgerId 得知占用磁盤的大小，所以我們實(shí)際的磁盤占用率對不上的問題依然沒有得到解決，這個(gè)問題我還會持續(xù)跟進(jìn)，有新的進(jìn)展再繼續(xù)同步。