由于有一条业务线不理想，高层决定下架业务。对于我们技术团队而言，其对应的所有服务器资源和其他相关资源都要释放。
释放了 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 的代码。
具体步骤如下：
- 通过这些代码统计出 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：
因此，等到了第二天天亮，我睡眼朦胧的看了一下，终于删除完毕了，时间 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
@Beanpublic 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 性能几乎没有影响。性能方面能接受。
总结
通过本次事情，我发现对于大多数开发者而言，差距其实不在于智力，而是在于态度。
