背景
企微报警群里连续发出生产环境报错警告,报错核心信息如下:
redis setNX error java.lang.NumberFormatException: For input string: "null"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:589)
at java.lang.Long.parseLong(Long.java:631)
经异常信息定位,发现是项目中自定义的Redis分布式锁报错,并且该异常是在最近需求上线后突然出现,并且伴随该异常出现的,还有需求涉及的业务数据出现部分错乱的问题。
问题分析
老规矩,先贴涉及代码
//切面
public class RedisLockAspect{
public void around(ProceedingJoinPoint pjp) {
String key = "...";
try {
//阻塞,直到获取锁为止
while (!JedisUtil.lock(key, timeOut)) {
Thread.sleep(10);
}
//执行业务逻辑
pjp.proceed();
}finally {
JedisUtil.unLock(key);
}
}
}
以上为自定义Redis分布式锁的切面,不看细节,只看整体逻辑,问题不大,那再看实际加锁方法。
public class JedisUtil{
public static boolean lock(String key, long timeOut){
long currentTimeMillis = System.currentTimeMillis();
long newExpireTime = currentTimeMillis + timeOut;
RedisConnection connection = null;
try {
connection = getRedisTemplate().getConnectionFactory().getConnection();
Boolean setNxResult = connection.setNX(key.getBytes(StandardCharsets.UTF_8), String.valueOf(newExpireTime).getBytes(StandardCharsets.UTF_8));
//位置1
if(setNxResult){
expire(key,timeOut, TimeUnit.MILLISECONDS);
return true;
}
//位置2
Object objVal = getRedisTemplate().opsForValue().get(key);
String currentValue = String.valueOf(objVal);
//位置3,异常位置为if判断中Long.parseLong(currentValue),currentValue为null的字符串
if (currentValue != null && Long.parseLong(currentValue) < currentTimeMillis) {
String oldExpireTime = (String) getAndSet(key, String.valueOf(newExpireTime));
if (oldExpireTime != null && oldExpireTime.equals(currentValue)) {
return true;
}
}
}
return false;
}
public static void unLock(String key){
getRedisTemplate().delete(key);
}
}
有经验的大佬看到这段代码,估计会忍不住爆粗,但咱先不管,先看错误位置。异常信息可以看出,currentValue的值为字符串“null”,即String.valueOf(objVal)中的objVal对象为null,也就是在Redis中,key对应的value不存在,此时思考一下,key对应的value不存在,无非以下两种情况:
-
key被主动删除;
-
key过期了。
继续跟着代码往上走,发现前面执行了setNx命令,并且返回setNxResult表示是否成功。正常来说,当setNxResult为false的时候,加锁失败,此时代码时不应该往下走的,但在本段代码中,却继续往下走!问了下相关同事,说是为了做可重入锁......(弱弱吐槽下,可重入锁也不是这样干的啊...) 其实分析到这,已经可以知道是什么原因导致的异常故障了,即上面说的,key被主动删除、key过期导致,下面假设有两个线程,对同一个key加锁,分别对应以上两种情况:key被主动删除的情况,发生于分布式锁加锁逻辑执行完后,调用unlock方法,见以上RedisLockAspect类中finally部分,如下图:
key过期的情况,主要在线程加锁并设置过期时间后,执行业务代码耗费的时间超过设置的锁过期时间,并且在锁过期前,未对锁进行续期:
解决方案 从上面的代码看来,这已经不是简单的Long.parseLong("null")问题了,这是整个Redis分布式锁实现的问题,并且该分布式锁在整个项目中大量使用,可想而知其实问题非常严重,如果只是解决Long.parseLong("null")的问题,无疑就是隔靴挠痒,没有任何意义的。一般情况下,自定义Redis分布式锁容易出现以下几大问题:
-
setNx锁释放问题;
-
setNx Expire 原子性问题;
-
锁过期问题;
-
多线程释放锁问题;
-
可重入问题;
-
大量失败时自旋锁问题;
-
主从架构下锁数据同步问题;
结合以上故障代码,可以发现项目中的Redis分布式锁实现几乎未对Redis分布式锁问题进行考虑,以下为主要问题以及对应解决方案:
setNx 和 expire 原子操作:使用Lua脚本,在一次Lua脚本命令中,执行setNx 与 expire命令,保证原子性;锁过期问题:为防止锁自动过期,可在锁过期前,定时对锁过期时间进行续期。可重入问题:可重入设计粒度需到线程级别,可在锁上加上线程唯一id。锁自旋问题:参考JDK中AQS设计,实现获取锁时最大等待时长。
对于项目中的问题以及每个问题的解决方案实现,baidu一下就有大量参考,此处不再介绍。目前比较成熟的综合解决方案为使用Redisson客户端,以下为简单伪代码demo:
public class RedisLockAspect{
@Autowired
private Redisson redisson;
public void around(ProceedingJoinPoint pjp) {
String key = "...";
Long waitTime = 3000L;
//获取锁
RLock lock = redisson.getLock(key);
boolean lockSuccess = false;
try {
//加锁设置超时时间,防止无限自旋。默认启用看门狗功能(自动对锁进行续期)
lockSuccess = lock.tryLock(waitTime);
//执行业务逻辑
pjp.proceed();
}finally {
//解锁,防止释放其他线程锁
if (lock.isLocked() && lock.isHeldByCurrentThread() && lockSuccess){
lock.unlock();
}
}
}
}
使用Redisson可以快速解决目前项目中Redis分布式锁存在的问题。除此之外,对于Redis主从架构下数据同步导致的锁问题,对应的解决方案RedLock,也提供了相应的实现。更多使用文档详见官方文档github.com/liulongbiao…
总结
对于分布式锁来说,可实现方案其实远远不止Redis这个实现途径,比如基于Zookeeper、基于Etcd等方案,但其实对于目的来说,都是殊途同归,重点在于,如何安全、正确的使用这些方案,保证业务正常。对于研发团队来说,针对类似的问题,需要对技术小伙伴进行培训,不断提升技术,更需要重视codereview工作,及时识别风险,避免发生故障造成严重损失(本次故障造成脏数据修复耗时一个多星期)。 敬畏技术,忠于业务。
作者: 十年培训经验的菜包
文章来源: https://c1n.cn/OZvGN
最近在准备面试BAT,特地整理了一份面试资料,覆盖Java核心技术分支、JVM、Java并发、SSM、微服务、数据库、数据结构等等。在这里,我为大家准备了一份2021年最新最全的互联网大厂Java面试经验总结。