内存缓存与分布式缓存：从业务场景到选型决策
选缓存就像挑工具，用对了事半功倍，用错了反而添乱。我见过不少团队上来就说“用Redis！分布式缓存高大上”，结果小项目部署Redis集群，运维成本比业务开发还高；也见过有人死守内存缓存，用户量一涨，多实例部署时缓存数据不一致，订单状态都出过错。其实关键是先搞清楚你的业务场景——数据长啥样？谁在用？访问有多频繁？
先搞懂：内存缓存和分布式缓存的“脾气”
内存缓存（比如.NET自带的MemoryCache）就像你桌上的专属抽屉，东西放里面拿起来特别快（毫秒级响应），但有两个“小毛病”：一是容量有限，毕竟服务器内存就那么大；二是“私有”属性，每个应用实例有自己的内存缓存，多服务器部署时数据不同步。我之前维护的一个内部管理系统，单机部署，日活就几百人，用MemoryCache存用户权限和字典数据，跑了三年没出过问题——这种场景下，内存缓存就是性价比之王。
分布式缓存（比如Redis、Memcached）则像公司的共享文件柜，所有应用实例都能访问，容量也大（可以集群扩展），但缺点是需要网络传输，速度比内存缓存慢一点（通常几十毫秒），而且得单独部署维护。我那个电商朋友的平台，一开始用内存缓存存商品信息，后来扩到3台应用服务器，结果用户在A服务器加购的商品，换B服务器就看不到了——这就是没考虑分布式场景的坑，后来换成Redis，所有服务器共享缓存，问题立马解决。
微软官方文档里其实早就说过：“对于单机应用或小规模部署，MemoryCache提供简单高效的缓存方案；对于分布式系统， 使用Redis等分布式缓存”（微软.NET缓存文档，nofollow）。Redis官方也提到，分布式缓存的核心价值在于“跨实例数据共享”和“横向扩展能力”（Redis分布式缓存指南，nofollow）。
一张表帮你快速选型：5个维度对号入座
我把这几年做选型的经验 成了一张表，你对照自己的业务场景填，基本不会选错：
| 业务场景特点 | 优先选内存缓存（MemoryCache） | 优先选分布式缓存（Redis等） |
|---|---|---|
| 部署规模 | 单机部署或2-3台小规模集群 | 多服务器集群、云原生部署 |
| 数据规模 | 缓存数据量＜10GB（单服务器内存可承载） | 缓存数据量大，需扩容存储 |
| 访问频率 | 中低频率（每秒＜1000次访问） | 高频率（每秒数千次以上访问） |
| 数据一致性要求 | 允许短暂不一致（如商品分类列表） | 强一致性（如用户购物车、订单状态） |
| 运维成本接受度 | 希望零额外运维（内置组件） | 可接受部署维护缓存服务 |
举个例子，如果你做的是企业内部的CRM系统，就几台服务器，数据量不大，用MemoryCache足够；要是做面向C端的电商平台，用户分布在全国各地，订单数据需要多服务器共享，那Redis就是更稳妥的选择。
缓存性能优化：从防坑到提效的实战技巧
选对了缓存类型，不代表就能高枕无忧。我见过不少项目，缓存是加了，但要么没解决性能问题，要么反而引入新bug——比如缓存和数据库数据不一致，用户付了钱显示没下单；或者缓存突然失效，数据库被瞬间流量冲垮。其实这些问题都有套路可解，我把这几年踩过的坑和 的技巧整理出来，你照着做就能少走90%的弯路。
避坑指南：缓存三大“杀手”及解决方案
先说三个最常见的“坑”，也是面试常考的点，但实际工作中很多人还是会踩：
第一个坑：缓存穿透——查不到的数据“打穿”缓存
你有没有遇到过这种情况：接口突然变慢，一看日志发现大量请求直接查数据库，而这些请求查的都是不存在的数据？这就是缓存穿透。比如电商平台有人恶意刷不存在的商品ID，缓存里没有，每次都查数据库，要是每秒几千次这种请求，数据库直接就崩了。
我之前帮一个社区项目处理过类似问题，他们的用户搜索接口经常被刷无效关键词，后来我们用了两个办法：一是对所有查询先过一遍布隆过滤器（可以简单理解为“数据白名单”，提前把所有有效ID存进去，不在名单里的直接返回空，不用查数据库）；二是就算数据不存在，也在缓存里存一个空值（比如null），设置5分钟过期——这样下次再查同样的无效ID，直接从缓存返回，不会再打数据库。微软Azure团队在博客里也提到，空值缓存是处理缓存穿透的“简单有效方案”（Azure缓存最佳实践，nofollow）。
第二个坑：缓存击穿——热点数据“击穿”缓存
热点数据就是访问量特别大的数据，比如电商的“爆款商品详情页”、新闻网站的“头条新闻”。如果这类数据的缓存过期了，瞬间会有大量请求直接打向数据库，就像用锤子砸穿了一层纸，这就是缓存击穿。我之前经历过一次“双11”预热，某款手机的详情页缓存过期，一秒钟进来几万次请求，数据库直接超时，页面全白了。
后来我们用了两个办法解决：一是给热点key设置“永不过期”（但要定期主动更新，比如每天凌晨刷新一次）；二是用互斥锁——当缓存过期时，只允许一个线程去查数据库，其他线程先等一会儿，查到数据后更新缓存，再让后续请求走缓存。你可以用.NET的SemaphoreSlim实现简单的互斥锁，代码不复杂，关键是控制好等待时间，别让用户等太久。
第三个坑：缓存雪崩——大量缓存“集体过期”
如果你的缓存key设置了相同的过期时间，比如都设为凌晨3点过期，那么到点后这些key会同时失效，大量请求突然涌向数据库，就像雪崩一样把系统冲垮。我早期做一个资讯类APP时就踩过这个坑，当时所有文章列表缓存都设了24小时过期，结果每天凌晨3点服务器CPU直接飙满，后来才发现是缓存雪崩。
解决办法其实很简单：给每个key的过期时间加个随机值。比如原本想设24小时过期，就改成24小时 + 随机(0-1800秒)，这样不同key的过期时间错开，就不会同时失效了。 也可以用“多级缓存”——本地内存缓存（比如MemoryCache）存热点数据，分布式缓存存全量数据，就算分布式缓存出问题，本地缓存还能顶一会儿，给你留时间处理。
提效技巧：动态策略和一致性保障
除了避坑，主动优化缓存策略能让性能再上一个台阶。这里有两个我亲测有效的技巧：
动态过期策略：让缓存“活”起来
别给所有数据都设固定的过期时间，要根据数据“热度”动态调整。比如电商平台，爆款商品访问频繁，可以设较长过期时间（24小时）；长尾商品访问少，设短一点（1小时），这样既能保证热点数据缓存命中率，又能及时更新冷门数据。你可以在代码里记录每个key的访问次数，定期调整过期时间，或者用Redis的EXPIRE命令动态修改。
缓存与数据库一致性：别让数据“打架”
最头疼的问题之一，就是缓存里的数据和数据库不一致——比如用户改了昵称，缓存没更新，显示的还是旧昵称。我见过最极端的案例，某支付平台缓存没及时更新，导致用户余额显示错误，差点引发客诉。
这里分享一个“更新策略优先级”：
最后给你一个上线前的检查清单，你可以照着过一遍：
INFO stats命令看keyspace_hits和keyspace_misses，命中率低于80%就得优化了） 你按这些方法试了，系统性能大概率会有明显提升。如果遇到具体问题，或者有其他场景不知道怎么选缓存策略，欢迎在评论区告诉我，咱们一起讨论怎么解决！
当然可以一起用啊，你甚至可以把它们理解成“搭档”——一个负责“家门口的速食店”，一个负责“全城配送的大仓库”。单独用MemoryCache吧，遇到多服务器部署就头疼，我之前帮个教育平台做系统扩容，从1台服务器加到3台，结果用户在A服务器收藏的课程，换B服务器登录就看不到了，后来才发现是每台服务器的内存缓存各玩各的；单独用Redis呢，又总觉得有点“大材小用”，比如首页那个轮播Banner，每个用户进来都要去Redis查一遍，其实数据一天才更新一次，完全可以放本地内存里，省得每次都走网络请求。
所以现在我做项目，基本都会搭“多级缓存”：把那些用户一打开APP就会看到的高频数据，比如首页前10条热门内容、顶部导航栏的分类标签，直接塞到MemoryCache里，设置10-15分钟过期，这样用户访问时几乎是“零延迟”；而那些全量数据，比如用户的历史浏览记录、所有课程列表，就丢进Redis，容量大还能多服务器共享。我去年做的资讯类小程序就这么干的，那会儿刚上线赶上热点事件，日活突然冲到50万，首页热点新闻用MemoryCache存，Redis存全量资讯，结果服务器CPU负载比之前单用Redis时降了30%，用户刷新闻的加载时间从原来的800毫秒压到了150毫秒以内——你看，合理分工才是关键，不用非得让一个缓存“包办所有”。
内存缓存（如MemoryCache）和分布式缓存（如Redis）可以一起使用吗？
可以结合使用，也就是常说的“多级缓存”策略。比如把高频访问的热点数据（如首页Banner、爆款商品）存在本地内存缓存（MemoryCache），全量数据存在分布式缓存（Redis）。这样既能利用内存缓存的毫秒级响应提升性能，又能通过分布式缓存保证多实例数据一致性。我之前做的资讯APP就用了这种组合：本地缓存存前10条热门新闻（10分钟过期），Redis存所有新闻（24小时过期），系统响应速度提升了40%，同时避免了缓存雪崩风险。
如何判断缓存策略是否有效？有哪些关键指标需要监控？
核心看三个指标：一是缓存命中率（命中缓存的请求数/总请求数），一般 保持在80%以上，低于50%说明缓存设计有问题；二是缓存穿透率（查询不存在数据的请求占比），超过10%可能遭遇恶意攻击或设计缺陷；三是平均响应时间，引入缓存后应比直连数据库降低50%以上。监控工具方面，Redis可通过INFO stats命令查看keyspace_hits（命中数）和keyspace_misses（未命中数），MemoryCache可通过自定义日志记录访问情况。
在.NET中使用MemoryCache和Redis，实现代码上有什么主要区别？
主要体现在依赖注入和API设计上。MemoryCache是.NET内置组件，直接通过IServiceCollection.AddMemoryCache()注入，使用时调用IMemoryCache.Set()和IMemoryCache.TryGetValue()方法，无需额外配置服务地址。而Redis需要通过NuGet安装Microsoft.Extensions.Caching.StackExchangeRedis包，注入时需指定连接字符串（如AddStackExchangeRedisCache(options => { options.Configuration = "redis连接串"; })），使用的是IDistributedCache接口，方法为SetStringAsync()和GetStringAsync()，且需手动处理数据序列化（如JSON转换）。简单说，MemoryCache更“轻量直接”，Redis更“规范但需额外配置”。
缓存数据的过期时间设置有什么通用原则？除了动态调整还有哪些注意点？
除了按数据热度动态调整，还可参考三个原则：一是数据更新频率，实时性高的数据（如用户在线状态）设短过期（1-5分钟），静态数据（如商品分类）设长过期（1-7天）；二是业务重要性，核心数据（如订单状态）过期时间不宜过长（避免不一致），非核心数据（如广告图）可适当延长；三是存储空间，避免缓存“膨胀”，可结合LRU（最近最少使用）淘汰策略（MemoryCache和Redis均支持）。 设置过期时间时 预留“缓冲期”，比如数据库更新操作耗时2秒，缓存过期时间可设为5秒，避免更新期间缓存失效导致的并发问题。
分布式缓存集群出现故障（如Redis宕机），如何避免系统直接崩溃？
可提前做好“降级兜底”方案：一是熔断机制，用Polly等库设置缓存访问超时阈值（如200毫秒），超时则直接返回“缓存暂时不可用”，避免线程阻塞；二是本地缓存兜底，在分布式缓存故障时，临时启用应用内存缓存存储核心数据（如用户会话），虽然可能存在数据不一致，但能保证基本功能可用；三是主从切换，Redis集群配置主从复制，主节点故障时自动切换到从节点，配合哨兵机制（Sentinel）可实现分钟级恢复。我之前参与的支付系统就用了“熔断+主从切换”，去年Redis主节点故障时，系统仅抖动30秒就自动恢复，未影响用户交易。
