计算机视觉网站扩容难？三步清除存储冗余

文章配图，仅供参考

　　咖啡凉了都没顾上喝，先翻监控。发现个怪事：存储总量看着没超，但某些目录的inode用满到99%——全是些小文件，几KB的模型版本、中间结果、测试图片，堆得跟垃圾场似的。我原以为这些文件会自动清理，结果运维同事老李说："谁敢删？怕影响线上服务啊！" 可说白了，这不就是典型的"存储冗余"？用户上传的测试数据、模型训练的临时文件、甚至前端传错的图片，全攒着，扩容能有用才怪。

　　窗外天黑了，我一边敲命令删文件，一边跟产品经理吐槽："你们要的'数据留存策略'呢？用户上传的测试图片，留三个月够了吧？模型训练的中间结果，留最新三个版本不行？" 产品经理挠头："用户说怕数据丢，我们不敢删..." 我差点把键盘敲烂："那你们倒是给个清理规则啊！现在存储满了，用户连新数据都传不了，这不是更丢数据？"

　　手机亮了一下，是测试组的消息："哥，存储满了，自动化测试挂了一片。" 我回了个"知道了"，转头继续删文件。突然想到个问题：这些冗余文件到底从哪来的？翻日志发现，前端代码里有个接口，用户上传图片后，不管成功失败，都会在本地存一份；模型训练的脚本更离谱，每次运行都生成个新目录，里面全是中间结果，连失败的任务都不删。我跟前端小王喊："你们这代码是按'存着总比删了强'写的？" 他挠头："怕用户重试时找不到原文件..." 我拍桌子："那用户重试的概率有1%吗？你们存了99%的垃圾！"

　　其实解决这问题，根本不用搞什么复杂扩容。我总结了"三步法"：第一步，先定规则——哪些文件必须留（比如用户主动保存的模型）、哪些可以删（比如临时生成的中间结果）；第二步，加清理逻辑——训练任务成功就删中间目录，用户上传失败就删临时文件；第三步，监控兜底——inode使用率超过80%就报警，自动触发清理脚本。说白了，就是"优胜劣汰"：有用的留着，没用的滚蛋。

　　但实施起来哪有这么顺？老李说："清理脚本万一误删怎么办？" 我怼他："那你说现在存储满了怎么办？用户连新数据都传不了，这不是更大的事故？" 他不说话了。后来我们折中：先在测试环境跑清理脚本，跑了一周没出错，才敢上生产。结果你猜怎么着？存储使用率直接从95%掉到60%，QPS没降，用户也没投诉——因为那些冗余文件根本没人用。

　　键盘声突然变响，是隔壁工位的新人在敲代码。我转头看他屏幕，好家伙，又在写"存着总比删了强"的逻辑——用户上传文件后，先存本地，再存对象存储，失败了还重试三次，每次重试都生成新文件。我喊："你这代码上了生产，存储又得满！" 他抬头："啊？那怎么办？" 我叹气："先学学'三步法'吧，别等存储满了再哭。"

　　现在回头看，这事儿最气人的不是技术问题，是大家都在"怕"。前端怕用户重试，产品怕用户投诉，运维怕误删，结果全攒着垃圾文件，把存储撑爆。其实计算机视觉网站扩容难，很多时候不是硬件不够，是"存储冗余"太狠——优胜劣汰的规则没定好，有用的没用的全混在一起，扩容能有用才怪。

　　不过话说回来，我现在也不确定这"三步法"是不是万能。比如清理脚本的触发条件，是按时间（比如三个月前的文件）还是按使用率（比如inode超过80%）？或者两者结合？老李说："得看业务场景。" 我点头："对，但至少得有个规则，不能全靠'怕'来决定存不存。" 他笑："那你去跟产品说？" 我摆手："算了，我先去喝口热咖啡——这破事儿，够我吐槽到明年端午了。"

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!