這篇文章給大家介紹如何進(jìn)行NFS文件鎖一致性設(shè)計(jì)原理解析，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

10年積累的成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)制作后付款的網(wǎng)站建設(shè)流程，更有平潭免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

文件鎖

文件鎖是文件系統(tǒng)的最基本特性之一，應(yīng)用程序借助文件鎖可以控制其他應(yīng)用對文件的并發(fā)訪問。NFS作為類UNIX系統(tǒng)的標(biāo)準(zhǔn)網(wǎng)絡(luò)文件系統(tǒng)，在發(fā)展過程中逐步的原生地支持了文件鎖(從NFSv4開始)。NFS從上個(gè)世界80年代誕生至今，共發(fā)布了3個(gè)版本：NFSv2、NFSv3、NFSv4。NFSv4最大的變化是有“狀態(tài)”了。某些操作需要服務(wù)端維持相關(guān)狀態(tài)，如文件鎖，例如客戶端申請了文件鎖，服務(wù)端就需要維護(hù)該文件鎖的狀態(tài)，否則其他客戶端沖突的訪問就無法檢測。如果是NFSv3就需要NLM協(xié)助才能實(shí)現(xiàn)文件鎖功能，但是有的時(shí)候兩者配合不夠協(xié)調(diào)就會(huì)容易出錯(cuò)。而NFSv4設(shè)計(jì)成了一種有狀態(tài)的協(xié)議，自身就可以實(shí)現(xiàn)了文件鎖功能，也就不需要NLM協(xié)議了。

應(yīng)用接口

應(yīng)用程序可以通過fcntl()或flock()系統(tǒng)調(diào)用管理NFS文件鎖，下面NAS使用NFSv4掛載時(shí)獲取文件鎖的調(diào)用過程:

從上圖調(diào)用棧容易看出來，NFS文件鎖實(shí)現(xiàn)邏輯基本復(fù)用了VFS層設(shè)計(jì)和數(shù)據(jù)結(jié)構(gòu)，在通過RPC從Server成功獲取文件鎖后調(diào)用locks_lock_inode_wait()函數(shù)將獲得文件鎖交給到VFS層管理，關(guān)于VFS層文件鎖設(shè)計(jì)的相關(guān)資料比較多，在此就不再描述了。

EOS原理

文件鎖是典型的非冪等操作，文件鎖操作的重試和Failover會(huì)導(dǎo)致文件鎖狀態(tài)視圖在客戶端和服務(wù)端間的不一致。NFSv4借助SeqId機(jī)制設(shè)計(jì)了最多執(zhí)行一次的機(jī)制，具體方法如下：

針對每個(gè)open/lock狀態(tài)Client和Server同時(shí)獨(dú)立維護(hù)seqid，Client在發(fā)起會(huì)引起狀態(tài)變化的操作時(shí)(open/close/lock/unlock/release_lockowner)會(huì)將seqid加1，并作為參數(shù)發(fā)送給Server，假定Client發(fā)送的seqid為R，Server維護(hù)的seqid為L，則：
1) 若R == L +1，表示合法請求，正常處理之；
2) 若R == L，表示重試請求，Server將緩存的reply返回即可；
3) 其他情況均為非法請求，決絕訪問。
根據(jù)上述規(guī)則，Server可判斷操作是否為正常、重試或非法請求。

該方法能夠保證每個(gè)文件鎖操作在服務(wù)端最多執(zhí)行一次，解決了RPC重試帶來的重復(fù)執(zhí)行的問題，但是僅靠這一點(diǎn)是不夠的。比如LOCK操作發(fā)送后調(diào)用線程被信號(hào)中斷，此后服務(wù)端又成功接受并執(zhí)行了該LOCK操作，這樣服務(wù)端就記錄了客戶端持有了鎖，但客戶端中卻因?yàn)橹袛喽鴽]有維護(hù)這把鎖，客戶端和服務(wù)端間的鎖狀態(tài)視圖不一致就發(fā)生了。因此，客戶端還需配合處理異常場景，最終才能夠做到文件鎖視圖一致性。

異常處理

由上一節(jié)分析可知，客戶端需要配合處理異常場景才能夠保證文件視圖一致性，那么客戶端設(shè)計(jì)者主要做了哪些配合的設(shè)計(jì)呢？目前客戶端主要從SunRPC和NFS協(xié)議實(shí)現(xiàn)兩個(gè)維度相互配合解決該問題，下面會(huì)分別介紹這兩個(gè)維度的設(shè)計(jì)如何保證了文件鎖狀態(tài)視圖一致性。

SunRPC設(shè)計(jì)

SunRPC是Sun公司專門為遠(yuǎn)程過程調(diào)用設(shè)計(jì)的網(wǎng)絡(luò)通訊協(xié)議，這里從保障文件鎖視圖一致性的維度來了解一下SunRPC實(shí)現(xiàn)層面的設(shè)計(jì)理念：

1) 客戶端使用int32_t類型的xid標(biāo)識(shí)上層使用者發(fā)起的每個(gè)遠(yuǎn)程過程調(diào)用過程，每個(gè)遠(yuǎn)程過程調(diào)用的多次RPC重試使用相同的xid標(biāo)識(shí)，這樣就保障了多次RPC重試中任何一個(gè)返回就可以告知上層遠(yuǎn)程過程調(diào)用已經(jīng)成功，保證了服務(wù)端執(zhí)行遠(yuǎn)程過程調(diào)用執(zhí)行耗時(shí)較長時(shí)也能拿到結(jié)果，這一點(diǎn)和傳統(tǒng)的netty/mina/brpc等都需要每個(gè)RPC都要有獨(dú)立的xid/packetid不同；
2) 服務(wù)端設(shè)計(jì)了DRC(duplicate request cache)緩存最近執(zhí)行的RPC結(jié)果，接收到RPC時(shí)會(huì)首先通過xid檢索DRC緩存，若命中則表明RPC為重試操作，直接返回緩存的結(jié)果即可，這在一定程度上規(guī)避了RPC重試帶來的重復(fù)執(zhí)行的問題。為了避免xid復(fù)用導(dǎo)致DRC緩存返回非預(yù)期的結(jié)果，開發(fā)者通過下述設(shè)計(jì)進(jìn)一步有效地減少復(fù)用引起錯(cuò)誤的概率:
a) 客戶端建立新鏈接時(shí)初始xid采用隨機(jī)值:
b) 服務(wù)端DRC會(huì)額外記錄請求的校驗(yàn)信息，緩存命中時(shí)會(huì)同時(shí)校驗(yàn)這些信息；
3) 客戶端允許在獲得服務(wù)端相應(yīng)前無限重試，保證調(diào)用者能夠獲得服務(wù)端確定性的執(zhí)行結(jié)果，當(dāng)然這樣的策略會(huì)導(dǎo)致無響應(yīng)時(shí)調(diào)用者會(huì)一直hang；
4) NFS允許用戶在掛載時(shí)通過soft/hard參數(shù)指定SunRPC的重試策略，其中soft模式禁止超時(shí)后重試，hard模式則持續(xù)重試。當(dāng)用戶使用soft模式掛載時(shí)NFS實(shí)現(xiàn)不保證客戶端和服務(wù)端狀態(tài)視圖的一致性，在遇到遠(yuǎn)程過程調(diào)用返回超時(shí)要求應(yīng)用程序配合狀態(tài)的清理和恢復(fù)，比如關(guān)閉訪問出錯(cuò)的文件等，然而實(shí)踐中很少有應(yīng)用程序會(huì)配合，所以一般情況下NAS用戶都使用hard模式掛載；
總之，SunRPC要解決的核心問題之一是遠(yuǎn)程過程調(diào)用執(zhí)行時(shí)間是不可控的，協(xié)議設(shè)計(jì)者為此定制化設(shè)計(jì)，盡量避免非冪等操作RPC重試帶來的副作用。

信號(hào)中斷

應(yīng)用程序等待遠(yuǎn)程過程調(diào)用結(jié)果時(shí)允許被信號(hào)中斷。當(dāng)發(fā)生信號(hào)中斷時(shí)由于沒有得到遠(yuǎn)程過程調(diào)用的執(zhí)行結(jié)果，所以客戶端和服務(wù)端的狀態(tài)很可能就不一致了，比如加鎖操作在服務(wù)端已經(jīng)成功執(zhí)行，但客戶端并不知道這個(gè)情況。這就要求客戶端做額外的工作將狀態(tài)和服務(wù)端恢復(fù)一致。下面簡要分析獲取文件鎖被信號(hào)中斷后的處理說明NFS協(xié)議實(shí)現(xiàn)層面的一致性設(shè)計(jì)。
通過獲取NFSv4文件鎖的過程可知，NFSv4獲取文件鎖最終會(huì)調(diào)用_nfs4_do_setlk()函數(shù)發(fā)起RPC操作，最終調(diào)用nfs4_wait_for_completion_rpc_task()等待，下面是相關(guān)代碼:

5684 static int _nfs4_do_setlk(struct nfs4_state state, int cmd, struct file_lock fl, int recovery_type)
5685 {

  ......

5718 task = rpc_run_task(&task_setup_data);
5719 if (IS_ERR(task))
5720 return PTR_ERR(task);
5721 ret = nfs4_wait_for_completion_rpc_task(task);
5722 if (ret == 0) {
5723 ret = data->rpc_status;
5724 if (ret)
5725 nfs4_handle_setlk_error(data->server, data->lsp,
5726 data->arg.new_lock_owner, ret);
5727 } else
5728 data->cancelled = 1;

   ......
 }

Copy
通過分析nfs4_wait_for_completion_rpc_task()實(shí)現(xiàn)可知，當(dāng)ret < 0時(shí)，表明獲取鎖過程被信號(hào)中，并使用struct nfs4_lockdata的cancelled成員記錄。繼續(xù)查看rpc_task完成后釋放時(shí)的回調(diào)函數(shù)nfs4_lock_release():

從上面紅色框中代碼可知，nfs4_lock_release()檢測到存在信號(hào)中斷時(shí)會(huì)調(diào)用nfs4_do_unlck()函數(shù)嘗試將可能成功獲得文件鎖釋放掉，注意此時(shí)沒有調(diào)用nfs_free_seqid()函數(shù)將持有的nfs_seqid釋放掉，這是為了：

1) 保證訂正狀態(tài)過程中不會(huì)有用戶新發(fā)起的并發(fā)加鎖或者釋放鎖操作，簡化實(shí)現(xiàn)；
2) 保證hard模式下UNLOCK操作只會(huì)在LOCK操作返回后才會(huì)發(fā)送，保障已經(jīng)獲得鎖能夠被釋放掉；
客戶端通過上面的方法能夠有效地保證信號(hào)中斷后客戶端和服務(wù)端鎖狀態(tài)的最終一致性,但也是在損失一部分可用性為代價(jià)的。

文件鎖是文件系統(tǒng)原生支持的基礎(chǔ)特性，NAS作為共享的文件系統(tǒng)要面臨客戶端和服務(wù)端鎖狀態(tài)視圖一致性的問題，NFSv4.0在一定程度上解決了這個(gè)問題，當(dāng)然，技術(shù)前進(jìn)的腳步不會(huì)停止，NFS的更新迭代也就不會(huì)停止，未來的NFS將會(huì)有更多的期待。

關(guān)于如何進(jìn)行NFS文件鎖一致性設(shè)計(jì)原理解析就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

網(wǎng)站欄目：如何進(jìn)行NFS文件鎖一致性設(shè)計(jì)原理解析
當(dāng)前鏈接：http://aaarwkj.com/article14/gopsde.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、、網(wǎng)站改版、服務(wù)器托管、移動(dòng)網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)