熬了一个通宵,终于把7千万个Key删完了
由于有一条业务线不理想,高层决定下架业务。对于我们技术团队而言,其对应的所有服务器资源和其他相关资源都要释放。

图片来自 Pexels
释放了 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 的定位难度很大。
通过这些代码统计出 Key 的前缀并录入到文本中。
通过 Python 脚本把载入文中中的的 Key 并在后面加上“*”通配符。
通过 Python 脚本通过 Scan 命令扫描出这些 Key。
为了便于检查,我们并没有直接使用 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:

知耻而后勇
从来没有经历过因业务下线而清除资源的经验。这次事情真心让我觉得细微之处见真功夫的道理。
如果一开始我们就能够遵循开发规范来使用和设计 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;
}
总结
通过本次事情,我发现对于大多数开发者而言,差距其实不在于智力,而是在于态度。
比如这次事件暴露出来的问题:大家都知道要遵循开发规范,然而到了真正“打仗”的时候,负责这个项目的开发者却没有几个人能始终如一的做好这些细微之事。
另外,Reviewer 的工作其实是极其重要的,他就像那“纪检委”,如果“纪检委”都放水睁一只眼闭一只眼,那麻烦可就大了!千里之提,毁于日常的点滴松懈啊!
经过这次事件之后,如果上天再给一次这样的机会,我一定会对项目经理说:接着奏乐,接着舞!
作者:浪漫先生
编辑:陶家龙
出处:https://juejin.im/post/5f18423fe51d453493113f5c

精彩文章推荐:
关注公众号:拾黑(shiheibook)了解更多
[广告]赞助链接:
四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/
关注网络尖刀微信公众号随时掌握互联网精彩
- 1 中央经济工作会议在北京举行 7904607
- 2 紧急提醒:请在日中国公民进行登记 7807916
- 3 中央定调明年继续“国补” 7713131
- 4 “九天”无人机成功首飞 7617440
- 5 断崖式降温!今冬最强寒潮来了 7521011
- 6 中央经济工作会议释信号:3件事不做 7428128
- 7 中国“空中航母”首飞成功 7331383
- 8 88岁爷爷机场接孙女几度认不出 7234324
- 9 人民空军中日双语发文:大惊小怪 7143259
- 10 寒潮来袭 “速冻”模式如何应对 7039596







51CTO技术栈
