Redis 分布式锁遇到的序列化问题

Redis 分布式锁遇到的序列化问题

作者: jaxer 2021-03-24 08:41:38

开发

前端

分布式

Redis 最近使用 Redis 遇到了一个类似分布式锁的场景,跟 Redis 实现分布式锁类比一下,就是释放锁失败,也就是缓存删不掉。又踩了一个 Redis 的坑……本文主要对此做个复盘。

[[389269]]

场景描述

最近使用 Redis 遇到了一个类似分布式锁的场景,跟 Redis 实现分布式锁类比一下,就是释放锁失败,也就是缓存删不掉。又踩了一个 Redis 的坑……

这是什么个情况、又是怎样排查的呢?

本文主要对此做个复盘。

问题排查

既然是释放锁有问题,那就先看看释放锁的代码吧。

释放锁

释放锁使用了 Lua 脚本,代码逻辑和 Lua 脚本如下:

释放锁示例代码

  1. public Object release(String key, String value) { 
  2.   Object existedValue = stringRedisTemplate.opsForValue().get(key); 
  3.   log.info("key:{}, value:{}, redis旧值:{}"key, value, existedValue); 
  4.    
  5.   DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>(COMPARE_AND_DELETE, Long.class); 
  6.   return stringRedisTemplate.execute(redisScript, Collections.singletonList(key), value); 

释放锁使用的 Lua 脚本

  1. if redis.call('get',KEYS[1]) == ARGV[1] 
  2. then 
  3.     return redis.call('del',KEYS[1]) 
  4. else 
  5.     return 0 
  6. end

删除脚本中,会先获取 Redis key 的旧值,并与入参 value 比较,二者相等时才会删除。

如果释放成功,也就是 Redis 缓存删除成功,返回值为 1,否则失败返回为 0。

乍一看代码似乎没啥问题,测一下试试?

不过既然要释放锁,在此之前肯定要加锁,先看看加锁的逻辑吧。

加锁

说到加锁这里的逻辑,代码里有两种实现方式:

示例代码一

  1. public Object lock01(String key, String value) { 
  2.   log.info("lock01, key={}, value={}"key, value); 
  3.   return redisTemplate.opsForValue().setIfAbsent(key, value, LOCKED_TIME, TimeUnit.SECONDS); 

示例代码二

  1. public Object lock02(String key, String value) { 
  2.   log.info("lock02, key={}, value={}"key, value); 
  3.   return stringRedisTemplate.opsForValue().setIfAbsent(key, value, LOCKED_TIME, TimeUnit.SECONDS); 

其实它们的区别就在于前者使用了 RedisTemplate,而后者使用的是 StringRedisTemplate。

  • Q: 等等……为什么会有两个 template??
  • A: 憋说了,是我挖的坑,RedisTemplate 是我加的……现在回想都没想明白当初为什么这样搞,可能真是脑子一时抽风了。

先测试一下这两个方法?

测试一下

使用两种方式分别加锁,其中:lock01 为 k1 和 v1,lock02 为 k2 和 v2。

分别看下 k1、k2 的值(使用工具:RDM, Redis Desktop Manager):

可以看到 v1 是有双引号的,而 v2 没有。

猜测应该是序列化的问题,看看 Redis 配置?

RedisTemplate 配置

加锁那里可以看到,k1 使用了 RedisTemplate,而 k2 是 StringRedisTemplate,它们两个的配置有什么区别呢?

其中 RedisTemplate 的配置是自定义的,如下:

  1. @Configuration 
  2. @AutoConfigureAfter(RedisAutoConfiguration.class) 
  3. public class RedisConfig { 
  4.   @Bean 
  5.   public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) { 
  6.     RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>(); 
  7.     redisTemplate.setConnectionFactory(redisConnectionFactory); 
  8.  
  9.     // 使用 Jackson2JsonRedisSerialize 替换默认序列化 
  10.     Jackson2JsonRedisSerializer<Object> jackson2JsonRedisSerializer 
  11.         = new Jackson2JsonRedisSerializer<>(Object.class); 
  12.  
  13.     ObjectMapper objectMapper = new ObjectMapper(); 
  14.     objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY); 
  15.     objectMapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL); 
  16.     objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); 
  17.  
  18.     jackson2JsonRedisSerializer.setObjectMapper(objectMapper); 
  19.  
  20.     // 设置 key、value 的序列化规则(尤其是 value) 
  21.     redisTemplate.setKeySerializer(new StringRedisSerializer()); 
  22.     redisTemplate.setValueSerializer(jackson2JsonRedisSerializer); 
  23.     redisTemplate.afterPropertiesSet(); 
  24.  
  25.     return redisTemplate; 
  26.   } 

StringRedisTemplate 的配置是 SpringBoot 默认的,即:

  1. @Configuration 
  2. @ConditionalOnClass({RedisOperations.class}) 
  3. @EnableConfigurationProperties({RedisProperties.class}) 
  4. @Import({LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class}) 
  5. public class RedisAutoConfiguration { 
  6.   public RedisAutoConfiguration() { 
  7.   } 
  8.  
  9.   @Bean 
  10.   @ConditionalOnMissingBean 
  11.   public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) throws UnknownHostException { 
  12.     StringRedisTemplate template = new StringRedisTemplate(); 
  13.     template.setConnectionFactory(redisConnectionFactory); 
  14.     return template; 
  15.   } 

PS: SpringBoot 版本为 2.1.13.RELEASE

点进去 StringRedisTemplate 看下:

  1. public class StringRedisTemplate extends RedisTemplate<String, String> { 
  2.      
  3.   public StringRedisTemplate() { 
  4.     // 注意这里的序列化设置 
  5.     setKeySerializer(RedisSerializer.string()); 
  6.     setValueSerializer(RedisSerializer.string()); 
  7.     setHashKeySerializer(RedisSerializer.string()); 
  8.     setHashValueSerializer(RedisSerializer.string()); 
  9.   } 
  10.   // ... 

注意下序列化设置,继续跟进,看到底是什么方式:

  1. public interface RedisSerializer<T> { 
  2.   static RedisSerializer<String> string() { 
  3.     return StringRedisSerializer.UTF_8; 
  4.   } 

  1. public class StringRedisSerializer implements RedisSerializer<String> { 
  2.   public static final StringRedisSerializer UTF_8 = new StringRedisSerializer(StandardCharsets.UTF_8); 
  3.     // ... 

可以看到,StringRedisTemplate 的 key 和 value 默认都是用 StringRedisSerializer(StandardCharsets.UTF_8) 进行序列化的。

而 RedisTemplate 的 key 使用 StringRedisSerializer,value 使用的是 Jackson2JsonRedisSerializer 序列化(至于为什么用这个,这里就不是我写的了)。

到这里,基本可以定位到问题所在了:就是 RedisTemplate 的 value 序列化和 StringRedisTemplate 不一致。

如果改成一致就可以了吗?验证一下试试。

验证推论

把 RedisTemplate 的 value 序列化方式修改为 StringRedisSerializer:

  1. @Configuration 
  2. @AutoConfigureAfter(RedisAutoConfiguration.class) 
  3. public class RedisConfig { 
  4.   @Bean 
  5.   public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) { 
  6.     RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>(); 
  7.        
  8.     // ... 
  9.  
  10.     redisTemplate.setKeySerializer(new StringRedisSerializer()); 
  11.     redisTemplate.setValueSerializer(new StringRedisSerializer()); 
  12.  
  13.     // ... 
  14.     return redisTemplate; 
  15.   } 

再调用两种加锁逻辑,看下 k1、k2 的值:

可以看到,v1 的双引号没了,释放锁的服务也能正常删掉了。

嗯,就是这里的问题。

至于两者序列化的源码,有兴趣的盆友们可以继续研究,这里就不再深入探讨了。

小结

本文遇到的这个问题,主要是因为使用了不同的 RedisTemplate 来加锁和释放锁,而这两个 template 使用了不同的序列化方式,最终还是序列化带来的问题。

当初真是草率了,而且一时还没测出来……

对于生产环境,还是要慎之又慎:如临深渊,如履薄冰。

 

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/295353.html<

(0)
管理的头像管理
上一篇2025-05-21 12:23
下一篇 2025-05-21 12:24

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注