数据库刚上线时往往扛得住，用户一多，商品详情、首页推荐、登录会话这些被反复读取的数据就会把它拖慢。缓存做的事情很简单：把热点数据放进内存，让大部分请求不必碰数据库。在阿里云上，团队常用的是云数据库 Redis 版（ApsaraDB for Redis），以及兼容 Redis 协议的增强型缓存服务。好处是不用自己搭集群，也不用处理扩容和主从切换，实例与 ECS、容器服务、数据库放在同一个 VPC 里，网络打通也简单。
Memcache 同样是老牌的内存缓存，但它只做简单的键值存取，没有持久化，数据结构也只有字符串。如果只是缓存一段页面片段或接口结果，丢了可以从数据库重建，Memcache 的模型够用，而且简单。一旦涉及计数、排行榜、分布式锁或会话，需要数据结构或持久化，Redis 通常更合适。简单说，Memcache 更像一块纯粹的内存缓冲，Redis 则是带数据结构的内存存储。
选版本前，先看数据量和可用性要求
- 标准版（主从架构）：数据量不大，能接受主节点故障时的短暂切换，成本较低，适合大多数中小业务起步。
- 集群版：单机内存放不下，或读写吞吐已经接近单节点上限时使用，数据会按分片分布到多个节点。注意多 key 操作和事务会受到限制，代码里要提前确认是否依赖这些能力。
- 读写分离版：读远多于写的场景，例如内容平台的文章详情。读请求可以分散到只读节点，但从节点存在同步延迟，刚写入的数据可能短时间读不到，业务需要能接受这个间隔。
支付、库存这类数据丢了就会出大问题的业务，需要评估多可用区高可用架构，并把持久化策略一起考虑。缓存本身是加速层，最终的数据仍然要以数据库为准。
一个电商详情页的改造过程
某中型电商团队在大促前发现，商品详情接口高峰期 QPS 达到数万，MySQL 的 CPU 长期居高不下。他们分三步做了调整。
第一步，把商品基础信息和库存拆开处理。名称、图片、描述这类变化少的内容放进缓存，库存仍然实时查询。如果库存也放进缓存又更新不及时，就容易出现超卖。
第二步，给过期时间加随机值。最初所有商品统一设置 1 小时过期，结果大量 key 在同一时刻失效，数据库瞬间被打满。改成 3600 秒加上 0 到 300 秒的随机偏移后，失效时间被打散，同一时刻回源的请求明显减少。
第三步，热门商品走本地缓存加 Redis 的二级结构。应用进程内放一个很小的缓存，过期时间只设几秒，既减轻了 Redis 的网络压力，几秒的窗口也不会让用户长时间看到旧数据。
改造后，数据库读请求下降超过八成，详情接口的平均响应时间缩短到原来的几分之一。这个结果来自该团队自己的业务和压测环境，换到别的场景未必一样，上线前最好在自己的环境里验证一遍。
三类常见问题与应对
缓存穿透
请求的数据在缓存和数据库里都不存在，每次都会打到数据库上。可以对空结果也做短时间缓存，或者在入口处用布隆过滤器挡掉明显不合法的 ID，比如负数或格式错误的参数。
缓存击穿
热点 key 过期的瞬间，大量并发请求同时回源。用互斥锁保证只有一个线程重建缓存，其他请求稍作等待，或者先返回旧值。
缓存雪崩
大量 key 同时失效，或者整个实例出故障。除了随机过期时间，还要开启多可用区高可用，并在云监控里为内存使用率、连接数和慢查询设置告警，问题发现得越早，留给处理的时间越多。
上线前后要检查的几件事
- 内存淘汰策略：内存满了以后如何处理，要和业务一起定。允许丢失的普通缓存可以考虑 allkeys-lru；会话数据被淘汰后，用户会莫名掉线，这类数据通常不能随意淘汰，最好与普通缓存分开实例部署。
- 网络访问：应用尽量通过 VPC 内网访问实例，安全组和白名单只放行需要的来源。实例暴露在公网，容易被扫描和爆破。
- 大 key 排查：单个 value 过大，或集合元素过多，会让序列化、网络传输和主从同步都变慢，严重时阻塞主线程。可以定期查看慢日志，找出这类 key 后拆分处理。
- 备份与恢复：持久化和备份策略按数据重要程度来配。没有演练过恢复的备份，等于没有备份，建议定期恢复到测试实例上验证一次。
回到选型问题，Redis 和 Memcache 的差别，最终落在你的数据需要什么：要不要持久化，要不要复杂的数据结构，丢了能不能从数据库重建。先把这几个问题想清楚，再去定实例规格，比上线后反复调参省事得多。
