服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

朋友公司的 Redis 集群监控上 used_memory 才 4GB，但 used_memory_rss 已经到了 8GB——是 used 的两倍。运维加了内存，过两个月又一样。最离谱的是有一次 used_memory 只有 2GB，Redis 却报了 OOM。排查发现内存碎片率 3.5，8GB 的物理内存被碎片占了一半多。 这就是 Redis 的内存碎片问题。used_memory 是你存进去的有用数据，used_memory_rss 是 Redis 实际向操作系统申请的内存。两者之间的差，就是碎片。 今天聊聊怎么用 Redis 自带的内存碎片整理和对象复用，把碎片率降到 1.1 以下。 碎片怎么来的 Redis 的内存分配是 jemalloc 管理的。当你反复写入和删除不同大小的 Key，就会出现这样的场景： 内存布局（简化）： |AAAA| 空闲 |BB| 空闲 |CCCC| 空闲 |DD| 空闲 |... 删掉的 Key 留下的空隙不够大，放不下新的 Key。新 Key 只能往后申请新内存。结果就是 used 没涨多少，rss 一直涨。 碎片率计算公式： mem_fra....

一、文件上传 OOM 的痛点 上个月，我的一个电商系统客户遇到了严重的生产事故：系统在处理用户上传的商品图片时，突然出现了 OOM（内存溢出）崩溃。 "我们的系统每天都要处理大量的图片上传，"客户焦急地说，"昨天有用户上传了几个 100MB 以上的大文件，直接导致服务器内存溢出，整个服务都崩溃了。" 我查看了他们的代码，发现问题确实很严重： 使用了 Spring Boot 默认的文件上传配置 上传的文件直接存储在内存中 没有对文件大小进行合理限制 没有使用流式处理，而是一次性读取整个文件 系统内存只有 4GB，根本无法处理大文件 更关键的是，他们根本不知道有多少用户正在上传大文件，也无法及时发现和处理这种内存风险。 二、传统方案的局限性 1. 默认配置上传 使用 Spring Boot 默认的文件上传配置。 @PostMapping("/upload") public String upload(@RequestParam("file") MultipartFile file) throws IOException { byte[] bytes = file.getBytes();....