以网盘系统为例讨论redis在类似系统中的应用在网盘系统中Redis绝对不是只用来存“登录态”的。它扮演的是加速缓存、状态暂存和任务协调的核心角色。下面我结合百度网盘的具体功能给你举6个最典型的缓存实例附带具体的Key设计和数据结构1. 用户会话与登录态最基础场景用户登录后7天内免输密码多端登录踢下线。数据结构String 带过期时间TTL。Key设计session:token:{userId}Value存JWT或用户简要信息。示例SET session:token:10001 jwt_xxxx EX 6048007天过期。每次请求进来网关先查Redis若不存在则强制重新登录极大减少对用户表的查询压力。2. 当前文件夹列表缓存防击穿提响应场景用户反复进入某个包含几千个文件的大文件夹每次都查MySQL并排序压力很大。数据结构Sorted Set有序集合利用Score存文件修改时间或文件名拼音。Key设计folder:list:{folderId}。示例ZADD folder:list:888 1700000000 file_123。当用户请求第1页按时间倒序时直接ZREVRANGE folder:list:888 0 19毫秒级返回。注意当用户在该文件夹内新增/删除/重命名文件时需要同步更新这个ZSet保证缓存一致性。3. “秒传”功能的文件指纹库核心业务场景你上传一个电影系统发现服务器里已经有人传过完全相同的文件了基于MD5/SHA-1就不让你真的传数据直接在你网盘里生成一个快捷方式。数据结构String。Key设计file:hash:{md5值}或file:hash:{sha1}。示例SET file:hash:e10adc3949ba59abbe56e057f20f883e master_file_id_999。上传前后端先计算文件的Hash然后GET file:hash:xxx如果查到值直接复用该物理存储地址无需查询MySQL索引库响应速度从几百毫秒降到几微秒。4. 文件分片上传的断点续传状态临时数据场景一个10GB的大文件用户传到一半断网了再次上传时客户端需要知道哪些分片Chunk已经上传成功。数据结构Set或Bitmap位图。Key设计upload:chunks:{uploadId}。示例使用Set存储已上传的分片编号SADD upload:chunks:uuid_001 1 2 3 5。上传中断后客户端请求续传接口Redis返回SMEMBERS upload:chunks:uuid_001客户端就知道跳过第1、2、3、5片从第4片开始重传。注这块数据必须在合并文件完成后立即DEL删除避免垃圾堆积。5. 用户当前实时容量/配额缓存读写频繁场景网盘首页右上角显示“已用 2.3TB / 总空间 5TB”。每上传一个文件这个数值都要变。数据结构Hash。Key设计user:quota:{userId}。示例HSET user:quota:10001 used 2300000000000 total 5000000000000。每次文件上传成功执行HINCRBY user:quota:10001 used 1048576增加文件大小。如果每次都去MySQL的User表累加在并发上传时会产生行锁竞争而Redis单线程原子操作完美避开这个问题。策略每小时或每天再将这个值异步回写MySQL做持久化。6. 全局分布式锁防止并发冲突场景两个用户同时操作同一个共享文件夹或者同一个用户同时重命名父文件夹和子文件夹。数据结构String利用SETNX命令。Key设计lock:folder:{folderId}。示例重命名文件夹时先执行SET lock:folder:888 thread_01 NX EX 10获取锁成功才执行后续复杂的逻辑更新路径、更新子文件path等。如果获取失败直接提示“操作频繁请稍后重试”。这样能避免关系型数据库中产生死锁或脏数据。⚠️ 特别提醒Redis里的数据“会丢”吗允许丢失的数据文件夹列表缓存丢了可以从MySQL重建、分片上传状态丢了用户重新传即可、分布式锁过期自动释放。绝对不能只存Redis的数据秒传的文件Hash索引虽然放在Redis加速但必须同时持久化到MySQL一张独立的file_hash表。因为Redis如果重启且没开启AOF持久化Hash丢失后所有用户再上传同一个文件都会视为“新文件”导致存储空间暴涨。一个最佳实践给不同数据设置合理的TTL过期时间文件夹列表缓存EXPIRE 60010分钟用户不操作自动释放内存。分片上传状态EXPIRE 864001天未完成的上传自动清理。用户容量数据不要设过期手动更新作为实时内存数据库使用。这样配置下来你的MySQL QPS每秒查询数至少能降低70%~80%全部压力量都让Redis扛住了。