原文摘要

架构师之路：架构设计中的100个知识点（78）

原文链接

进一步信息揣测

• 缓存作为服务间通信媒介的隐患：
• 行业内部通常使用MQ（消息队列）而非缓存进行服务间数据传递，缓存用于此目的会导致服务间强耦合（如共享缓存实例），违反微服务解耦原则
• 缓存设计初衷是加速读操作，而非数据传输，其缺乏MQ的可靠性保证（如消息持久化、重试机制）
• 缓存雪崩的深层防御策略：
• 实际场景中缓存全挂时，数据库可能被压垮的真实案例往往源于未做"缓存穿透保护"（如本地缓存+短过期时间）和数据库限流
• 资深架构师会采用"多级缓存+熔断降级"组合拳：Redis集群宕机时自动降级到本地缓存（如Caffeine），而非直接透传数据库
• 热点Key问题的黑科技解法：
• 内部常用"分片热Key"技巧：将热点Key拆分为key_1、key_2...key_n，配合客户端轮询分散压力（需权衡数据一致性）
• 头部企业会使用有界队列更新缓存：对同一热点Key的并发更新请求排队处理，避免重复计算（如Guava的RateLimiter）
• 数据一致性处理的灰色手段：
• 高并发场景下，部分公司会牺牲强一致性：通过"延迟双删+本地黑名单"实现最终一致（先删缓存→改DB→延迟200ms再删缓存）
• 金融级系统则采用binlog订阅异步更新缓存（如Canal组件），但存在秒级延迟，需业务容忍
• 缓存选型的潜规则：
• 互联网大厂Redis集群并非纯内存：部分冷数据会启用RocksDB混合存储，成本直降60%（但需接受性能折损）
• 自研缓存中间件已成趋势：如某厂将Redis协议适配到自研存储引擎，兼容社区生态同时实现硬件级优化