如何做免费企业网站,wordpress邮箱头像,吕梁市城乡建设局网站,网站服务器中如何做重定向由于有一条业务线不理想#xff0c;高层决定下架业务。对于我们技术团队而言#xff0c;其对应的所有服务器资源和其他相关资源都要释放。释放了 8 台应用服务器#xff1b;1 台 ES 服务器#xff1b;删除分布式定时任务中心相关的业务任务#xff1b;备份并删除 MySQL 数…由于有一条业务线不理想高层决定下架业务。对于我们技术团队而言其对应的所有服务器资源和其他相关资源都要释放。释放了 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,count2000)return keys_listexcept Exception,e:print eRedis 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_listexcept 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因此等到了第二天天亮我睡眼朦胧的看了一下终于删除完毕了时间 0713早高峰即将来临……知耻而后勇从来没有经历过因业务下线而清除资源的经验。这次事情真心让我觉得细微之处见真功夫的道理。如果一开始我们就能够遵循开发规范来使用和设计 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;}Overridepublic 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);}Overridepublic 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: truekey: E00P01
Bean
public RedisTemplateString, Object redisTemplate(RedisConnectionFactory redisConnectionFactory) {RedisTemplateString, Object redisTemplate new RedisTemplate();redisTemplate.setConnectionFactory(redisConnectionFactory);// 支持key前缀设置的key SerializerredisTemplate.setKeySerializer(new PrefixStringKeySerializer());redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer());return redisTemplate;
}通过以上方式我们至少可以从项目维度来区分出 Key避免了多个项目之间共用同一个集群时而导致重复 Key 的问题。从项目维度对 Key 进行了划分。更方便管理和运维。如果对于 Key 的管理粒度要求更细我们甚至可以细化到具体业务维度。我们在测试环境进行了压测增加 Key 前缀对 Redis 性能几乎没有影响。性能方面能接受。总结通过本次事情我发现对于大多数开发者而言差距其实不在于智力而是在于态度。比如这次事件暴露出来的问题大家都知道要遵循开发规范然而到了真正“打仗”的时候负责这个项目的开发者却没有几个人能始终如一的做好这些细微之事。另外Reviewer 的工作其实是极其重要的他就像那“纪检委”如果“纪检委”都放水睁一只眼闭一只眼那麻烦可就大了千里之提毁于日常的点滴松懈啊经过这次事件之后如果上天再给一次这样的机会我一定会对项目经理说接着奏乐接着舞编辑浪漫先生
