为什么使用redis：降低数据库压力

为什么使用redis，核心是把高频读取、变动平缓的数据放到内存里，减少MySQL这类磁盘数据库的查询请求，你可以在热点商品缓存、会话存储、计数限流、排行榜场景直接落地；它适合读多写少、允许短暂数据不一致的业务，当业务写请求占比超过七成、数据必须强事务一致时，不适合选用。

为什么使用redis做热点数据缓存

内存读写速度远高于磁盘，单节点redis的QPS可以达到数万级别，磁盘数据库通常只能承载数千。同一个商品详情、首页配置、分类列表，短时间会被大量用户重复访问，这类数据存入redis后，后续请求直接读取缓存，不会反复穿透到底层数据库。缓存会设置过期时间，数据更新时主动删除或更新缓存，保证数据不会长期陈旧。

控制好缓存穿透、缓存击穿、缓存雪崩三类问题，缓存的收益可以稳定兑现。

为什么使用redis实现轻量业务能力

redis自带多种数据结构，不用额外开发组件就能实现很多功能。String结构存储用户登录session，Hash存放用户简单资料，ZSet用来做积分排行榜，Set完成去重统计，List充当简单消息队列。这些能力如果全部依靠数据库实现，会增加大量SQL语句和表结构维护成本，开发周期更长。

分布式场景下，redis可以作为公共存储，多台应用实例共享同一份会话和计数数据，避免单机内存存储带来的数据隔离问题。

为什么使用redis支撑限流与计数

基于redis的原子命令，可以实现接口限流、访问次数统计。例如限制单个IP每分钟访问接口的次数，每次请求执行自增命令并设置过期时间，超出阈值直接拦截请求。这类高频计数操作如果交给数据库，短时间内会产生大量写入语句，很容易拖慢整体库的响应速度，redis原子操作执行开销更低。

redis不替代主数据库。

它的数据存在内存，持久化只是兜底手段，出现进程宕机、服务器故障时，存在数据丢失的可能性。重要资金类、订单类核心数据，仍然需要持久化数据库做主存储，redis只承担辅助加速的角色。

你部署redis集群时，优先开启RDB和AOF混合持久化，平衡性能和数据丢失范围。AOF每秒刷盘模式下，故障后最多丢失一秒内写入的数据，适合大部分线上业务。

业务数据变更流程要遵循先更新数据库，再删除缓存的顺序，颠倒顺序容易出现短时间脏数据，在高并发更新场景里这个现象会更容易被用户感知。