Web Locks API主要用于同一浏览器上下文内的资源协调，通过navigator.locks.request()方法实现客户端共享资源的原子性访问。它支持排他锁（exclusive）和共享锁（shared）模式，可防止多标签页间的操作冲突，适用于防止重复提交、同步本地存储、单例任务执行等场景。相比localStorage等传统同步机制，其优势在于原子性、自动释放、内置队列管理和更清晰的语义，但局限在同源策略和客户端范围，无法跨浏览器或机器协调。在分布式锁系统中，Web Locks API不替代后端锁机制（如Redis或ZooKeeper），而是作为前端“本地哨兵”，减少对后端锁服务的无效请求，优化用户体验和系统效率。
Web Locks API主要用于同一浏览器上下文（即同一来源的多个标签页或Worker）内的资源协调，它提供了一种原生的、原子性的方式来管理客户端共享资源的访问。这并非一个真正的“分布式锁”机制，因为分布式锁通常指跨不同客户端、不同服务器甚至不同机器的协调。然而，在前端，它能有效解决同一用户在多个浏览器标签页之间操作冲突的问题，并在与后端分布式锁结合时，作为客户端优化的第一道防线。
解决方案
在前端，利用Web Locks API实现“锁”机制的核心在于
navigator.locks.request()
方法。这个方法允许你请求一个具名的锁，并在锁被授予后执行一段关键代码。
定义锁的名称： 为你想要保护的资源选择一个唯一的字符串作为锁的名称。例如，如果你想防止用户重复提交某个表单，可以将其命名为
'submit-order-lock'
。
选择锁的模式：
'exclusive'
（排他模式）：这是默认模式。同一时间只有一个请求可以持有这个锁。适用于写入操作或任何需要独占访问的场景。
'shared'
（共享模式）：允许多个请求同时持有同一个锁。适用于读取操作，当多个读取者可以同时访问资源，但写入者需要独占访问时。
发起锁请求：
async function performCriticalOperation() { try { // 请求一个排他锁，名为 'my-resource-lock' await navigator.locks.request('my-resource-lock', async (lock) => { // lock 参数是 LockInfo 对象，包含锁的名称和模式 console.log(`Lock '${lock.name}' acquired in '${lock.mode}' mode.`); // 这是你的关键代码区域，只有在获得锁后才能执行 // 假设这里是一个耗时的API调用或数据处理 console.log('Performing critical operation...'); await new Promise(resolve => setTimeout(resolve, 3000)); // 模拟耗时操作 console.log('Critical operation completed.'); // 确保在操作完成后或出错时，锁能被释放 // Promise完成后，锁会自动释放，但你也可以在此处显式处理 }); console.log('Lock released, operation finished.'); } catch (error) { // 如果请求被中止（例如，通过AbortSignal），或者其他错误 console.error('Failed to acquire or execute with lock:', error); }}// 在不同地方调用，尝试获取同一个锁performCriticalOperation();performCriticalOperation(); // 另一个请求会排队等待
处理选项：
request()
方法还接受一个选项对象：
mode
:
'exclusive'
或
'shared'
。
ifAvailable
: 如果设置为
true
，锁不可用时会立即拒绝Promise而不是等待。
steal
: 如果设置为
true
，当锁被其他请求持有但处于空闲状态时，会尝试“窃取”锁。这需要谨慎使用，因为它可能导致其他等待的请求永远无法获得锁。
signal
: 一个
AbortSignal
对象，允许你在锁请求等待时取消它。
lifetime
: 指定锁的生存周期（以毫秒为单位），超过此时间锁会自动释放。通常不需要，因为锁会在回调函数执行完毕后自动释放。
Web Locks API的强大之处在于它抽象了底层的并发控制细节，让开发者可以专注于业务逻辑，而不用担心复杂的竞态条件和锁管理。
Web Locks API在前端并发控制中的实际应用场景有哪些？
说实话，当我第一次接触Web Locks API时，我立刻想到了那些我们过去用
localStorage
或
sessionStorage
加一些自定义逻辑来模拟锁的“黑魔法”。Web Locks API的出现，为前端的并发控制提供了一个更加规范和可靠的工具。
它的实际应用场景远比我们想象的要多：
防止重复的API请求： 这是最常见的痛点之一。用户手抖多点了几下提交按钮，或者网络延迟导致请求看起来没响应，用户又点了一次。如果没有锁机制，后端可能会收到多个重复的请求，导致数据混乱或不必要的资源消耗。Web Locks API可以在发送API请求前获取一个锁，确保同一时间只有一个请求在进行。同步
localStorage
或
IndexedDB
操作： 多个浏览器标签页或Worker可能同时尝试读写本地存储。如果没有协调，就可能出现数据覆盖或读取到不一致状态的问题。使用Web Locks API可以确保对特定存储键的读写操作是原子性的。例如，一个标签页在更新用户配置到
localStorage
时，可以获取一个排他锁，防止另一个标签页同时写入。单例任务执行： 有些后台任务，比如数据同步、定时刷新令牌、或者推送通知的注册，我们希望它只在其中一个浏览器标签页或Worker中执行。Web Locks API可以用来选举一个“领导者”标签页，由它来执行这个任务，其他标签页则保持静默。UI状态的竞态条件： 复杂的单页应用中，多个异步事件可能同时触发对同一个UI元素的更新。例如，一个数据加载完成的事件和一个用户交互事件同时尝试修改同一个DOM元素。Web Locks API可以用来序列化这些UI更新操作，确保UI状态的一致性。资源密集型操作的节流： 某些计算密集型或内存密集型的操作（如图片处理、大型数据解析）如果同时在多个标签页中运行，可能会导致浏览器卡顿甚至崩溃。通过Web Locks API，可以限制这些操作在同一时间只能有一个实例运行。
对我而言，Web Locks API最吸引人的地方在于它提供了一种浏览器原生的、可靠的解决方案，避免了手动实现锁机制时容易引入的各种竞态条件和bug。它不是万能的，但对于客户端内部的协调，它无疑是目前最好的选择之一。
Web Locks API与传统的客户端同步机制（如
localStorage
localStorage
事件）相比，优势和局限性何在？
回想起以前尝试用
localStorage
来实现跨标签页同步，那简直是一场与竞态条件的搏斗。你得非常小心地设计写入、读取、删除逻辑，还得监听
storage
事件，处理各种边缘情况，稍有不慎就可能导致数据不一致。Web Locks API的出现，就像给前端工程师提供了一把趁手的工具，而不是让我们自己去造轮子。
Web Locks API的优势：
原子性和可靠性： 这是最核心的优势。Web Locks API提供了真正的原子性锁操作。当你请求一个锁时，浏览器会保证要么你获得锁，要么你等待，要么你被拒绝（如果使用了
ifAvailable
）。这避免了
localStorage
模拟锁时常见的“检查-然后-设置”的竞态条件。内置的队列管理： 当多个请求同时竞争同一个锁时，Web Locks API会自动将它们排队。这省去了开发者手动管理等待队列的复杂性，代码逻辑变得更清晰。而
localStorage
需要你手动实现复杂的重试、等待机制。明确的语义和意图：
navigator.locks.request()
方法本身就清晰地表达了“我需要独占访问这个资源”的意图。相比之下，
localStorage
事件更多是用于广播状态变化，而不是用于控制独占访问。自动释放机制： 当持有锁的Promise解决或拒绝时，或者当标签页关闭/导航时，锁会自动释放。这大大降低了死锁的风险，而
localStorage
模拟锁时，你必须非常小心地处理锁的释放，否则可能导致永久性死锁。条件性获取和中止：
ifAvailable
和
signal
选项提供了更灵活的锁管理策略，可以尝试非阻塞获取锁，或者在长时间等待后取消锁请求，这在
localStorage
中很难优雅地实现。
Web Locks API的局限性：
仅限于同源（Same-Origin）： Web Locks API的锁作用域严格限定在同一来源（origin）下。这意味着不同域名下的标签页或Worker无法通过它进行协调。客户端（浏览器）范围： 它是一个纯粹的客户端API，无法与服务器端的资源进行直接协调。它不能替代后端分布式锁系统。浏览器支持： 虽然现代浏览器（Chrome, Firefox, Edge, Safari）已广泛支持，但如果你需要支持非常老的浏览器，可能需要提供降级方案。无法跨浏览器实例： 如果用户在两台不同的机器上，或者同一个机器上使用两个不同的浏览器（例如Chrome和Firefox），Web Locks API也无法协调它们之间的资源访问。
总结来说，Web Locks API在处理同一浏览器实例内、同源的客户端并发问题时，提供了远超传统
localStorage
事件的健壮性和便利性。它让前端工程师能够以更声明式、更可靠的方式解决本地并发挑战。
如何结合后端服务，构建一个真正意义上的分布式锁系统，Web Locks API在其中扮演什么角色？
要构建一个真正意义上的分布式锁系统，前端的Web Locks API是远远不够的。分布式锁的核心在于协调跨进程、跨机器的资源访问，这必然需要一个中心化的、高可用的后端服务来管理锁的状态。我通常会把Web Locks API看作是客户端的“本地哨兵”，它能为后端分布式锁系统减轻一些不必要的负担，并优化用户体验。
后端分布式锁系统的构建：
一个典型的后端分布式锁系统会依赖于一个共享存储或服务，例如：
Redis： 常用
SET NX EX
命令来实现原子性的锁获取，配合Lua脚本进行锁的释放，并需要考虑锁的过期时间、续期机制（Redlock算法是一个更复杂的分布式锁实现）。ZooKeeper/etcd/Consul： 这些是专门为分布式协调设计的服务。它们通过创建临时有序节点等机制，可以实现强一致性的分布式锁。数据库： 可以通过创建唯一的记录（例如，一个带有唯一索引的锁表），或者利用事务和行锁来实现。但这通常性能较低，且容易遇到死锁。
无论选择哪种后端技术，一个真正的分布式锁系统都必须解决以下几个关键问题：
原子性： 锁的获取和释放必须是原子操作。互斥性： 在任何给定时刻，只有一个客户端能持有锁。死锁避免： 即使持有锁的客户端崩溃，锁也必须能被释放（通常通过设置过期时间或心跳机制）。容错性： 锁服务本身不能成为单点故障。可重入性（可选）： 同一个客户端可以多次获取同一个锁。
Web Locks API在其中的角色：
Web Locks API在这里的角色，可以理解为客户端的“前置缓存”或“本地节流器”。它不会直接参与后端分布式锁的协调，但能有效地优化客户端行为，减少对后端锁服务的压力。
减少后端锁请求： 假设用户在多个浏览器标签页中同时尝试执行一个需要后端分布式锁的操作（比如购买一件商品）。如果每个标签页都直接去请求后端分布式锁，会增加后端服务的负担。通过Web Locks API，我们可以在前端先获取一个本地锁。只有成功获取到本地Web Lock的标签页，才会向后端服务发起请求，尝试获取分布式锁。其他标签页会因为无法获取Web Lock而等待，或者被告知操作正在进行中。这样可以有效减少同一用户在短时间内向后端发起的重复分布式锁请求，减轻后端压力。优化用户体验： 当一个标签页正在执行需要分布式锁的操作时，其他标签页可以显示一个“正在处理”或“请稍候”的提示，而不是每个标签页都去尝试操作，然后收到后端冲突的响应。这提供了更流畅、更一致的用户体验。客户端本地资源保护： 即使有了后端分布式锁，客户端内部可能仍然有一些共享资源（如本地状态、UI元素）需要保护，Web Locks API可以独立于后端锁，提供这种本地的并发控制。
示例流程：
用户点击“购买”按钮。前端代码首先使用
navigator.locks.request('purchase-lock', ...)
尝试获取一个Web Lock。如果成功获取Web Lock：a. 前端向后端服务发送请求，尝试获取分布式锁（例如，通过一个API调用）。b. 如果后端分布式锁获取成功，执行购买逻辑。c. 购买完成后，释放后端分布式锁，Web Lock也随之释放。d. 如果后端分布式锁获取失败（例如，商品已被其他用户锁定），则释放Web Lock，并提示用户。如果未能获取Web Lock（说明同一浏览器内有其他标签页正在处理）：a. 前端可以显示“您的订单正在处理中，请勿重复操作”的提示，或者等待Web Lock释放。
所以，Web Locks API在分布式锁系统中扮演的角色，更像是一个客户端的智能代理，它在本地层面过滤和协调请求，确保只有经过本地协调的请求才去竞争真正的分布式锁，从而提高整体系统的效率和用户体验。它不是分布式锁的替代品，而是其在客户端的有力补充。
以上就是如何用Web Locks API实现分布式锁机制？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1521087.html
微信扫一扫 
支付宝扫一扫 
