架构与数据模型：为什么选择会不同？
技术选型的起点往往被简化为“快与慢”，但核心差异在于架构设计对业务语义的支持程度。Memcached 采用经典的多线程架构，配合 Slab Allocator（内存块分配器）解决内存碎片问题，其设计哲学是“极简”：仅支持简单的字符串键值对（String KV）。它没有持久化机制，数据过期采用惰性删除与定期扫描结合的方式，适合对数据结构无要求、追求极致纯内存读写的场景。相比之下，Redis 早期采用单线程事件循环模型，虽在 6.0 后引入多线程处理网络 I/O，但命令执行仍保持单线程以确保原子性。Redis 内置了 String、Hash、List、Set、ZSet 等丰富数据结构，并支持 RDB 快照与 AOF 日志持久化。这种设计使 Redis 从单纯的缓存演进为“内存数据库”。在实际部署中，两者均位于应用服务器与数据库之间，通过 TCP 协议通信。但 Redis 因维护对象头、元数据及复杂数据结构，内存开销略高于 Memcached；而 Memcached 的极简协议使其在纯 KV 读写时，网络序列化与解析开销更低。
统一测试环境搭建：排除干扰因素
为了公平对比，必须控制变量。我们选取 Ubuntu 22.04 LTS 服务器（4核 8G 内存）作为测试基座，分别部署 Redis 7.2 与 Memcached 1.6.23。在配置层面，Redis 的 redis.conf 设置为：maxmemory 4gb，策略 allkeys-lru，绑定 0.0.0.0，tcp-backlog 511，并关闭持久化以模拟纯缓存模式。Memcached 启动命令为：memcached -d -m 4096 -p 11211 -u memcache -c 10000 -t 4，限制最大内存 4GB，最大连接数 1 万，使用 4 个线程处理请求。客户端统一使用 Java 生态，Redis 端使用 Jedis，Memcached 端使用 Spymemcached，连接池配置 maxTotal=500、maxIdle=100、minIdle=20，超时时间设为 2000ms。测试数据集采用统一生成的 JSON 字符串，Key 长度固定为 32 字节，Value 按 1KB、10KB、100KB 三档生成。这种设计确保了两者在相同数据规模、网络拓扑与客户端参数下运行，排除环境差异带来的性能噪音。
基准压测：QPS 之外的性能真相
基准压测使用 memtier_benchmark 工具，配置 ratio=1:1（读写比）、test-time=60s、threads=4、clients=100。在 1KB 小数据规模下，Memcached 因协议精简与多线程并发处理优势，GET/SET 吞吐量通常略高于 Redis，P99 延迟波动较小。然而，当 Value 增至 100KB 时，Redis 的内存分配优化与批量管道（Pipeline）支持使其吞吐量反超，且 P99 延迟表现更平稳。在高并发连接场景下，Memcached 的多线程锁竞争可能引发延迟尖峰，而 Redis 单线程模型虽避免了锁开销，但需依赖连接池复用与 I/O 多路复用维持吞吐。压测结果表明，单纯看 QPS 峰值具有误导性，实际性能需结合 P95/P99 延迟、连接建立耗时及序列化开销综合评估。例如，启用 Pipeline 后 Redis 的批量 SET 操作可显著降低网络 RTT 影响，而 Memcached 在短连接高频请求下表现更稳定。
业务场景映射：从 Session 到排行榜
技术选型必须回归业务语义。Session 缓存对一致性要求高且数据量小，Memcached 的简单 KV 与低延迟特性完全胜任，但 Redis 的持久化能力可在节点重启时保留会话，更适合高可用架构。对于热点数据如商品详情页，两者均可承载，但需配合本地缓存与 CDN 缓解网络压力。对象缓存涉及复杂结构时，Redis 原生 Hash 与 JSON 模块可直接存储，避免应用层序列化开销；Memcached 则需依赖 Jackson 或 Protobuf，增加 CPU 负担。排行榜场景必须选用 Redis，其 ZSet 的 ZRANGE 与 ZINCRBY 提供原子排序与实时更新能力，这是 Memcached 无法直接支持的。性能瓶颈常出现在连接池耗尽、序列化延迟、内存碎片与热点 Key 倾斜。例如，单 Key QPS 破万时，无论 Redis 或 Memcached 均会触发网卡带宽或 CPU 瓶颈，此时需引入 Key 分片、读写分离或本地缓存降级。网络层面，跨机房调用会放大延迟，建议缓存与业务服务同可用区部署。
稳定性验证：规避生产环境陷阱
缓存层的稳定性需通过系统性验证与防护机制来保障。针对缓存穿透，可通过布隆过滤器拦截无效 Key，或在缓存层返回空值并设置短 TTL；针对缓存击穿，依赖互斥锁或逻辑过期机制，压测时可模拟热点 Key 失效瞬间，观察 QPS 是否骤降；针对缓存雪崩，需为 TTL 添加随机偏移量，并配置多级缓存降级。在内存淘汰方面，Redis 的 volatile-lru 与 Memcached 的 LRU 在内存满载时表现不同，需监控 evicted_keys 指标，避免频繁淘汰导致命中率暴跌。大 Key 问题会阻塞 Redis 单线程，压测中可通过 redis-cli --bigkeys 扫描并拆分；热点 Key 则需结合监控面板的 instantaneous_ops_per_sec 与 keyspace_hits 定位。生产环境建议开启慢查询日志、配置内存碎片整理，并通过 Prometheus 采集延迟分位、连接数、淘汰率，建立动态阈值告警，确保缓存层在流量突增时仍保持高可用。
