如何进行NFS文件锁一致性设计原理解析
这篇文章给大家介绍如何进行NFS文件锁一致性设计原理解析，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
10年积累的成都网站制作、网站设计经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计制作后付款的网站建设流程，更有平潭免费网站建设让你可以放心的选择与我们合作。
文件锁
文件锁是文件系统的最基本特性之一，应用程序借助文件锁可以控制其他应用对文件的并发访问。NFS作为类UNIX系统的标准网络文件系统，在发展过程中逐步的原生地支持了文件锁(从NFSv4开始)。NFS从上个世界80年代诞生至今，共发布了3个版本：NFSv2、NFSv3、NFSv4。NFSv4最大的变化是有“状态”了。某些操作需要服务端维持相关状态，如文件锁，例如客户端申请了文件锁，服务端就需要维护该文件锁的状态，否则其他客户端冲突的访问就无法检测。如果是NFSv3就需要NLM协助才能实现文件锁功能，但是有的时候两者配合不够协调就会容易出错。而NFSv4设计成了一种有状态的协议，自身就可以实现了文件锁功能，也就不需要NLM协议了。
应用接口
应用程序可以通过fcntl()或flock()系统调用管理NFS文件锁，下面NAS使用NFSv4挂载时获取文件锁的调用过程:
从上图调用栈容易看出来，NFS文件锁实现逻辑基本复用了VFS层设计和数据结构，在通过RPC从Server成功获取文件锁后调用locks_lock_inode_wait()函数将获得文件锁交给到VFS层管理，关于VFS层文件锁设计的相关资料比较多，在此就不再描述了。
EOS原理
文件锁是典型的非幂等操作，文件锁操作的重试和Failover会导致文件锁状态视图在客户端和服务端间的不一致。NFSv4借助SeqId机制设计了最多执行一次的机制，具体方法如下：
针对每个open/lock状态Client和Server同时独立维护seqid，Client在发起会引起状态变化的操作时(open/close/lock/unlock/release_lockowner)会将seqid加1，并作为参数发送给Server，假定Client发送的seqid为R，Server维护的seqid为L，则：
1) 若R == L +1，表示合法请求，正常处理之；
2) 若R == L，表示重试请求，Server将缓存的reply返回即可；
3) 其他情况均为非法请求，决绝访问。
根据上述规则，Server可判断操作是否为正常、重试或非法请求。
该方法能够保证每个文件锁操作在服务端最多执行一次，解决了RPC重试带来的重复执行的问题，但是仅靠这一点是不够的。比如LOCK操作发送后调用线程被信号中断，此后服务端又成功接受并执行了该LOCK操作，这样服务端就记录了客户端持有了锁，但客户端中却因为中断而没有维护这把锁，客户端和服务端间的锁状态视图不一致就发生了。因此，客户端还需配合处理异常场景，最终才能够做到文件锁视图一致性。
异常处理
由上一节分析可知，客户端需要配合处理异常场景才能够保证文件视图一致性，那么客户端设计者主要做了哪些配合的设计呢？目前客户端主要从SunRPC和NFS协议实现两个维度相互配合解决该问题，下面会分别介绍这两个维度的设计如何保证了文件锁状态视图一致性。
SunRPC设计
SunRPC是Sun公司专门为远程过程调用设计的网络通讯协议，这里从保障文件锁视图一致性的维度来了解一下SunRPC实现层面的设计理念：
1) 客户端使用int32_t类型的xid标识上层使用者发起的每个远程过程调用过程，每个远程过程调用的多次RPC重试使用相同的xid标识，这样就保障了多次RPC重试中任何一个返回就可以告知上层远程过程调用已经成功，保证了服务端执行远程过程调用执行耗时较长时也能拿到结果，这一点和传统的netty/mina/brpc等都需要每个RPC都要有独立的xid/packetid不同；
2) 服务端设计了DRC(duplicate request cache)缓存最近执行的RPC结果，接收到RPC时会首先通过xid检索DRC缓存，若命中则表明RPC为重试操作，直接返回缓存的结果即可，这在一定程度上规避了RPC重试带来的重复执行的问题。为了避免xid复用导致DRC缓存返回非预期的结果，开发者通过下述设计进一步有效地减少复用引起错误的概率:
a) 客户端建立新链接时初始xid采用随机值:
b) 服务端DRC会额外记录请求的校验信息，缓存命中时会同时校验这些信息；
3) 客户端允许在获得服务端相应前无限重试，保证调用者能够获得服务端确定性的执行结果，当然这样的策略会导致无响应时调用者会一直hang；
4) NFS允许用户在挂载时通过soft/hard参数指定SunRPC的重试策略，其中soft模式禁止超时后重试，hard模式则持续重试。当用户使用soft模式挂载时NFS实现不保证客户端和服务端状态视图的一致性，在遇到远程过程调用返回超时要求应用程序配合状态的清理和恢复，比如关闭访问出错的文件等，然而实践中很少有应用程序会配合，所以一般情况下NAS用户都使用hard模式挂载；
总之，SunRPC要解决的核心问题之一是远程过程调用执行时间是不可控的，协议设计者为此定制化设计，尽量避免非幂等操作RPC重试带来的副作用。
信号中断
应用程序等待远程过程调用结果时允许被信号中断。当发生信号中断时由于没有得到远程过程调用的执行结果，所以客户端和服务端的状态很可能就不一致了，比如加锁操作在服务端已经成功执行，但客户端并不知道这个情况。这就要求客户端做额外的工作将状态和服务端恢复一致。下面简要分析获取文件锁被信号中断后的处理说明NFS协议实现层面的一致性设计。
通过获取NFSv4文件锁的过程可知，NFSv4获取文件锁最终会调用_nfs4_do_setlk()函数发起RPC操作，最终调用nfs4_wait_for_completion_rpc_task()等待，下面是相关代码:
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()实现可知，当ret < 0时，表明获取锁过程被信号中，并使用struct nfs4_lockdata的cancelled成员记录。继续查看rpc_task完成后释放时的回调函数nfs4_lock_release():
从上面红色框中代码可知，nfs4_lock_release()检测到存在信号中断时会调用nfs4_do_unlck()函数尝试将可能成功获得文件锁释放掉，注意此时没有调用nfs_free_seqid()函数将持有的nfs_seqid释放掉，这是为了：
1) 保证订正状态过程中不会有用户新发起的并发加锁或者释放锁操作，简化实现；
2) 保证hard模式下UNLOCK操作只会在LOCK操作返回后才会发送，保障已经获得锁能够被释放掉；
客户端通过上面的方法能够有效地保证信号中断后客户端和服务端锁状态的最终一致性,但也是在损失一部分可用性为代价的。
文件锁是文件系统原生支持的基础特性，NAS作为共享的文件系统要面临客户端和服务端锁状态视图一致性的问题，NFSv4.0在一定程度上解决了这个问题，当然，技术前进的脚步不会停止，NFS的更新迭代也就不会停止，未来的NFS将会有更多的期待。
关于如何进行NFS文件锁一致性设计原理解析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
网页标题：如何进行NFS文件锁一致性设计原理解析
地址分享：http://6mz.cn/article/gopsde.html