熬了一个通宵，终于把7千万个Key删完了！

时间  2020-08-21 标签 一个 通宵 终于 千万个 key 完了

因为有一条业务线不理想，高层决定下架业务。对于咱们技术团队而言，其对应的全部服务器资源和其余相关资源都要释放。redis

释放了 8 台应用服务器；1 台 ES 服务器；删除分布式定时任务中心相关的业务任务；备份并删除 MySQL 数据库；删除 Redis 中相关的业务缓存数据。spring

CTO 指名点姓让我带头冲锋，才扣了我绩效……好吧，冲~数据库

其余都还好，很少时就解决了。惟独这删除 Redis 中的数据，害得我又熬了一个通宵，真是折煞我也！缓存

难点分析服务器

共用 Redis 服务集群运维

因为这条业务线的数据在 Redis 大概在 3G 左右，彻底不必单独建一个 Redis 服务集群，本着能节约就节约的态度，当初就决定和其余项目共享一个集群（这个集群配置：16 个节点，128G 内存，还算豪华吧~）分布式

集群配置以下：

ced13826458e4b1caf4548403b11201c

在这种共用集群的状况下，致使没法简单粗暴的释放。所以只能选择删除 Key 的方式。ide

Key 命名不规范spring-boot

要删除 Key，首先就要精准的定位出哪些 Key 须要删除，若是勿删 Key，会影响到其余服务正常运转！性能

若是 Key 自己设置了过时时间，但有些数据需是持久化的。然而那该死的项目经理一直催项目进度，致使开发人员在开发过程当中不少地方都没有设计到位。

好比 Redis Key 散落在项目代码的每一个角落；好比命名不是很规范。

真不知道是怎么 Review 代码！哦，想必是没有时间 Review，那该死的项目经理……

我随便截个支付服务中的 Key 命名：

65af026e27d1470890d35bb9c0afecc9

怎么样？是否是以为咱们开发人员写的代码很 Low！别笑，在实际工做中，还有比这更 Low 的！但愿你别遇到，否则真的很痛苦~

解决思路

通过以上的分析，咱们简单概括以下：

  • 咱们真正关心的是那些未设置过时时间的 Key。

  • 不能误删除 Key，不然下个月绩效也没了。

  • 因为 Key 的命名及使用及其不规范，致使 Key 的定位难度很大。

看来，经过 Scan 命令扫描匹配 Key 的方式行不通了。只能经过人肉搜索了。

幸而 Idea 的搜索大法好，这个项目中使用的是 spring-boot-starter-data-redis。

所以我经过搜索 RedisTemplate 和 StringRedisTemplate 定位全部操做 Redis 的代码。

具体步骤以下：

  • 经过这些代码统计出 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：

 

5a4c51abc1594caa8327e38c2da3876a

所以，等到了次日天亮，我睡眼朦胧的看了一下，终于删除完毕了，时间 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 的工做实际上是极其重要的，他就像那“纪检委”，若是“纪检委”都放水睁一只眼闭一只眼，那麻烦可就大了！千里之提，毁于平常的点滴松懈啊！

通过此次事件以后，若是上天再给一次这样的机会，我必定会对项目经理说：接着奏乐，接着舞！

联系我们 沪ICP备13005482号-10