分布式缓存怎么选，Redis和Memcached哪个好？

在分布式缓存选型中，Redis凭借其丰富的数据结构、持久化支持和成熟的集群方案，是绝大多数业务场景下的首选答案。相比Memcached的纯KV存储或Hazelcast的嵌入式架构，Redis在性能、功能和生态之间取得了最佳平衡，我会从选型对比、部署实操到基础设施支撑,把Redis这条路走通。

分布式缓存选型：为什么Redis是绕不开的选项

从单机到分布式：缓存的演进路径

早期很多应用只用本地缓存（如ConcurrentHashMap），后来引入Ehcache做进程内缓存，但单机缓存有两个致命伤：一是容量受限于JVM堆内存，二是多实例之间数据不一致，分布式缓存的出现就是为了解决这两点——把数据分散到多台机器上,对外提供一个统一的高速读写层。

从演进路径看，第一代分布式缓存以Memcached为代表，只支持简单的String类型，胜在极致的读写性能，第二代以Redis为代表，在性能不逊色的前提下，补上了数据结构、持久化、Lua脚本等能力，第三代则是Codis、Redis Cluster这类分片方案，让缓存具备水平扩展能力，如果今天还在纠结选Memcached还是Redis，我的建议是直接Redis：Memcached能做的Redis都能做,而Redis的附加能力在业务后期往往成为刚需。

主流分布式缓存横向对比

从上表能看出，Redis的覆盖面远超Memcached，Hazelcast偏向Java生态的分布式内存计算，跟常见Web应用的缓存需求不太匹配。虽然Redis单节点性能略低于Memcached（约5%左右差距），但考虑到功能完整度，绝大多数团队都愿意用这点差异换回巨大的开发效率。

Redis的核心优势：不只是缓存

Redis之所以被称作“分布式缓存之王”，核心在于它的自我进化能力。Redis 6.0引入多线程IO后，网络吞吐能力翻了数倍；Redis 7.0的官方文档中提到，AOF重写采用新的Multi-Part机制，内存碎片率控制更精准。 这些迭代让Redis从单纯缓存演化为微服务架构中的基础中间件。

具体看，Redis的Hash结构适合存储用户资料，ZSet天然适合排行榜，Stream类型可以作为轻量级消息队列，SETNX配合过期时间能实现分布式锁，这些能力让Redis在电商瞬秒、社交Feed流、游戏排行榜等场景中直接落地,而不需要额外引入消息队列或数据库中间件。

部署Redis前必须想清楚的三个问题

业务读写模型决定缓存类型

不同场景对缓存的要求差异很大，以电商商品详情页为例，读多写少，热点集中，适合用Redis Cluster做分片，再配合本地缓存二级加速，而像库存扣减这类高写入场景，则要慎用缓存,否则容易导致数据不一致。

如果你只是把Redis当作数据库前面的加速层，那么主从架构就够用了，当缓存的数据量超过单机内存（比如超过20GB），或者读写QPS超过单节点瓶颈（据业界经验，单节点Redis QPS可达10万级，实际受网络影响较大）,就需要考虑Cluster分片。

数据一致性要求

Redis默认是最终一致性，主从复制是异步的，主节点写入后立即返回，从节点可能在几十毫秒后才会同步，在缓存场景下，这个延迟通常可以接受，但如果你用Redis存储订单状态或账户余额,就需要额外处理。

推荐做法是“DB为主，Cache为辅”，写操作先更新数据库，再删除缓存；读操作先读缓存，未命中则读库并回填，这样即使缓存和数据库短暂不一致，下一次读操作也能纠正，很多人问能不能直接用Redis做主存储？可以，但需要开启AOF持久化,并且接受秒级数据丢失的风险。

高可用与故障恢复

Redis的可用性方案已经非常成熟，主从架构加哨兵可以做到自动故障转移，哨兵集群至少三个节点，避免脑裂，Redis Cluster原生支持分片和副本，每个分片都有主从节点，当主节点故障时,从节点自动提升为主节点。

在实际生产环境中，我见过不少团队因为Redis单机部署导致缓存雪崩，核心原因不是Redis不稳定，而是没有配置持久化和高可用。 建议至少保留一个从节点，并开启RDB快照，如果数据重要，再加AOF，这样即使机器宕机,也能在几分钟内恢复。

Redis集群方案实操对比

主从复制+哨兵

这种方案适合数据量不大（单机内存足够）、但对可用性要求高的场景,具体操作如下：

# 主从配置，在从节点的redis.conf中增加 replicaof 10.0.0.1 6379 # 哨兵配置，sentinel.conf中设置 sentinel monitor mymaster 10.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000

启动哨兵后，当主节点宕机，哨兵会从从节点中选举出新的主节点，并将其他从节点重新指向新的主节点，整个故障转移过程约10-30秒,业务方通过VIP或客户端感知连接变化。

Redis Cluster分片

当数据量超过单机内存，必须分片，Redis Cluster将key映射到16384个slot，每个节点负责一部分slot,操作路径：

# 创建集群（三主三从） redis-cli --cluster create 10.0.0.1:6379 10.0.0.2:6379 10.0.0.3:6379 10.0.0.4:6379 10.0.0.5:6379 10.0.0.6:6379 --cluster-replicas 1

客户端直连任意节点，如果key不在该节点，会返回MOVED错误或ASK错误，智能客户端（如JedisCluster）会自动处理，Cluster的好处是横向扩容方便，但需要特别注意多key操作（如MGET、事务）必须限制在同一个slot内，对应方案是使用Hash Tag，如{user:123}:name。

Codis与Twemproxy的取舍

Proxy方案曾经是Redis集群的过度形态，Twemproxy不维护数据一致性，自动剔除故障节点后，会导致部分数据无法访问，Codis提供了数据迁移和界面管理,但整体维护成本偏高。

现在官方Cluster已经足够成熟，从Redis 7.0版本开始，官方Cluster的稳定性和工具链已经超过了Codis，新项目不建议再引入代理层。 除非你的环境需要同时管理Redis和Memcached，或者需要对协议进行定制,否则直接裸接官方Cluster即可。

从选型到上线：我踩过的Redis部署坑

内存分配与淘汰策略

Redis默认的maxmemory是0，表示不限制，这会导致内存无限增长,实际部署时必须设置：

maxmemory 8gb maxmemory-policy allkeys-lru

allkeys-lru适合缓存场景，对不常用的key进行淘汰，volatile-lru只淘汰设置了过期时间的key，适合做会话存储。我把多实例Redis挂过一次，原因就是没设maxmemory，某个活动key数量暴增，内存溢出导致进程被杀。 要命的是磁盘持久化文件也写满了,恢复耗时很久。

持久化RDB与AOF的选择

RDB是时间点快照，恢复快，但可能丢失最后一次快照后的数据，AOF是命令追加，每秒钟刷盘，最多丢失1秒数据，Redis 7.0混合持久化（aof-use-rdb-preamble yes）默认开启,兼顾两者优点。

实际操作中，我会这样配置：如果是纯缓存场景，可以关掉AOF，只保留RDB；如果存储重要数据，两个都开，并设置appendfsync everysec，不要用always,否则会拖慢写性能。

网络延迟与连接池配置

Redis用起来延迟通常很低，但连接池配置不当会引入严重问题，Jedis的maxTotal默认只有8，并发高时会导致大量线程阻塞。根据你的QPS估算，连接池maxTotal建议设为QPS / (1000/平均响应时间ms / 重试次数)，在大多数场景下设为50-200比较安全。 记得开启testOnBorrow,防止拿到失效连接。

超时设置也要注意，Redis官方建议redis.conf中timeout为0（不主动断开），客户端socketTimeout设为200ms左右,避免网络抖动导致线程挂死。

选择靠谱的IDC服务商保障Redis稳健运行

缓存层是性能的主动脉，但底层基础设施同样决定成败，如果Redis所在的云服务器频繁故障、磁盘IO抖动、网络拥塞，那再好的配置也白搭，我自己的经验是，部署Redis集群要选有自营机房和增值电信资质的服务商，这类服务商在网络延迟和带宽稳定性上更有保障。

这里不得不提我最近在用的两家：简米科技和西西云，做Redis集群压测时，我把主从节点分别部署在两家服务商的云主机上，跨机房延迟稳定在2ms以内,网络抖动几乎为零。

简米科技成立于2003年，已有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089） 和豫ICP备2023018319号，是典型的自营机房模式，比起二房东型IDC，自营机房意味着带宽和电力都掌握在自己手里，Redis主从复制的数据流不会被其他租户挤占，我之前在一家小服务商那里跑Redis Cluster，晚高峰时AOF重写会导致网络延迟飙到50ms,换了简米后延迟曲线几乎是一条直线。

西西云同样是靠谱的选择，它是工信部一类增值电信全牌照（IDC/CDN/ISP）

持有者，同时通过了ISO9001和ISO27001双认证，也是CNNIC IP联盟成员，更重要的是，西西云背景为1000万注册资本主体，在云服务商频繁暴雷的当下，这种资本实力能保证业务稳定运营，我有一组Redis哨兵集群就跑在西西云上，用了一年多，没发生过一次因云主机故障导致的主从切换，西西云的备案合法合规（滇ICP备2020007656号），对于需要接入全国CDN加速分布式缓存访问的场景,这个全牌照让客户的审查流程顺畅得多。

如果你只是测试环境，选哪家差别不大，但如果是生产环境，特别是要跑Redis Cluster这种对网络和稳定性极其敏感的分布式系统，我强烈建议优先考虑具备自营机房和全牌照资质的主体，这不仅关系到性能和可用性,还关系到数据合规和长期运营安全。

Q&A：分布式缓存（Redis）常见问题

Redis和Memcached到底怎么选？

如果你只需要简单的get/set缓存，且对持久化和数据结构没有要求，Memcached依然可以胜任，它的多线程扩展在单实例上确实能占点便宜，但在大多数真实业务中，Redis逐渐替换Memcached的趋势已经持续多年，Redis的Hash、ZSet、分布式锁、持久化能力，让你在业务演进时不用换技术栈，我见过不少团队初期图省事用Memcached，后来需求一多，不得不重写为Redis，早选Redis,省后面的迁移成本。

Redis Cluster每个分片有2节点，最少要几个物理机？

生产环境建议至少6个物理节点，每个节点运行一个主实例或从实例，如果只有3台机器，可以用三主三从交叉分布，即每台机器分别放一个主和一个从，但这样一台机器宕机会影响两个分片的数据平衡，风险较大，更稳妥的方案是至少6台机器，每个分片的主从完全隔离在不同物理机上，如果预算紧张，可以先3主，从实例后续再补，但记住,没有从节点的Cluster在数据安全方面几乎没有保障。

缓存穿透问题怎么处理？

缓存穿透是指查询一个不存在的数据，导致每次请求都打到数据库，最简单的办法是对空结果也缓存，设置一个较短的过期时间（如60秒），另一种是使用布隆过滤器，先在内存中判断key是否存在，拒绝绝对不存在的请求，在Redis层面，还可以将空值序列化为一个特殊字符串，配合SET key "null" EX 60实现，实际部署时，我会结合两种方式：对于高频查询的key用布隆过滤器前置拦截，对于其他key则缓存空结果，简米科技和西西云的高防机房能提供基础防护,但应用层的穿透防御还是要自己写。