百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术教程 > 正文

Redis——熬了一个通宵终于把Key删完了

mhr18 2024-11-11 11:55 18 浏览 0 评论

前言

??由于有一条业务线不理想,高层决定下架业务。对于我们技术团队而言,其对应的所有服务器资源和其他相关资源都要释放。释放了8台应用服务器;1台es服务器;删除分布式定时任务中心相关的业务任务;备份并删除MySQL数据库;删除Redis中相关的业务缓存数据。CTO指名点姓让我带头冲锋,才扣了我绩效……好吧,冲~ 其他都还好,不多时就解决了。唯独这删除Redis中的数据,害得我又熬了一个通宵,真是折煞我也!

难点分析

共用Redis服务集群

??由于这条业务线的数据在Redis大概在3G左右,完全没必要单独建一个Redis服务集群,本着能节约就节约的态度,当初就决定和其他项目共享一个集群(这个集群配置:16个节点,128G内存,还算豪华吧~)集群配置如下:


??在这种共用集群的情况下,导致无法简单粗暴的释放。因此只能选择删除Key的方式。


Key命名不规范

??要删除Key,首先就要精准的定位出哪些Key需要删除,如果勿删Key,会影响到其他服务正常运转!如果Key本身设置了过期时间,但有些数据需是持久化的。然而那该死的项目经理一直催项目进度,导致开发人员在开发过程中很多地方都没有设计到位,比如Redis Key散落在项目代码的每个角落;比如命名不是很规范。真不知道是怎么review代码!哦,想必是没有时间review,那该死的项目经理…… 我随便截个支付服务中的Key命名:



??怎么样?是不是觉得我们开发人员写的代码很low~别笑,在实际工作中,还有比这更low的!希望你别遇到,不然真的很痛苦~

解决思路

??经过以上的分析,我们简单归纳如下:

  • 我们真正关心的是那些未设置过期时间的Key
  • 不能误删除Key,否则下个月绩效也没了
  • 由于Key的命名及使用及其不规范,导致Key的定位难度很大

看来,通过scan命令扫描匹配Key的方式行不通了。只能通过人肉搜索了~ 幸而Idea的搜索大法好,这个项目中使用的是spring-boot-starter-data-redis.因此我通过搜索RedisTemplate和StringRedisTemplate定位所有操作redis的代码,具体步骤如下: 1.通过这些代码统计出Key的前缀并录入到文本中; 2.通过python脚本把载入文中中的的Key并在后面加上“*”通配符; 3.通过python脚本通过scan命令扫描出这些key; 4.为了便于检查,我们并没有直接使用del命令删除key,在删除key之前,先通过debug object key的方式得到其序列化的长度,再执行删除并返回序列化长度。这样,我们就可以统计出所有key的序列化长度来得到我们释放的空间大小。 关键代码如下:

def get_key(rdbConn,start):
    try:
    keys_list = rdbConn.scan(start,count=2000)
    return keys_list
    except Exception,e:
    print e

''' Redis DEBUG OBJECT command got key info '''
def get_key_info(rdbConn,keyName):
    try:
    rpiple = rdbConn.pipeline()
    rpiple.type(keyName)
    rpiple.debug_object(keyName)
    rpiple.ttl(keyName)
    key_info_list = rpiple.execute()
    return key_info_list
    except Exception,e:
    print "INFO : ",e

def redis_key_static(key_info_list):
    keyType = key_info_list[0]
    keySize = key_info_list[1]['serializedlength']
    keyTtl = key_info_list[2]
    key_size_static(keyType,keySize,keyTtl)
复制代码

??通过以上方式,能够统计出究竟释放了多少内存了。 ??由于这个集群是有这么接近7千万个key:


??因此,等到了第二天天亮,我睡眼朦胧的看了一下,终于删除完毕了,时间07:13...早高峰即将来临……


知耻而后勇

?从来没有经历过因业务下线而清除资源的经验。这次事情真心让我觉得细微之处见真功夫的道理。如果一开始我们就能够遵循开发规范来使用和设计redis key,也不至于浪费这么多时间。为了让key的命名和使用更加规范,以及今后避免再次遇到这种情况,下午睡醒之后,我就在redis公共组件库里面添加了一个配置和自定义了key序列化,代码如下:


@ConfigurationProperties(prefix = "spring.redis.prefix")
public class RedisKeyPrefixProperties {
	private Boolean enable = Boolean.TRUE;
	private String key;
	public Boolean getEnable() {
		return enable;
	}
	public void setEnable(Boolean enable) {
		this.enable = enable;
	}
	public String getKey() {
		return key;
	}
	public void setKey(String key) {
		this.key = key;
	}
}
复制代码
/**
 * @desc 对字符串序列化新增前缀
 * @author create by liming sun on 2020-07-21 14:09:51
 */
public class PrefixStringKeySerializer extends StringRedisSerializer {
    private Charset charset = StandardCharsets.UTF_8;
    private RedisKeyPrefixProperties prefix;
    
    public PrefixStringKeySerializer(RedisKeyPrefixProperties prefix) {
    	super();
    	this.prefix = prefix;
    }
    
    @Override
    public String deserialize(@Nullable byte[] bytes) {
    	String saveKey = new String(bytes, charset);
    	if (prefix.getEnable() != null && prefix.getEnable()) {
    		String prefixKey = spliceKey(prefix.getKey());
    		int indexOf = saveKey.indexOf(prefixKey);
    		if (indexOf > 0) {
    			saveKey = saveKey.substring(indexOf);
    		}
    	}
    	return (saveKey.getBytes() == null ? null : saveKey);
    }
    
    @Override
    public byte[] serialize(@Nullable String key) {
    	if (prefix.getEnable() != null && prefix.getEnable()) {
    		key = spliceKey(prefix.getKey()) + key;
    	}
    	return (key == null ? null : key.getBytes(charset));
    }
    
    private String spliceKey(String prefixKey) {
    	if (StringUtils.isNotBlank(prefixKey) && !prefixKey.endsWith(":")) {
    		prefixKey = prefixKey + "::";
    	}
    	return prefixKey;
    }
}
复制代码

使用效果

??为了避免再次发生这种工作低效而又不得不做的事情,我们在开发规范中规定,新项目中redis的使用必须设置此配置,前缀就设置为:项目编号。另外,一个模块中的key必须统一定义在二方库的RedisKeyConstant类中。配置如下:

spring: 
    redis: 
        prefix:
            enable: true
            key: E00P01
复制代码
@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
    RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
    redisTemplate.setConnectionFactory(redisConnectionFactory);
    // 支持key前缀设置的key Serializer
    redisTemplate.setKeySerializer(new PrefixStringKeySerializer());
    redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer());
    return redisTemplate;
}
复制代码

??通过以上方式,我们至少可以从项目维度来区分出key,避免了多个项目之间共用同一个集群时而导致重复key的问题。从项目维度对key进行了划分。更方便管理和运维。如果对于key的管理粒度要求更细,我们甚至可以细化到具体业务维度。我们在测试环境进行了压测,增加key前缀对redis性能几乎没有影响。性能方面能接受。

总结

??通过本次事情,我发现对于大多数开发者而言,差距其实不在于智力,而是在于态度。比如这次事件暴露出来的问题:大家都知道要遵循开发规范,然而到了真正“打仗”的时候,负责这个项目的开发者却没有几个人能始终如一的做好这些细微之事。另外,reviewer的工作其实是极其重要的,他就像那“纪检委”,如果“纪检委”都放水睁一只眼闭一只眼,那麻烦可就大了!千里之提,毁于日常的点滴松懈啊~~~ ??经过这次事件之后,如果上天再给一次这样的机会,我一定会对项目经理说:接着奏乐,接着舞~

分享一些我个人的学习文档,有需要的朋友自行选择获取1、面试文档专题整理

既然是要面试,那么就少不了刷题,实际上春节回家后,哪儿也去不了,我自己是刷了不少面试题的,所以在面试过程中才能够做到心中有数,基本上会清楚面试过程中会问到哪些知识点,高频题又有哪些,所以刷题是面试前期准备过程中非常重要的一点。

根据自身面试经历整理以及不断收集的(珍藏版)

相关的电子书、底层源码



阿里巴巴必备学习知识点

资料获取方式:转发和评论这篇文章,然后关注小编,后台私信【面试资料】即可打包带走所有资料~

相关推荐

如何通过 Redis 日志排查连接超时问题

Redis是一种高性能的内存数据存储服务,但在高并发或误配置情况下,可能会出现连接超时问题。借助Redis日志,可以快速定位并解决连接超时的根本原因。以下是具体的排查和解决步骤:1.什么是R...

给你1亿的Redis key,如何高效统计?

前言有些小伙伴在工作中,可能遇到过这样的场景:老板突然要求统计Redis中所有key的数量,你随手执行了KEYS*命令,下一秒监控告警疯狂闪烁——整个Redis集群彻底卡死,线上服务大面积瘫痪。今天...

Redis分布式锁的安全性分析与实践指南

一、Redis分布式锁的核心原理Redis分布式锁通过SETNX(SetifNotExists)和EXPIRE(Expire)指令实现原子性操作,结合UUID生成唯一标识符,确保锁的互斥性和安全...

高可用Redis分布式锁:秒杀系统中的锁战

引言在分布式系统中,“程序猿的终极武器是并发控制”。当多个服务实例同时访问共享资源时,如何避免数据不一致和重复操作?答案是分布式锁。Redis凭借其高性能和原子性操作,成为实现分布式锁的首选方案。...

Redis分布式锁(redis分布式锁解决超卖)

场景描述简单模拟一个高并发库存扣减场景,商品库存加载到Redis缓存,如:127.0.0.1:6379>setproduct:stock:101200无锁状态操作从缓存中获取对应商品的库存...

Redis 分布式锁和 ZooKeeper分布式锁

Redis分布式锁和ZooKeeper(简称zk)分布式锁都是用来解决在分布式系统中多个节点之间竞争资源的问题。它们各自有不同的特点和适用场景。Redis分布式锁Redis实现分布式锁主要是...

Redis vs ZooKeeper锁:高并发下的生死对决,谁才是最终赢家?

在分布式系统中,锁是控制资源访问的重要机制。Redis和ZooKeeper作为两种主流的分布式锁实现方案,各有优劣。本文将从原理、性能、代码实现三个维度进行硬核对比,助你做出最佳技术选型。一、原理对比...

说说Redis的大key(redis key大小限制)

一句话总结Redis大key指存储超大值(如字符串过大、集合元素过多)的键。主要成因包括:1.设计不合理,未拆分数据结构;2.业务需求(如缓存整页数据);3.数据持续积累未清理;4.使用不当的集合类型...

PHP Laravel框架底层机制(php框架的底层原理)

当然可以,Laravel是最受欢迎的PHP框架之一,以优雅的语法和丰富的生态而闻名。尽管开发体验非常“高端”,它的底层其实是由一系列结构清晰、职责分明的组件构成的。下面我从整体架构、核心流程、...

PHP性能全面优化-值得收藏(php优化网站性能)

PHP项目卡顿频发,老技巧失灵?隐藏漏洞竟在代码循环里。上周公司服务器突然开始卡顿,测试发现用户请求响应时间翻倍。我们先按以前学的方法做了基准测试,用AB工具压测时发现2000并发就有5%错误,换成S...

PHP+UniApp:低成本打造外卖系统横扫App+小程序+H5全平台

在餐饮行业数字化转型中,外卖系统开发常面临两大痛点:高昂的开发成本(需独立开发App、小程序、H5)和多端维护的复杂性。PHP+UniApp的组合通过技术复用与跨平台能力,为中小商家和开发者提供了“降...

从需求到上线:PHP+Uniapp校园圈子系统源码的架构设计与性能优化

一、需求分析与架构设计1.核心功能需求用户体系:支持手机号/微信登录、多角色权限(学生、教师、管理员)。圈子管理:支持创建/加入兴趣圈子(如学术、电竞)、标签分类、动态发布与审核。实时互动:点赞、评...

PHP 8.0性能翻3倍?四年亲测:这些项目升了哭晕!

2020年那个感恩节,当PHP8.0带着“性能翻倍”的豪言横空出世时,无数程序员连夜备份代码准备升级。四年过去了,那些宣称“性能提升3倍”的项目,真的跑出火箭速度了吗?还记得当时铺天盖地的宣传吗?“...

我把 Mac mini 托管到机房了:一套打败云服务器的终极方案

本内容来源于@什么值得买APP,观点仅代表作者本人|作者:薯仔不爱吃薯仔我把我积灰的Macmini托管到机房了,有图有真相。虽然画质又渣又昏暗,但是!这就是实锤。作为开发者,谁不想拥有个自己的服...

从phpstudy到Docker:我用一个下午让开发效率翻倍的实战指南

一、为什么放弃phpstudy?上周三下午,我花了3小时将本地开发环境从phpstudy迁移到Docker,没想到第二天团队反馈:环境部署时间从2小时压缩到5分钟,跨设备协作bug减少70%。作为一个...

取消回复欢迎 发表评论: