[發明專利]一種分布式系統中的讀取方法及裝置

有效

• 申請號: 201610412855.4
• 申請日: 2016-06-13
• 公開（公告）號: CN107491455B
• 公開（公告）日: 2020-11-20
• 發明（設計）人: 劉善陽
• 申請（專利權）人: 阿里巴巴集團控股有限公司
• 主分類號: G06F16/182
• 分類號: G06F16/182;G06F16/13
• 代理公司: 北京安信方達知識產權代理有限公司 11262
• 代理人: 李紅爽;栗若木

一種分布式系統中的讀取方法及裝置；所述讀取方法包括：當收到用戶對于第一文件的讀請求后，向所述第一文件對應的存儲節點之一發送讀數據請求；當等待響應的時間長度達到或超過第一時間間隔時，向所述第一文件對應的另一存儲節點發送針對所述讀數據請求的冗余請求；其中，所述第一時間間隔是根據讀操作的性能指標而動態確定的。本申請能夠自適應調整針對讀數據請求的冗余請求的發送間隔。

技術領域

本發明涉及領域，尤其涉及一種分布式系統中的讀取方法及裝置。

背景技術

針對分布式系統中讀毛刺的優化，相關技術中提出了一種BackupRequest的策略。BackupRequest是在普通的讀流程中添加的冗余請求，在不要求單個請求的讀延時降低的基礎上，降低用戶感知的讀延時毛刺率。

以Google的谷歌文件系統(Google File System，GFS)為例來描述包含BackupRequest的讀取過程，谷歌文件系統具體結構如圖1所示：

客戶端(Client)庫：為分布式存儲系統的用戶提供各種接口；

塊服務器(Chunkserver)：作為數據管理模塊，具體管理用戶的數據；

主控端(Master)：作為命名空間管理模塊，管理分布式存儲系統的元(meta)數據。

在客戶端，主控端，塊服務器模式的分布式存儲系統中，用戶文件的所有元數據都存儲在主控端中。文件的數據以多副本的方式保存在不同的塊服務器中。

客戶端發送文件名稱(file name)和塊索引(Chunk index)到主控端，主控端返回塊句柄(Chunk handle)和塊位置(Chunk location)；客戶端發送塊句柄和字節范圍(byterange)到塊服務器，塊服務器返回塊數據(Chunk data)。塊服務器還向主控端上報塊服務器狀態(state)，主控端下發對于塊服務器的指令(Instructions to Chunkserver)給塊服務器。其中，主控端中文件命名空間包含(File namespace)；塊服務器使用Linux文件系統(file system)。其中，塊服務器返回給客戶端的塊數據是數據消息，客戶端發送給塊服務器的塊句柄和字節范圍、客戶端與主控端之間、主控端與塊服務器之間交互的均是控制消息。

帶有BackupRequest的讀流程如下：

101、客戶端接收到用戶的對文件F讀數據的請求；

102、客戶端向主控端請求文件F的數據所在塊的信息；

103、主控端將塊的多個副本的塊服務器的地址返回給客戶端；

104、客戶端向其中一個副本所在的塊服務器發起讀數據請求，并等待塊服務器返回結果，此時用戶后續的寫被阻塞；

105、如果步驟104的等待超過發送間隔T，客戶端會再向另一個副本所在的塊服務器發起讀數據請求，這個請求被稱作BackupRequest；

106、步驟104和步驟105中任何一個請求先成功，客戶端就會返回給用戶表示讀成功的消息。

用戶收到讀成功的結果后，如果繼續發起下一次讀，則回到上述的步驟101。

上述的BackupRequest方法用冗余讀的方法來實現讀毛刺率的降低。在冗余讀的方法中，有一個重要的參數決定了方法的性能和穩定性：冗余請求的發送間隔。發送間隔越短，對毛刺率的優化效果越好，但需要的額外的資源越多，相關技術中，BackupRequest方法中發送間隔設置定義成固定值，在前端壓力基本不變的場景可以正常工作，但在壓力變化明顯的場景下，固定的發送間隔的會有如下問題：

壓力小的場景發送間隔過大，因為沒有及時的發送冗余請求，所以無法得到更好的毛刺率優化效果；