缓存选型：从本地到分布式，怎么选才不踩坑
选缓存就像挑鞋子，合脚最重要。很多人一开始就盯着Redis这类“大牌”，却忽略了本地缓存的优势；也有人图方便只用sync.Map，结果高并发时内存直接炸了。我 你先搞清楚自己的业务场景——数据访问频率多高？变更多频繁？需不需要跨服务共享？把这些想明白了，选型就不容易出错。
本地缓存：高频低变场景的“性能王者”
本地缓存（比如Go自带的sync.Map、第三方LRU缓存库）最大的优势是快，因为数据存在应用进程内存里，不用走网络IO。但你千万别觉得“快就完事了”，用错场景照样踩坑。我之前在一个日志分析服务里，为了缓存用户最近7天的访问记录，直接用了普通的map+互斥锁，结果并发写的时候锁竞争特别严重，QPS从2000掉到500，后来换成sync.Map才解决问题。这就是典型的“没选对工具”——sync.Map专门优化了读多写少的场景，内置的原子操作比互斥锁更轻量，如果你的数据是“读多写少”，比如商品分类列表、地区编码表这种一天才变一次的数据，用它准没错。
但sync.Map也不是万能的。它没有淘汰策略，数据会一直占着内存，如果你缓存的是大量高频更新的数据，比如用户实时在线状态，内存会越涨越高，最后OOM。这时候就得用LRU（最近最少使用）缓存，比如github.com/hashicorp/golang-lru这个库，它会自动淘汰长时间没访问的数据，控制内存占用。我在一个IM系统里就用了它缓存用户会话信息，设置最大容量10万条，内存稳定在200MB左右，比之前用sync.Map时动不动就飙到1G舒服多了。
分布式缓存：跨服务共享的“协作工具”
如果你的服务是集群部署，或者需要多服务共享数据，本地缓存就搞不定了——总不能每个实例都存一份，数据同步会让你头大。这时候就得上分布式缓存，最常用的就是Redis。但用Redis也有讲究，我见过有人把Redis当“万能缓存”，不管数据大小、访问频率，全往里塞，结果大Value（比如1MB以上的JSON）频繁传输，网络带宽占满，反而拖慢性能。
其实Redis更适合存“小而精”的数据，比如用户Token、购物车信息，单个Value最好控制在10KB以内。 选Redis的时候还要注意集群模式——如果你用的是单机Redis，一旦宕机整个缓存系统就挂了，这时候就得考虑主从复制+哨兵，或者Redis Cluster。我去年帮一个社区项目做缓存改造，他们之前用单机Redis，有次硬盘坏了，缓存全丢，数据库瞬间被打垮，后来改成主从+哨兵，就算主节点挂了，从节点10秒内就能顶上，服务几乎无感。
为了让你更直观地选，我整理了一个表格，对比不同缓存的适用场景，你可以对着看：
| 缓存类型 | 适用场景 | 优点 | 缺点 | 选型 |
|---|---|---|---|---|
| sync.Map | 单实例、读多写少、无淘汰需求 | 无需初始化大小、原子操作、轻量 | 无淘汰策略、不适合大量数据 | 配置表、枚举值缓存 |
| LRU缓存 | 单实例、数据量大、需控制内存 | 自动淘汰冷数据、内存可控 | 实现较复杂、有淘汰开销 | 用户会话、高频访问商品 |
| Redis（单机） | 小规模集群、低可用性要求 | 部署简单、支持多种数据结构 | 单点故障风险、容量有限 | 测试环境、非核心业务 |
| Redis Cluster | 大规模集群、高可用性要求 | 分片存储、自动故障转移 | 部署复杂、有网络开销 | 核心业务、跨服务数据共享 |
小提醒
：选型时别追求“高大上”，我见过一个日活几万的小项目，非要上Redis Cluster，结果运维成本比业务开发还高。你可以先从本地缓存试起，等业务规模上来了，再逐步引入分布式缓存，这样更稳妥。
缓存实战：高并发下的避坑与性能调优技巧
选对了缓存只是第一步，高并发场景下，稍微不注意就会掉进“缓存穿透”“击穿”“雪崩”这些坑里。我之前在一个秒杀系统里，就因为没处理好缓存击穿，导致商品库存查询接口直接被打挂。接下来我就把这些坑的“踩坑实录”和解决方案告诉你，都是实战中验证过的有效方法。
三大经典坑：穿透、击穿、雪崩，怎么防？
先说缓存穿透——简单说就是用户老查不存在的数据，比如故意用一个不存在的商品ID频繁请求，缓存里没有，每次都直接查数据库，数据库压力骤增。我之前遇到过有人恶意刷我们的商品详情接口，用随机ID请求，一天下来数据库被打了几十万次查询，CPU直接跑满。后来我们用了“空值缓存”+“布隆过滤器”组合拳才解决：对不存在的数据，缓存一个空值（比如””），设置短期过期（5-10分钟），同时用布隆过滤器把所有合法的商品ID存起来，请求先过过滤器，不合法的直接返回，根本到不了数据库。
再看缓存击穿——一个热点Key突然过期，这时候大量请求同时进来，全去查数据库，瞬间把数据库打垮。比如秒杀活动的商品Key过期了，几万用户同时点击，数据库肯定扛不住。我之前在处理一个演唱会门票秒杀时就踩过这个坑，当时缓存过期时间设了1小时，结果整点过期时，数据库直接超时。后来用了“互斥锁”方案：缓存过期时，只允许一个请求去查数据库，其他请求等待重试，等数据库查到结果后更新缓存，其他请求再从缓存拿数据。Go里可以用sync.Mutex或者channel实现，不过要注意锁的粒度，别把整个缓存都锁住， 按Key加锁，比如用一个map存每个Key的锁对象。
还有缓存雪崩——大量Key同时过期，或者缓存服务直接挂了，请求全涌向数据库，导致“级联失败”。我见过最惨的一次是Redis集群升级时没做好预案，所有Key同时失效，数据库QPS从平时的1000飙升到5万，直接宕机。预防雪崩有两个关键点：一是过期时间随机化，比如给每个Key的过期时间加个5-10分钟的随机值，避免同时过期；二是熔断降级，用Hystrix或者Go自带的限流器（比如golang.org/x/time/rate），当数据库压力过大时，直接返回默认值或错误，保护核心服务。Go 1.21以后的rate包很好用，我在项目里通常这么配：每秒允许100个请求，最多排队50个，超过就降级，亲测能扛住突发流量。
缓存更新与并发控制：数据一致才是硬道理
缓存和数据库的数据一致性，是很多人头疼的问题。你是不是遇到过“明明数据库改了，缓存还是旧数据”的情况？这多半是缓存更新策略没设计好。常见的更新策略有几种，我给你分析一下利弊，你可以根据业务选：
Cache-Aside（旁路缓存）
：最常用的策略，读的时候先查缓存，没有就查数据库，再回写缓存；写的时候先更新数据库，再删缓存（注意是“删”不是“更新”）。我之前在用户中心项目里就用这个，用户修改资料时，先更新MySQL，再删Redis里的用户Key，下次查询时自动从数据库加载新数据。为什么是“删”不是“更新”？因为如果先更新缓存，再更新数据库，万一数据库更新失败，缓存就是错的；而先更数据库再删缓存，就算删缓存失败，下次查询会重新加载正确数据，风险更低。不过这个策略有个小问题：如果并发写的时候，数据库更新成功了，缓存删除失败，会有短期不一致，这时候可以加个重试机制，或者用消息队列异步删缓存。
Write-Through（写透缓存）：写的时候同时更新缓存和数据库，缓存和数据库强一致。但这个策略性能比较差，每次写都要等两个操作完成，适合对一致性要求极高的场景，比如金融交易。我在一个支付系统里用过，虽然性能损耗了15%左右，但数据一致性得到了保障，出问题的概率小很多。
并发读写时的数据安全也很重要。你有没有遇到过这样的情况：两个goroutine同时读缓存，发现缓存缺失，然后同时查数据库，再同时写缓存，导致重复查询数据库？这就是“缓存并发竞争”。解决办法可以用“double check”+“互斥锁”：第一个goroutine查缓存缺失，加锁，再次检查缓存（防止其他goroutine已经更新了），如果还是缺失再查数据库。代码大概长这样：
func GetData(key string) (Data, error) {
// 第一次查缓存
data, ok = cache.Get(key)
if ok {
return data, nil
}
// 加锁
mu.Lock()
defer mu.Unlock()
// 第二次查缓存（double check）
data, ok = cache.Get(key)
if ok {
return data, nil
}
// 查数据库
data, err = db.Query(key)
if err != nil {
return nil, err
}
// 更新缓存
cache.Set(key, data)
return data, nil
}
这个方法我在多个项目里验证过，能有效减少并发查询数据库的问题，不过要注意锁的开销，别用全局锁，按Key分片加锁更高效。
最后再分享个性能调优的小技巧：缓存预热。如果你的服务刚启动时缓存是空的，大量请求会直接打数据库，这时候可以在服务启动时，主动加载热点数据到缓存。比如电商系统启动时，把销量前100的商品数据加载到本地缓存，能大大减少数据库压力。我之前在一个生鲜电商项目里做过预热，启动时用goroutine并发加载数据，30秒内完成预热，服务启动后缓存命中率直接从0升到85%，数据库负载降了60%。
其实缓存这东西，说难不难，说简单也不简单。关键是要结合业务场景，选对工具，避开那些“隐形坑”。你平时在Go项目里用缓存遇到过什么问题？或者有什么好用的技巧？欢迎在评论区告诉我，咱们一起交流进步！
你知道吗，直接更新缓存特别容易踩坑，我之前在电商项目里就吃过这个亏——当时商品价格改了，我们先更新了Redis缓存，结果数据库更新时突然断网失败了，缓存里存的还是新价格，数据库却是旧价格，用户看到的价格和实际支付价格对不上，客服电话直接被打爆。后来才明白，“先更缓存再更数据库”这个顺序根本不靠谱，万一数据库更新失败，缓存就成了“孤魂野鬼”，存着错误数据。
现在我都用“Cache-Aside（旁路缓存）”这个笨办法，亲测靠谱。读数据的时候，你先去缓存里查，有就直接返回；没有的话就查数据库，查到结果后顺手回写到缓存里，下次再查就快了。写数据的时候更关键，一定要先更新数据库，成功之后再删除缓存，别直接更新缓存。你可能会问，为什么是“删缓存”不是“更缓存”？你想啊，要是先更缓存，数据库更新失败了，缓存里的新数据就永远是错的；但先更数据库再删缓存，就算删除缓存失败了，下次有人查询的时候，发现缓存里没数据，自然会去查数据库，拿到最新的正确数据，再把缓存补回来，相当于“自愈”了。
要是你做的是支付、订单这类对一致性要求特别高的业务，光删缓存可能还不够。我之前在一个支付系统里，订单状态更新后必须保证缓存和数据库完全一致，就加了个“重试机制”——删缓存失败的话，用个小队列存起来，后台线程隔3秒、5秒、10秒重试三次，基本能解决99%的删除失败问题。如果还不放心，还可以用消息队列，比如把“删除缓存”的操作发到Kafka里，消费端确认删除成功才算完事，这样就算缓存服务临时挂了，等它恢复后消息还能重新消费，数据肯定错不了。
本地缓存和分布式缓存应该如何选择？
选择时主要看业务场景：本地缓存（如sync.Map、LRU）适合“高频低变、单实例部署”的场景，比如商品分类列表、地区编码表等一天变更一次的数据，优势是访问速度快（内存操作），但无法跨服务共享；分布式缓存（如Redis）适合“跨服务共享、集群部署”的场景，比如用户购物车、跨服务会话数据，支持数据分片和高可用，但有网络IO开销。 先从本地缓存试起，业务规模扩大后再引入分布式缓存。
sync.Map和LRU缓存有什么区别，分别适合什么场景？
sync.Map是Go内置的并发安全Map，优势是读多写少场景下性能好（原子操作优化锁竞争），但没有淘汰策略，数据会一直占用内存，适合缓存“数据量小、变更频率低”的数据，比如系统配置表、枚举值；LRU（最近最少使用）缓存（如golang-lru库）有自动淘汰策略，会删除长时间未访问的数据，控制内存占用，适合“数据量大、需限制内存”的场景，比如用户会话信息、高频访问的商品详情。
如何避免缓存穿透问题？
缓存穿透是指查询不存在的数据导致请求直达数据库，可通过“空值缓存+布隆过滤器”解决：对不存在的数据缓存空值（如””）并设置短期过期（5-10分钟），避免重复查询；同时用布隆过滤器存储所有合法数据ID（如商品ID），请求先经过过滤器校验，不合法ID直接返回，减少数据库压力。比如恶意请求随机商品ID时，布隆过滤器会直接拦截，无需查询数据库。
缓存和数据库的数据一致性如何保证？
推荐使用“Cache-Aside（旁路缓存）”策略：读操作时先查缓存，未命中则查数据库并回写缓存；写操作时先更新数据库，再删除缓存（而非直接更新缓存）。删除缓存可避免“先更缓存再更数据库”导致的不一致（若数据库更新失败，缓存会存错误数据），即使删除失败，下次查询也会从数据库加载正确数据。若对一致性要求极高，可增加删除缓存重试机制或用消息队列异步删除。
缓存预热有必要吗，具体怎么实现？
缓存预热很有必要，尤其在服务启动或重启后，可避免大量请求直达数据库。实现方法：服务启动时，通过后台goroutine并发加载热点数据到缓存，比如电商系统加载销量前100的商品信息、IM系统加载活跃用户会话。可结合业务设置预热数据范围（如近7天高频访问数据），并控制加载速度（如限制并发数）避免影响服务启动。例如生鲜电商项目中，启动时用10个goroutine并行加载热点商品，30秒内完成预热，缓存命中率从0提升至85%。
