分布式锁服务设计01设计方案
Posted 架构之家
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式锁服务设计01设计方案相关的知识,希望对你有一定的参考价值。
锁主要解决资源并发的问题,在java单应用的情况下,可以通过Synchronized,ReentrantLock实现。但在分布式环境下对同一资源访问,如何实现并发锁控制呢?主要实现方案是分布式锁。本文主要介绍Redis分布式锁的一种设计方案,代码预计在第二篇发布。将传统的基于Jar包的锁提升为锁服务。不足之处,请大家一起交流。
一、整体方案
1.1组件图
1.2组件介绍
(1)锁服务-客户端
主要职责:封装LockService的调用(可使用代理或注解方式,用于业务功能使用)。
(2)锁服务-服务端
主要职责:实现加锁和解锁功能(手动解锁,自动解锁)。
(3)锁服务-管理端
主责职责:监控锁服务的运行情况,控制锁参数的执行细节。
2.3锁生命周期
锁的状态:无锁,已锁定,锁定成功,已解锁[无锁]
锁的操作:请求加锁,请求解锁,自动解锁,锁等待,锁超时
二、锁服务-服务端设计
2.1设计类图
2.2类图介绍
(1)对外开放锁定和解锁接口,其中Key的参数为Map<String,String>类型。
(2)锁机制基于Redis的串行执行和SetNx命令实现。
(3)lock(keyMap : Map<String, String>)方法,采用默认超时时间,此时间可以通过管理端根据不同的业务参数自定义。
(4)lock(keyMap : Map<String, String>, ltimeout :long) ,采用指定超时时间,此时间也可以通过管理端根据不同的业务参数自定义覆盖或不覆盖。
2.3 Map Key参数设计
基于Map实现可扩展的参数设计,主要字段介绍,如下:
Map key |
Map value |
描述 |
格式说明 |
source |
100 |
业务系统 |
|
ver |
10 |
版本号 |
|
subSys |
101010 |
子系统 |
前两位=子系统,中间两位=模块,后两位=功能 |
业务参数N |
其它业务参数 |
N个则为N个key |
三、锁服务-客户端设计
3.1类图设计
3.2类图介绍
(1)左侧是调用锁服务的简单封装,主要用于封装重复代码,方便业务调用。简称为代理模式;
(2)右侧是在代理模式的基础上,做注解和拦截,根据复杂程度此处可实现可不实现;
(3)如果简单,代理模式也可以不使用,直接调用服务接口即可。
四、锁服务-管理端设计
4.1功能用例图
4.2主要用例介绍
(1)开通锁权限
开通某业务系统的分布式锁使用权限,可细化到业务系统,模块或功能。
(2)管理锁权限
管理锁的使用权限比如停用,开通,查询等功能。
(3)配置通用锁参数
配置锁服务的公用参数,比如默认锁超时时间,服务降级,异常返回值等。
(4)配置业务锁参数
配置具体业务,模块,功能,参数的锁参数,比如默认超时时间,服务降级,异常返回值等。
(5)查看锁运行情况
根据实际需要可开发,如查看目前锁定的业务功能,锁定时间,锁冲突日志,历史锁定统计等功能。
五、锁分级-实际应用
5.1分级锁设计
针对不同的业务场景,锁控制的范围和粒度,简单划分为以下几种锁类型。
业务锁:与锁定值相关的所有操作;比如:锁订单号,可以控制所有与订单号有关的流程;
业务锁:一个业务流程中的某一类数据;比如在落单时控制并发,Key=订单号+_CREATE。
乐观锁:允许并发操作,但最终只有一个可执行成功,其它失败。适用于并发量不大但需要强一致的情况。比如将某订单从待支付更新为支付成功。
5.2锁服务降级
当分布式锁宕机时,需要支持锁服务降级,此处推荐两种方案:
(1)数据库方式
原理:数据库唯一索引+DB乐观锁[最底层控制方案]+查询数据。适用于并发量不大的情况,如果并发量大需要前端做限流。
(2)基于Zookeeper
原理:在获取分布式锁的时候在locker节点下创建临时顺序节点,释放锁的时候删除该临时节点。适合大并发场景。此方案也可以理解为与Redis锁的互备,实现高可用。
六、下篇预告
设计方案优化,服务化实现,提供源码。
以上是关于分布式锁服务设计01设计方案的主要内容,如果未能解决你的问题,请参考以下文章