1. RocketMQ的文件體系介紹
?RocketMQ的消息存儲(chǔ)是RocketMQ中最為復(fù)雜和最為重要的一部分矗蕊。RocketMQ底層有5類文件值桩，對(duì)于不同類型的文件在存儲(chǔ)邏輯層采用不同的類提供服務(wù)掸读，其中三類大文件和兩類小文件：
- Index文件由
IndexService類提供服務(wù)（大文件） - consumequeue文件由
Consumequeue類提供服務(wù)（大文件） - commitlog文件由
CommitLog類提供服務(wù)（大文件） - checkpoint文件由
StoreCheckPoint類提供訪問服務(wù)（小文件） - config目錄下面的配置文件（以json格式存儲(chǔ)）由
ConfigMananger類提供訪問服務(wù)（小文件）
2. CommitLog糜颠，ConsumeQueue熊榛， IndexFile 介紹
2.1 CommitLog
?消息主體以及元數(shù)據(jù)的存儲(chǔ)主體种樱，存儲(chǔ)Producer端寫入的消息主體內(nèi)容,消息內(nèi)容不是定長(zhǎng)的蒙袍。單個(gè)文件大小默認(rèn)1G ，文件名長(zhǎng)度為20位嫩挤，左邊補(bǔ)零害幅，剩余為起始偏移量，比如00000000000000000000代表了第一個(gè)文件岂昭，起始偏移量為0以现，文件大小為1G=1073741824；當(dāng)?shù)谝粋€(gè)文件寫滿了约啊，第二個(gè)文件為00000000001073741824邑遏，起始偏移量為1073741824，以此類推恰矩。消息主要是順序?qū)懭肴罩疚募?/strong>记盒，當(dāng)文件滿了，寫入下一個(gè)文件外傅；
2.2 ConsumeQueue
?消息消費(fèi)隊(duì)列纪吮，引入的目的主要是提高消息消費(fèi)的性能，由于RocketMQ是基于主題topic的訂閱模式萎胰，消息消費(fèi)是針對(duì)主題進(jìn)行的碾盟，如果要遍歷commitlog文件中根據(jù)topic檢索消息是非常低效的。
?Consumer即可根據(jù)ConsumeQueue來查找待消費(fèi)的消息技竟。其中冰肴，ConsumeQueue（邏輯消費(fèi)隊(duì)列）作為消費(fèi)消息的索引，保存了指定Topic下的隊(duì)列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的HashCode值嚼沿。
?consumequeue文件可以看成是基于topic的commitlog索引文件估盘，故consumequeue文件夾的組織方式如下：topic/queue/file三層組織結(jié)構(gòu)，具體存儲(chǔ)路徑為：$HOME/store/consumequeue/{topic}/{queueId}/{fileName}骡尽。
?同樣consumequeue文件采取定長(zhǎng)設(shè)計(jì)遣妥，每一個(gè)條目共20個(gè)字節(jié)，分別為8字節(jié)的commitlog物理偏移量攀细、4字節(jié)的消息長(zhǎng)度箫踩、8字節(jié)tag hashcode，單個(gè)文件由30W個(gè)條目組成谭贪，可以像數(shù)組一樣隨機(jī)訪問每一個(gè)條目境钟，每個(gè)ConsumeQueue文件大小約5.72M；
2.3 IndexFile
?IndexFile（索引文件）提供了一種可以通過key或時(shí)間區(qū)間來查詢消息的方法俭识。Index文件的存儲(chǔ)位置是：HOME\store\index{fileName}慨削，文件名fileName是以創(chuàng)建時(shí)的時(shí)間戳命名的，固定的單個(gè)IndexFile文件大小約為400M套媚，一個(gè)IndexFile可以保存 2000W個(gè)索引缚态，IndexFile的底層存儲(chǔ)設(shè)計(jì)為在文件系統(tǒng)中實(shí)現(xiàn)HashMap結(jié)構(gòu)，故rocketmq的索引文件其底層實(shí)現(xiàn)為hash索引堤瘤。
2.4 存儲(chǔ)方式
RocketMQ采用的是混合型的存儲(chǔ)結(jié)構(gòu)玫芦，即為Broker單個(gè)實(shí)例下所有的隊(duì)列共用一個(gè)日志數(shù)據(jù)文件（即為CommitLog）來存儲(chǔ)。RocketMQ的混合型存儲(chǔ)結(jié)構(gòu)(多個(gè)Topic的消息實(shí)體內(nèi)容都存儲(chǔ)于一個(gè)CommitLog中)針對(duì)Producer和Consumer分別采用了數(shù)據(jù)和索引部分相分離的存儲(chǔ)結(jié)構(gòu)本辐，Producer發(fā)送消息至Broker端桥帆，然后Broker端使用同步或者異步的方式對(duì)消息刷盤持久化，保存至CommitLog中慎皱。只要消息被刷盤持久化至磁盤文件CommitLog中老虫，那么Producer發(fā)送的消息就不會(huì)丟失。
3. 頁緩存與內(nèi)存映射
3.1 頁緩存pageCache
?頁緩存（PageCache)是OS對(duì)文件的緩存茫多，用于加速對(duì)文件的讀寫祈匙。一般來說，程序?qū)ξ募M(jìn)行順序讀寫的速度幾乎接近于內(nèi)存的讀寫速度地梨，主要原因就是由于OS使用PageCache機(jī)制對(duì)讀寫訪問操作進(jìn)行了性能優(yōu)化，將一部分的內(nèi)存用作PageCache缔恳。對(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ù)讀取赖钞。
3.2 內(nèi)存映射
?RocketMQ主要通過MappedByteBuffer對(duì)文件進(jìn)行讀寫操作腰素。其中，利用了NIO中的FileChannel模型將磁盤上的物理文件直接映射到用戶態(tài)的內(nèi)存地址中（這種Mmap的方式減少了傳統(tǒng)IO將磁盤文件數(shù)據(jù)在操作系統(tǒng)內(nèi)核地址空間的緩沖區(qū)和用戶應(yīng)用程序地址空間的緩沖區(qū)之間來回進(jìn)行拷貝的性能開銷）雪营，將對(duì)文件的操作轉(zhuǎn)化為直接對(duì)內(nèi)存地址進(jìn)行操作弓千，從而極大地提高了文件的讀寫效率（正因?yàn)樾枰褂脙?nèi)存映射機(jī)制，故RocketMQ的文件存儲(chǔ)都使用定長(zhǎng)結(jié)構(gòu)來存儲(chǔ)献起，方便一次將整個(gè)文件映射至內(nèi)存）洋访。
