数据库通常是业务量涨起来以后最先顶不住的地方。读请求一多，连接数跟着涨，慢查询也接连出现。把高频访问的数据放进内存，是见效最快的办法之一。Redis 性能好、数据结构够用，生态也成熟，很多团队都从它开始。如果不想自己买机器、装机房，还要半夜处理主从切换，直接用阿里云上的 Redis 会省心很多。
阿里云 Redis 替你做了什么
阿里云的云数据库 Redis 版兼容开源 Redis 协议，多数应用改个连接地址就能迁过去，业务代码基本不用动。它在开源版本上加了持久化与备份、主从高可用、故障自动切换、监控告警和弹性扩缩容这些能力。对没有专职 Redis 运维的小团队来说，这些功能省下的时间很实在。
架构版本怎么选
选版本之前，先问自己三个问题：数据大概有多大，峰值每秒要扛多少请求，预算能到什么程度。常见的三种形态大致如下：
- 标准版（主从架构）：数据量不大、并发一般的业务用它就够，成本最低。主节点出问题时会自动切到备节点。
- 集群版：数据分片存放。单个实例的内存装不下，或者需要横向扩展时再考虑。
- 读写分离版：通过增加只读副本分担查询压力。内容类、读多写少的业务比较合适。
估算时数据量和峰值 QPS 都要算，然后留出余量，别按刚好够用来配。如果半年内基本确定要分片，一开始就选集群版，后面迁移的改造成本会低很多。反过来，如果只是“以后可能用到”，就提前买集群版，平时只会白花钱。
大促时缓存是怎么用的
拿一家服装电商的大促来说。商品详情页的访问量比平时高了二十多倍，数据库 CPU 长时间卡在高位。他们主要做了三件事。
第一，把商品详情和价格写进 Redis，设置合理的过期时间。商品信息一改，就主动删掉对应的缓存，既减少读库，也避免读到旧数据。
第二，秒杀库存用 Redis 的 DECR 原子操作扣减，扣减成功才允许进入下单流程。并发请求不会把库存扣成负数，超卖问题在入口就被挡住了。
第三，热门商品的缓存过期的那一瞬间，大量请求会同时打到数据库上，这就是缓存击穿。他们对热点 key 加了互斥锁，过期时间也加上随机偏移，让缓存不会整齐地一起失效。大促期间数据库压力明显降下来，页面响应也稳住了。
这个例子里，Redis 承担的不只是缓存，计数、限流和并发控制也都靠它。各种数据结构的特点摸清楚，用起来才不容易出岔子。
上线前要过一遍的配置
- 网络：实例尽量和应用放在同一个 VPC 里，走内网访问，再配好安全组和 IP 白名单。别图省事直接对公网开放。
- 访问控制：密码要够强，账号权限按需分配。涉及敏感数据的环境，连接时开启 SSL 加密。
- 大 key：单个 key 太大时，一次读写就会卡住主线程，线上稍有波动就能看出来。比如一个超大的 Hash，可以按业务维度拆成几个小 Hash。
- 阻塞命令：KEYS 命令和数据量大的 SMEMBERS，线上最好不用。换成 SCAN 这类增量遍历，每次只取一小批。
- 淘汰策略：如果 Redis 纯粹当缓存用，可以设成 allkeys-lru 之类的策略。要是里面放的是不能丢的数据，就保留持久化，并把内存水位控制住，别等到内存快满了才处理。
上线后盯哪些指标
阿里云控制台能看到内存使用率、连接数、命中率和慢查询。建议给内存使用率和连接数设置告警，阈值留一点提前量，问题刚冒头就能介入。
成本也值得定期看一眼。内存长期只用了三成左右，说明规格偏大，可以考虑降配。命中率一直上不去，多半是缓存粒度没设计好，或者过期策略不合适。这时优先检查这两处，而不是急着加内存。
小结
选型先看清业务规模，上线前把网络和安全配好，运行中盯住大 key 和慢查询。Redis 阿里云方案的好处，是让团队把时间花在数据结构和业务逻辑上，而不是天天处理底层故障。
