層次化存儲-特性介紹:

https://www.alluxio.org/docs/1.6/cn/Tiered-Storage-on-Alluxio.html

引入分層存儲后，Alluxio管理的數據塊不只在內存中，可存放于任何可用的存儲層。Alluxio使用分配策略和回收策略管理塊的存放和移動。Alluxio根據I/O性能的高低從上到下配置存儲層。因此，這種配置策略決定了最頂層存儲是MEM，然后是SSD，最后是HDD。

可以配置多個存儲目錄,不同的存儲介質

一個存儲層至少有一個存儲目錄。目錄是Alluxio數據塊存放的文件路徑。Alluxio支持單個存儲層包含多個目錄的配置，允許一個存儲層有多個掛載點或存儲設備。舉例而言，如果Alluxio worker上有5個SSD設備，可以配置Alluxio在SSD層同時使用這5個SSD設備。詳細配置請參考下面。分配策略決定數據塊文件存放的目錄。

寫數據

用戶寫入新數據塊時默認寫在頂層存儲。如果頂層沒有足夠的空間存放數據塊，回收策略會被觸發(fā)并釋放空間給新數據塊。如果頂層沒有足夠的可釋放空間，那么寫操作會失敗。如果文件大小超出了頂層空間，寫操作也會失敗。 用戶還可以通過配置項設置指定寫數據默認的層級。 從ReadType.CACHE或ReadType.CACHE_PROMOTE讀數據會導致數據被寫到Alluxio中。這種情況下，數據被默認寫到頂層。 最后，通過load命令可將數據寫到Alluxio中。這種情況，數據也會被寫到頂層。

讀數據

讀取分層存儲的數據塊和標準Alluxio類似。如果數據已經在Alluxio中，Alluxio從存儲位置讀取數據塊。如果Alluxio配置了多層存儲，數據塊不一定是從頂層讀取，因為可能被透明地移到下層存儲中。 讀取策略為ReadType.CACHE_PROMOTE時，Alluxio會確保數據在讀取前先被移動到頂層存儲中。通過顯式的將熱數據移到最高層,該策略也可以用于數據塊的管理。

固定文件

?

用戶可以通過固定(pin)和取消固定(unpin)來固定和移動該文件。文件被固定時，數據塊不會從Alluxio的存儲空間中移出。同時用戶可以將固定文件的數據塊移到頂層存儲。

分配策略

Alluxio使用分配策略選擇新數據塊的寫入位置。Alluxio定義了分配策略的框架，也內置了幾種分配策略。以下是Alluxio已實現的分配策略：

• 貪心分配策略 分配新數據塊到首個有足夠空間的存儲目錄。
• 最大剩余空間分配策略 分配數據塊到有最大剩余空間的存儲目錄。
• 輪詢調度分配策略 分配數據塊到有空間的最高存儲層，存儲目錄通過輪詢調度選出。

將來會有更多的分配策略可供選擇。由于Alluxio支持自定義分配策略。你可以為自己的應用開發(fā)合適的分配策略。

回收策略

Alluxio使用回收策略決定當空間需要釋放時，哪些數據塊被移到低存儲層。Alluxio支持自定義回收策略，已有的實現包括：

• 貪心回收策略 移出任意的塊直到釋放出所需大小的空間。
• LRU回收策略 移出最近最少使用的數據塊直到釋放出所需大小的空間。
• LRFU回收策略 基于權重分配的最近最少使用和最不經常使用策略移出數據塊。如果權重完全偏向最近最少使用,LRFU回收策略退化為LRU回收策略。
• 部分LRU回收策略 基于最近最少使用移出，但是選擇有最大剩余空間的存儲目錄(StorageDir)，只從該目錄移出數據塊。

將來會有更多的回收策略可供選擇。由于Alluxio支持自定義回收策略。你也可以為自己的應用開發(fā)合適的回收策略。 使用同步移出時，推薦使用較小的塊大小配置（64MB左右），以降低塊移出的延遲。使用空間預留器時，塊大小不會影響移出延遲。

層次化存儲-架構位置

層次化存儲是作為分布式緩存的最為核心的特性,加速讀取/寫入

層次化存儲也是worker組件最重要的功能,同時支持橫向擴展

?

層次化存儲-代碼解析

接上文https://www.cnblogs.com/victor2302/p/10491974.html,我們講到了BlockWorker接口

該接口的實現實現類:DefaultBlockWorker

DefaultBlockWorker

主要負責幾種功能:

• PinListSync,定時獲取pinned列表
• BlockMasterSync周期性的工作,例如:與master的心跳交互
• 報告計量相關指標至master
• 所有塊相關存儲操作的邏輯

成員變量如下: /** Runnable responsible for heartbeating and registration with master. */ 和master節(jié)點的心跳任務 private BlockMasterSync mBlockMasterSync;/** Runnable responsible for fetching pinlist from master. */ 獲取master pin列表的任務 private PinListSync mPinListSync;/** Runnable responsible for clean up potential zombie sessions. */ private SessionCleaner mSessionCleaner;/** Client for all block master communication. */ 與block master通訊 private final BlockMasterClient mBlockMasterClient; /*** Block master clients. commitBlock is the only reason to keep a pool of block master clients* on each worker. We should either improve our RPC model in the master or get rid of the* necessity to call commitBlock in the workers.*/ private final BlockMasterClientPool mBlockMasterClientPool;/** Client for all file system master communication. */ 與file system交互的客戶端 private final FileSystemMasterClient mFileSystemMasterClient;/** Block store delta reporter for master heartbeat. */ 報告者 private BlockHeartbeatReporter mHeartbeatReporter; /** Metrics reporter that listens on block events and increases metrics counters. */ 報告者 private BlockMetricsReporter mMetricsReporter; /** Session metadata, used to keep track of session heartbeats. */ private Sessions mSessions; /** Block Store manager. */ mBlockStore是TieredBlockStore，為多級存儲block存儲管理器 private BlockStore mBlockStore; private WorkerNetAddress mAddress;/** The under file system block store. */ ufs管理器 private final UnderFileSystemBlockStore mUnderFileSystemBlockStore;/*** The worker ID for this worker. This is initialized in {@link #start(WorkerNetAddress)} and may* be updated by the block sync thread if the master requests re-registration.*/ private AtomicReference<Long> mWorkerId;

?

涉及到交互的方法	代碼	注釋	?
commitBlock	blockMasterClient.commitBlock	提交bolock	?
start	mBlockMasterClient.getId(address)	獲取workerId	?
?	?	?	?
心跳類方法	?代碼	?注釋	?
PinListSync	Set<Long> pinList = mMasterClient.getPinList(); mBlockWorker.updatePinList(pinList);	更新本地的pin列表	?
SessionCleaner	for (long session : mSessions.getTimedOutSessions()) { mSessions.removeSession(session); for (SessionCleanable sc : mSessionCleanables) { sc.cleanupSession(session); } }	清除session	?
SpaceReserver	太多	各存儲層空間檢查	?
BlockMasterSync	cmdFromMaster = mMasterClient.heartbeat(mWorkerId.get(), storeMeta.getUsedBytesOnTiers(), blockReport.getRemovedBlocks(), blockReport.getAddedBlocks(), metrics); handleMasterCommand(cmdFromMaster);	向blockmaster發(fā)送心跳，并處理返回的消息	?

?

TieredBlockStore

該類負責分層存儲邏輯,與不同介質的緩存存儲模塊進行交互

維護讀寫鎖,保證block操作的線程安全

該類擁有前文提到過得申請和驅逐策略以及 pinned列表

備注:申請和驅逐策略,就是關于不同介質的緩存存儲模塊如何進行分配以及管理的策略

//申請策略接口 private final Allocator mAllocator; //驅逐策略接口 private final Evictor mEvictor;private final Set<Long> mPinnedInodes = new HashSet<>();

?

轉載于:https://www.cnblogs.com/victor2302/p/10506408.html

總結

以上是生活随笔為你收集整理的alluxio源码解析-层次化存储(4)的全部內容，希望文章能夠幫你解決所遇到的問題。

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