分布式缓存常用技术有哪些？，Redis缓存性能如何优化

Redis是当前最主流的分布式缓存技术，它凭借高性能、丰富的数据结构以及成熟的高可用方案，成为解决高并发读场景的首选。

分布式缓存常用技术对比：Redis与Memcached怎么选

在选型时，很多团队会纠结于Redis和Memcached，两者都是内存缓存，但设计理念和适用场景差异明显，下面从几个关键维度拆解,帮你在实际业务中做出判断。

数据结构支持差异

• Redis：支持字符串、哈希、列表、集合、有序集合、位图、HyperLogLog、地理空间等，可以直接在服务端操作数据,减少网络开销。
• Memcached：仅支持简单的键值对，Value是纯二进制块,所有复杂操作必须在客户端完成。

如果你的业务需要缓存对象的部分字段（如用户信息中的头像和昵称），用Redis的哈希结构可以只更新某个字段,而Memcached必须全量传输整个对象。

持久化与高可用

• Redis：提供RDB快照和AOF日志两种持久化方式，支持主从复制、哨兵、集群模式，保证数据不丢或少丢,具备自动故障转移能力。
• Memcached：纯内存运行，宕机后数据全部丢失，没有原生持久化或复制机制,高可用只能依赖客户端做一致性哈希或代理层实现。

行业共识认为，对数据安全性要求较高的场景（如订单缓存、会话数据），Redis是更稳妥的选择；而纯临时的、可丢失的数据（如页面静态片段）可以用Memcached。

性能与内存效率

• 注意：Redis在纯KV场景下性能与Memcached接近，但一旦使用复杂数据结构，CPU消耗会上升,大部分业务场景下Redis的灵活度带来的收益远大于微小的性能损耗。

缓存穿透的解决方案：从理论到实战

缓存穿透是指请求查询一个根本不存在的数据，绕过缓存直接打到数据库，如果攻击者刻意构造大量不存在的key，数据库压力会瞬间飙升，解决这个问题的核心思路是让“不存在”也被缓存起来。

布隆过滤器方案

布隆过滤器是一个空间效率很高的概率型数据结构，用于判断一个元素是否在集合中，它会有一定的误判率（把不存在判为存在），但不会漏判（存在的一定判为存在）。

• 实现步骤：

  1. 在Redis中加载布隆过滤器模块（RedisBloom），或使用客户端库（如Redisson）。
  2. 将所有可能存在的数据key提前存入布隆过滤器。
  3. 请求到来时，先检查布隆过滤器：如果判定不存在，直接返回空；如果判定存在,再查缓存或数据库。
  4. 数据库写入新数据时，同步更新布隆过滤器（添加新key）。

• 优点：纯内存判断，速度快，占用空间小（1亿个元素约100MB）。

• 缺点：存在误判率,需要定期重建过滤器以修正数据变化。

缓存空对象方案

直接针对查询不到的key，在Redis中缓存一个空值（如null或特殊标记），并设置较短的过期时间（如1-5分钟）。

• 操作路径：

  1. 查询缓存,若命中则返回。
  2. 未命中则查询数据库，若数据库无记录，将key-value=null写入Redis,TTL设为60秒。
  3. 后续相同请求在TTL内直接返回空,不再穿透到数据库。

• 优点：实现简单,无需额外组件。

• 缺点：会占用少量缓存空间，且如果恶意攻击的key不断变化，仍然会穿透（每个无效key都会缓存一次），通常建议结合布隆过滤器使用，先过滤大部分无效key,再对个别漏网之鱼做空值缓存。

如何选择适合你的方案

• 如果业务数据量级固定、key数量可控，且对精确度要求高，优先用

  

  缓存空对象。

• 如果攻击者可能随机生成大量不可预测的key，且数据库承受不住突发压力，请上布隆过滤器,或两者叠加。
• 对于高并发秒杀、活动页等场景，建议在网关层加一层本地布隆过滤器,减少Redis压力。

分布式缓存的高可用与性能优化

缓存系统的稳定性直接影响业务链路，下面重点讨论缓存雪崩、击穿以及一致性平衡的常见手段。

缓存雪崩怎么解决

缓存雪崩指大量缓存同时过期，导致请求全部涌向数据库，常见原因包括：设置相同过期时间、Redis节点宕机。

• 解决措施：
  • 过期时间加随机偏移：比如基础过期时间+随机0~300秒,避免集体失效。
  • 多级缓存：本地缓存（如Caffeine）+ Redis，本地缓存过期时间短于Redis,两者错开。
  • 限流熔断：数据库层做限流，保护后端服务；部分请求降级返回默认值。
  • 部署Redis集群高可用：主从切换+哨兵,避免单点故障引发雪崩。

缓存击穿与互斥锁

缓存击穿指一个热点key在过期瞬间，大量并发请求同时到达数据库，解决方案是只让一个请求去重建缓存。

• 互斥锁方案（以Redis的SETNX实现）：
  1. 当key过期时，第一个请求获取锁（SETNX lock_key 1）。
  2. 获取锁的请求从数据库加载数据，写入Redis,释放锁。
  3. 其他请求等待锁释放后，直接从缓存获取数据（或返回旧数据）。
• 注意事项：锁的过期时间要合理设置，避免死锁；重建缓存期间，其他请求可以返回“正在加载”的提示或直接返回已缓存的数据（如果允许短暂不一致）。

缓存与数据库一致性方案

业务实际中，数据更新后需要同步清理或更新缓存，否则会出现脏读,业内常用的策略包括：

• 先更新数据库，再删除缓存：这是最通用的做法，为了避免并发写导致的脏数据，可以采用延迟双删（先删缓存，再更新数据库，稍后再删一次缓存）。



• 消息队列异步同步：数据库变更后发送MQ消息，消费者负责更新或删除缓存,适合对一致性要求稍低的场景。
• 订阅binlog：通过Canal等工具监听MySQL binlog，实时同步到Redis，完全解耦,但运维成本较高。

推荐顺序：业务允许短期不一致时，优先用“先更新DB，再删缓存”；要求强一致时，加分布式锁,并配合版本号或CAS检查。

日常运维与性能排查

• 大key与热key：使用redis-cli --bigkeys扫描大key，大字符串或大集合会拖慢Redis实例；发现热key后,通过本地缓存或读写分离来分担压力。
• 慢查询排查：启用SLOWLOG命令，分析慢查询命令，避免使用KEYS、HGETALL等全量操作，改用SCAN、HSCAN。
• 内存碎片优化：定期执行MEMORY PURGE（Redis 4.0+），并合理设置maxmemory-policy,防止内存暴涨。

Q&A：分布式缓存常用技术Redis常见问题解答

Redis缓存穿透和缓存雪崩有什么区别？

缓存穿透是针对不存在的数据，大量请求绕过缓存直接打数据库；缓存雪崩是大量缓存同时过期或节点宕机，导致请求全部落到数据库，前者解决思路是布隆过滤器或空值缓存，后者侧重过期时间随机化、多级缓存、高可用部署。

分布式缓存Redis和Memcached，哪个更适合做会话存储？

Redis更适合，会话数据需要持久化、高可用以及快速更新（如更新用户登录状态），Redis的哈希结构可以单独修改某个字段，而Memcached无法做到,多数大型系统的会话中心都基于Redis实现。

缓存一致性要求高的场景，推荐哪种更新策略？

推荐使用“先更新数据库，再删除缓存”并配合延迟双删，如果业务允许几毫秒的不一致，通过消息队列异步删除也是常见方案，对于银行类强一致场景，需要引入分布式锁和版本号,确保读写操作串行化。