建议收藏：缓存架构 灰度发布 | 面试高频

我直接上干货。缓存架构设计和灰度发布，是两个在实际项目中必须认真对待的环节。缓存架构设计得不好，系统易变慢，甚至崩溃。灰度发布没做好，可能把新功能砸到生产环境，导致用户数据出问题。这两块东西，得用实际案例和具体技术细节来说。我见过很多项目，缓存没用好，被别人用高并发冲垮，也见过灰度发布没规范，导致线上故障。可以说，这两块东西，是架构师的必修课。缓存架构要讲一致性、可用性、扩展性，灰度发布要讲流量控制、版本管理、监控告警。这些经验不是纸上谈兵，是踩坑踩出来的。

我用过Redis做主缓存，用本地缓存做二级缓存。主缓存用集群，本地缓存用Caffeine。缓存穿透问题，我用布隆过滤器解决了。缓存雪崩，我用随机延迟过期时间，加了本地缓存兜底。数据一致性，我用异步更新，但也不做强一致。读写分离，我用Spring Cache+Redisson。缓存击穿，我用互斥锁加热点数据预加载。这些配置不是随便写的，是我见过的最稳定方案之一。比如用Redis的Lua脚本来做互斥锁，用`SETNX`加`EX`，确保只有一个线程能更新缓存。本地缓存配置，我用`Caffeine.newBuilder().maximumSize(10000).expireAfterWrite(5, TimeUnit.MINUTES)`。这些参数是根据业务调用量和数据更新频率调整的。

灰度发布方面，我用过Kubernetes的Canary发布。配置一个Deployment，设置多个ReplicaSet，通过权重控制流量。比如用`spec.strategy.rollingUpdate.maxSurge: 1`和`maxUnavailable: 0`，确保旧版本不中断。同时用Istio的DestinationRule和VirtualService来做流量分配。在VirtualService里设置`match`规则和`route`权重，比如`route: { destination: { host: "service-name", weight: 20 } }`。这个方式比较灵活，但需要操作Istio的控制平面。另外，我也用过蓝绿部署，拉起新版本后，用`kubectl set image`切换流量，但这种方式对资源消耗大，适合资源充足的场景。

在微服务中，灰度发布要考虑服务发现和负载均衡。比如用Consul做服务注册，同时在灰度发布时，通过标签控制实例的归属。新版本实例加`canary=true`标签，老版本加`canary=false`。在负载均衡器配置中，用标签过滤来决定路由到哪个版本。这种做法需要在配置中明确写`labels: canary: "true"`，并确保负载均衡器能够识别标签。另外，我也用过Nginx做灰度发布，通过`upstream`和`geo`模块控制流量。比如`geo $canary { default 0; 192.168.1.0/24 1; }`和`if ($canary = 1) { proxy_pass http://new-service; }`。这种方式比较本地化，适合对流量控制要求高的场景。

缓存架构设计要考虑存储引擎的选择。比如，Redis适合缓存热点数据，Memcached适合简单键值对。如果用Redis，记得开启持久化，用`RDB`和`AOF`混合模式。RDB是快照，AOF是日志。配置文件中写`appendonly yes`和`save 900 1`，确保数据安全。缓存集群部署，用`redis-cli -c`检查分片状态，用`CLUSTER SLOTS`命令查看槽位分布。分布式锁的问题，我用Redis的`SET key value NX PX 30000`来实现，确保锁能自动过期。在高并发场景下，这种方式比数据库锁更高效。

缓存预热是必要的。在应用启动时，手动加载热点数据到缓存，避免冷启动高峰。比如用`@PostConstruct`写一段代码加载数据，用`RedisTemplate`的`opsForValue().set("key", value, 30, TimeUnit.MINUTES)`。这种做法比较直接，但需要提前知道哪些数据是热点。或者用定时任务，比如`@Scheduled(fixedDelay = 60000)`，在半夜执行数据预热，减少对线上服务的影响。我见过有些项目直接用`Redisson`做缓存预热，用`RMap`的`putAll`批量加载数据。

缓存穿透问题，我用过布隆过滤器。在Spring Boot中，用Redisson的`RBloomFilter`加`RedisTemplate`做判断。比如在查询前，先检查布隆过滤器是否存在，不存在就直接返回空。配置的时候，用`bloomFilter: { falsePositive: 0.01, size: 1000000 }`，设置合理的误判率和数据量。但布隆过滤器不能持久化，所以在重启后需要重新加载数据。我一般用`RedissonClient.getBloomFilter("bloomKey")`来获取，然后用`RedisTemplate`从数据库读取数据再写入布隆过滤器。这个方法在一些电商项目中应用得比较广泛。

缓存更新策略要谨慎。我用过TTL（Time To Live）机制，设置合理的过期时间。比如`SET key value EX 300`，把缓存设置为30分钟过期。但有些业务不允许数据过期，就改用手动更新。比如在业务逻辑中，当数据变更时，主动删除缓存，用`DEL key`命令。不过要注意的是，删除缓存的时机必须和数据库更新保持一致，否则会出现脏读。我见过一个项目，缓存更新不及时导致库存错误，后果很严重。所以，缓存更新必须和业务操作耦合，比如用监听器或者消息队列来触发。

灰度发布还要考虑回滚机制。如果某版本有问题，必须能快速回退。我用过Kubernetes的`kubectl rollout undo`命令，回滚到上一个稳定版本。但前提是你在发布的时候，使用了`--record`参数记录操作历史。如果没有记录，回滚就只能通过删除Deployment，再用旧的YAML文件重新部署。这种做法虽然有效，但容易出错。所以，建议在发布前确保有完整的配置记录，比如用`git commit`保存发布状态。另外，有些项目用CI/CD工具做自动回滚，比如Jenkins在检测到异常时自动触发回退流程。

在灰度发布中，监控是关键。我用过Prometheus+Grafana做监控，同时用ELK做日志分析。当某个版本出现异常，比如CPU飙升、响应时间变长，监控系统会及时报警。在Kubernetes中，可以用`kubectl top pod`查看资源使用情况，用`kubectl logs`查日志。但监控不只是看数据，还要看用户行为。比如用A/B测试，对比新旧版本的用户点击率、转化率，判断效果。如果新版本数据明显变差，就立刻停止发布。这种做法在一些广告系统中特别常见，因为数据变化直接关系到收益。

缓存架构要考虑缓存失效的策略。有些业务数据不能一直缓存，比如订单信息，必须实时更新。这时候，可以设置`TTL`或`TTI`（Time To Invalidate）。比如`SET key value EX 5 MIN`表示5分钟后过期。但有些数据需要更精确的控制，比如用`EVAL`脚本处理。在Redis中，可以写一个Lua脚本，根据业务规则判断是否失效。例如：`local val = redis.call("GET", KEYS[1]) if val and val ~= "expired" then return val else return nil end`。这种做法可以减少不必要的缓存查询，提升效率。

缓存架构还要考虑缓存击穿的问题。比如某个接口在大量请求下，缓存突然失效，导致所有请求都打到数据库。我用过互斥锁来解决，比如在Redis中用`SETNX`加`EX`命令，让一个线程去更新缓存，其他线程等待。代码中写`string key = "key"; String value = redisTemplate.opsForValue().get(key); if(value == null) { synchronized(lock) { value = redisTemplate.opsForValue().get(key); if(value == null) { value = fetchFromDB(); redisTemplate.opsForValue().set(key, value, 30, TimeUnit.MINUTES); } } }`。这种做法在高并发场景下非常有用，但容易导致线程阻塞，所以得合理设置锁的超时时间。

灰度发布要考虑流量控制。比如用Istio的`DestinationRule`设置`trafficPolicy`，在`http`里写`timeout: 5s`和`retry: { attempts: 3 }`。这样能避免因为新版本不稳定导致请求失败。我见过一个项目，灰度发布时流量没控制好，新版本的API响应慢，导致用户等待时间变长。所以，在配置`VirtualService`的时候，要设置合理的流量分配比例和超时策略。比如用`weight`控制新旧版本的比例，用`headers`做请求头匹配。

缓存架构设计还要考虑缓存的冷热分离。比如将热点数据存到Redis，冷数据存到本地缓存，或者磁盘缓存。这样能提升性能，同时减少内存占用。我见过一个项目，用ElasticCache做主缓存，用Memcached做本地缓存，结合Spring Cache的`@Cacheable`和`@CacheEvict`，实现自动缓存更新。冷热分离的关键是数据分类，比如根据访问频率或业务特征来划分。在配置中，用`@Cacheable("hot")`和`@Cacheable("cold")`来区分缓存类型。

灰度发布还要考虑测试环境的部署。比如在Kubernetes中，用`kubectl apply -f canary.yaml`部署灰度版本，然后用`kubectl get pods`查看状态。测试环境要和生产环境保持一致，否则灰度发布会出问题。我用过Docker做镜像管理，用`docker-compose`部署测试环境，再用`kubectl`切换流量。这样能确保测试环境不会影响生产环境，同时方便回滚。

缓存架构还要考虑缓存的监控。比如用Redis的`INFO memory`命令查看内存使用情况，`INFO stats`查看命中率、空值率等。在Spring Boot中，用`Spring Cache`的`CacheManager`获取统计信息，比如`cacheManager.getCache("hot").getStatistics()`。监控数据能帮助我们发现缓存瓶颈，比如某个key的命中率低，说明需要优化缓存策略。我也用过Prometheus的`redis_exporter`，把缓存指标暴露出来，方便监控。

灰度发布还要考虑回滚的触发条件。比如在Istio中，设置一个`DestinationRule`，当某个版本的错误率超过阈值，自动切换到旧版本。具体配置是`apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: canary spec: trafficPolicy: loadBalancer: simple: ROUND_ROBIN hosts: - service-name traffic: - tag: canary weight: 20 - tag: stable weight: 80`。当发现canary版本的错误率超过10%，就用`kubectl rollout undo deployment/canary`回滚。这种做法能有效减少人为干预，提高系统稳定性。