徐州网站建设推广,如何做网站步骤,兰州网站推广建设公司,怎么更改网站备案信息吗简介#xff1a; 阿里云存储提供了完整的分布式锁解决方案#xff0c;经过了阿里云众多云产品宝贵的业务场景中长期锤炼#xff0c;稳定高可靠#xff0c;且提供了多种语言的SDK选择#xff0c;甚至是RESTful集成方案。
1 背景
针对共享资源的互斥访问历来是很多业务系统…简介 阿里云存储提供了完整的分布式锁解决方案经过了阿里云众多云产品宝贵的业务场景中长期锤炼稳定高可靠且提供了多种语言的SDK选择甚至是RESTful集成方案。
1 背景
针对共享资源的互斥访问历来是很多业务系统需要解决的问题。在分布式系统中通常会采用分布式锁这一通用型解决方案。本文将就分布式锁的实现原理、技术选型以及阿里云存储的具体实践进行论述。 图1 锁
2 从单机锁到分布式锁
在单机环境中当共享资源自身无法提供互斥能力的时候为了防止多线程/多进程对共享资源的同时读写访问造成的数据破坏就需要一个第三方提供的互斥的能力这里往往是内核或者提供互斥能力的类库如下图所示进程首先从内核/类库获取一把互斥锁拿到锁的进程就可以排他性的访问共享资源。演化到分布式环境我们就需要一个提供同样功能的分布式服务不同的机器通过该服务获取一把锁获取到锁的机器就可以排他性的访问共享资源这样的服务我们统称为分布式锁服务锁也就叫分布式锁。 图2 单机锁到分布式锁
由此抽象一下分布式锁的概念首先分布式锁需要是一个资源这个资源能够提供并发控制并输出一个排他性的状态也就是 锁 资源 并发控制 所有权展示 以常见的单机锁为例 Spinlock BOOL CAS 乐观锁 Mutex BOOL CAS 通知 悲观锁 Spinlock和Mutex都是一个Bool资源通过原子的CAS指令当现在为0设置为1成功的话持有锁失败的话不持有锁如果不提供所有权的展示例如AtomicInteger也是通过资源IntergerCAS但是不会明确的提示所有权因此不会被视为一种锁当然可以将“所有权展示”这个更多地视为某种服务提供形式的包装。 单机环境下内核具备“上帝视角”能够知道进程的存活当进程挂掉的时候可以将该进程持有的锁资源释放但发展到分布式环境这就变成了一个挑战为了应对各种机器故障、宕机等就需要给锁提供了一个新的特性可用性。 如下图所示任何提供三个特性的服务都可以提供分布式锁的能力资源可以是文件、KV等通过创建文件、KV等原子操作通过创建成功的结果来表明所有权的归属同时通过TTL或者会话来保证锁的可用性。 图3 分布式锁的特性和实现
3 分布式锁的系统分类
根据锁资源本身的安全性我们将分布式锁分为两个阵营 A基于异步复制的分布式系统例如mysqltairredis等 B基于paxos协议的分布式一致性系统例如zookeeperetcdconsul等 基于异步复制的分布式系统存在数据丢失丢锁的风险不够安全往往通过TTL的机制承担细粒度的锁服务该系统接入简单适用于对时间很敏感期望设置一个较短的有效期执行短期任务丢锁对业务影响相对可控的服务。 基于paxos协议的分布式系统通过一致性协议保证数据的多副本数据安全性高往往通过租约会话的机制承担粗粒度的锁服务该系统需要一定的门槛适用于对安全性很敏感希望长期持有锁不期望发生丢锁现象的服务。
4 阿里云存储分布式锁
阿里云存储在长期的实践过程中在如何提升分布式锁使用时的正确性、保证锁的可用性以及提升锁的切换效率方面积累比较多的经验。
4.1 严格互斥性 互斥性作为分布式锁最基本的要求对用户而言就是不能出现“一锁多占”那么存储分布式锁是如何避免该情况的呢 答案是服务端每把锁都和唯一的会话绑定客户端通过定期发送心跳来保证会话的有效性也就保证了锁的拥有权。当心跳不能维持时会话连同关联的锁节点都会被释放锁节点就可以被重新抢占。这里有一个关键的地方就是如何保证客户端和服务端的同步在服务端会话过期的时候客户端也能感知如下图所示在客户端和服务端都维护了会话的有效期的时间客户端从心跳发送时刻S0开始计时服务端从收到请求S1开始计时这样就能保证客户端会先于服务端过期。 用户在创建锁之后核心工作线程在进行核心操作之前可以判断是否有足够的有效期同时我们不再依赖墙上时间而是基于系统时钟来对时间进行判断系统时钟更加精确且不会向前或者向后移动秒级别误差毫秒级同时在NTP跳变的场景最多会修改时钟的速率。 图4 存储场景的使用方式
在分布式锁互斥性上我们是不是做到完美了并非如此还是存在一种情况下业务基于分布式锁服务的访问互斥会被破坏。我们来看下面的例子如下图9所示客户端在时间点S0尝试去抢锁在时间点S1在后端抢锁成功因此也产生了一个分布式锁的有效期窗口。在有效期内时间点S2做了一个访问存储的操作很快完成然后在时间点S3判断锁的有效期依旧成立继续执行访问存储操作结果这个操作耗时良久超过了分布式锁的过期时间那么可能这个时候分布式锁已经被其他客户端抢占成功进而出现两个客户端同时操作同一批数据的可能性这种可能性是存在的虽然概率很小。 图6 越界场景
针对这个场景具体的应对方案是在操作数据的时候确保有足够的锁有效期窗口当然如果业务本身提供回滚机制的话那么方案就更加完备该方案也在存储产品使用分布式锁的过程中被采用。 还有一个更佳的方案即存储系统本身引入IO Fence能力。这里就不得不提Martin Kleppmann和redis的作者antirez之间的讨论了redis为了防止异步复制导致的锁丢失的问题引入redlock该方案引入了多数派的机制需要获得多数派的锁最大程度的保证了可用性和正确性但仍然有两个问题 • 墙上时间的不可靠NTP时间 • 异构系统的无法做到严格正确性 墙上时间可以通过非墙上时间MonoticTime来解决redis目前仍然依赖墙上时间但是异构系统的只有一个系统并没有办法保证完全正确如下图10所示Client1获取了锁在操作数据的时候发生了GC在GC完成时候丢失了锁的所有权造成了数据不一致。 图7 异构系统无法做到完全正确性
因此需要两个系统同时协作来完成一个完全正确的互斥访问在存储系统引入IO Fence能力如下图11所示全局锁服务提供全局自增的tokenClient1拿到锁返回的token是33并带入存储系统发生GC当Client2抢锁成功返回34带入存储系统存储系统会拒绝token较小的请求那么经过了长时间full gc重新恢复后的Client 1再次写入数据的时候因为存储层记录的Token已经更新携带token值为33的请求将被直接拒绝从而达到了数据保护的效果chubby的论文中有讲述也是Martin Kleppmann提出的解决方案。 图8 引入IO Fence能力
这与阿里云分布式存储平台盘古的设计思路不谋而合盘古支持了类似IO Fence的写保护能力引入Inline File的文件类型配合Seal File操作这就有着类似IO Fence的写保护能力首先SealFile操作用来关闭已经打开的cs上面的文件防止旧的Owner继续写数据其次InlineFile可以防止旧的Owner打开新的文件。这两个功能事实上也是提供了存储系统中的Token支持。
4.2 可用性 存储分布式锁通过持续心跳来保证锁的健壮性让用户不用投入很多精力关注可用性但也有可能异常的用户进程持续占据锁。针对该场景为了保证锁最终可以被调度提供了可以安全释放锁的会话加黑机制。 当用户需要将发生假死的进程持有的锁释放时可以通过查询会话信息并将会话加黑此后心跳将不能正常维护最终导致会话过期锁节点被安全释放。这里我们不是强制删除锁而是选用禁用心跳的原因如下:
删除锁操作本身不安全如果锁已经被其他人正常抢占此时删锁请求会产生误删除。 b.删除锁后持有锁的人会话依然正常它仍然认为自己持有锁会打破锁的互斥性原则。
4.3 切换效率 当进程持有的锁需要被重新调度时持有者可以主动删除锁节点但当持有者发生异常(如进程重启机器宕机等)新的进程要重新抢占就需要等待原先的会话过期后才有机会抢占成功。默认情况下分布式锁使用的会话生命期为数十秒当持有锁的进程意外退出后(未主动释放锁)最长需要经过很长时间锁节点才可以被再次抢占。 图5 客户端和服务各自维护过期时间
要提升切换精度本质上要压缩会话生命周期同时也意味着更快的心跳频率对后端更大的访问压力。我们通过对进行优化使得会话周期可以进一步压缩。 同时结合具体的业务场景例如守护进程发现锁持有进程挂掉的场景提供锁的CAS释放操作使得进程可以零等待进行抢锁。比如利用在锁节点中存放进程的唯一标识强制释放已经不再使用的锁并重新争抢该方式可以彻底避免进程升级或意外重启后抢锁需要的等待时间。
5 结语
阿里云存储提供了完整的分布式锁解决方案经过了阿里云众多云产品宝贵的业务场景中长期锤炼稳定高可靠且提供了多种语言的SDK选择甚至是RESTful集成方案。 分布式锁提供了分布式环境下共享资源的互斥访问业务或者依赖分布式锁追求效率提升或者依赖分布式锁追求访问的绝对互斥。同时在接入分布式锁服务过程中要考虑接入成本、服务可靠性、分布式锁切换精度以及正确性等问题正确和合理的使用分布式锁是需要持续思考并予以优化的。 原文链接 本文为阿里云原创内容未经允许不得转载。
