前言
在分布式系统中,难免涉及到对同一数据的并发操作,如何保证分布式系统中数据的并发安全呢?分布式锁!
一:分布式锁
常用的分布式锁实现方式:
1、基于数据库实现分布式锁
针对于数据库实现的分布式锁,如mysql使用使用for update
共同竞争一个行锁来实现; 在JanusGraph中,也是基于数据库实现的分布式锁,这里的数据库
指的是我们当前使用的第三方backend storage
,具体的实现方式也和mysql有所不同,具体我们会在下文分析
2、基于Redis实现的分布式锁
基于lua脚本
+setNx
实现
3、基于zk实现的分布式锁
基于znode
的有序性和临时节点
+zk的watcher
机制实现
4、MVCC多版本并发控制乐观锁实现
本文主要介绍Janusgraph的锁机制,其他的实现机制就不在此做详解了
下面我们来分析一下JanusGraph
的锁机制
实现~
二:JanusGraph锁机制
在JanusGraph中使用的锁机制是:本地锁
+ 分布式锁
来实现的;
2.1 一致性行为
在JanusGraph
中主要有三种一致性修饰词(Consistency Modifier)
来表示3种不同的一致性行为
,来控制图库使用过程中的并发问题的控制程度;
public enum ConsistencyModifier {
DEFAULT,
LOCK,
FORK
}
源码中ConsistencyModifier
枚举类主要作用:用于控制JanusGraph在最终一致或其他非事务性后端系统
上的一致性行为!其作用分别为:
- DEFAULT:默认的一致性行为,不使用分布式锁进行控制,对配置的存储后端使用由封闭事务保证的默认一致性模型,一致性行为主要取决于存储后端的配置以及封闭事务的(可选)配置;无需显示配置即可使用
- LOCK:在存储后端支持锁的前提下,显示的获取分布式锁以保证一致性!确切的一致性保证取决于所配置的锁实现;需
management.setConsistency(element, ConsistencyModifier.LOCK);
语句进行配置 - FORK:只适用于
multi-edges
和list-properties
两种情况下使用;使JanusGraph修改数据时,采用先删除后添加新的边/属性的方式,而不是覆盖现有的边/属性,从而避免潜在的并发写入冲突;需management.setConsistency(element, ConsistencyModifier.FORK);
进行配置
LOCK
在查询或者插入数据时,是否使用分布式锁
进行并发控制,在图shcema
的创建过程中,如上述可以通过配置schema元素
为ConsistencyModifier.LOCK
方式控制并发,则在使用过程中就会用分布式锁
进行并发控制;
为了提高效率,JanusGraph默认不使用锁定。 因此,用户必须为定义一致性约束
的每个架构元素决定是否使用锁定。
使用JanusGraphManagement.setConsistency(element,ConsistencyModifier.LOCK)
显式启用对架构元素的锁定
代码如下所示:
mgmt = graph.openManagement()
name = mgmt.makePropertyKey('consistentName').dataType(String.class).make()
index = mgmt.buildIndex('byConsistentName', Vertex.class).addKey(name).unique().buildCompositeIndex()
mgmt.setConsistency(name, ConsistencyModifier.LOCK) // Ensures only one name per vertex
mgmt.setConsistency(index, ConsistencyModifier.LOCK) // Ensures name uniqueness in the graph
mgmt.commit()
FORK
由于边缘作为单个记录存储在基础存储后端中,因此同时修改单个边缘将导致冲突。
FORK
就是为了代替LOCK
,可以将边缘标签配置为使用ConsistencyModifier.FORK
。
下面的示例创建一个新的edge label,并将其设置为ConsistencyModifier.FORK
mgmt = graph.openManagement()
related = mgmt.makeEdgeLabel('related').make()
mgmt.setConsistency(related, ConsistencyModifier.FORK)
mgmt.commit()
经过上述配置后,修改标签配置为FORK
的edge时,操作步骤为:
- 首先,删除该边
- 将修改后的边作为新边添加
因此,如果两个并发事务修改了同一边缘,则提交时将存在边缘的两个修改后的副本,可以在查询遍历期间根据需要解决这些副本。
注意edge fork仅适用于MULTI edge。 具有多重性约束的边缘标签不能使用此策略,因为非MULTI的边缘标签定义中内置了一个唯一性约束,该约束需要显式锁定或使用基础存储后端的冲突解决机制
下面我们具体来看一下janusgrph
的锁机制
的实现:
2.2 LoackID
在介绍锁机制之前,先看一下锁应该锁什么东西呢?
我们都知道在j