为什么用Redis而不用Mysql呢？-CSDN博客

本文链接：https://blog.csdn.net/2302_79951871/article/details/147656864

Redis 是一个高性能的键值存储系统，支持多种数据结构（String，List，Hash，Set，Zset等）和丰富的功能，广泛应用于缓存、实时数据处理、消息队列等场景。Mysql和Redis对比图在最下面

Redis的用处

缓存

核心作用

加速数据访问：将热点数据存储在内存中，减少对慢速存储（如数据库、磁盘）的访问。
降低后端负载：通过缓存高频查询结果，减少数据库压力，避免系统过载。

典型场景

用户信息缓存
存储用户基本信息、权限等，避免每次请求都查询数据库。
```
SET user:1001 '{"name":"Alice","role":"admin"}' EX 3600  # 缓存1小时
```
页面静态化
缓存动态生成的页面片段（如商品详情页），提升响应速度。
数据库查询缓存
缓存复杂查询结果（如排行榜、聚合统计），定期更新或通过消息队列触发刷新。

优势

微秒级响应：内存操作速度远超磁盘或网络请求。
灵活过期策略：通过 EXPIRE 设置 TTL（生存时间），自动清理旧数据。

会话管理

核心作用

集中式会话存储：在分布式系统中统一管理用户登录状态，避免会话丢失或重复登录。
跨服务共享：多个微服务可通过 Redis 共享会话信息，实现无状态架构。

典型场景

Web 应用的 Session 存储
将会话数据（如用户 ID、权限令牌）存入 Redis，替代传统 Cookie 或服务器内存存储。
```
HSET session:abc123 user_id 1001 expires 1690000000
```
单点登录（SSO）
存储全局登录凭证，供多个子系统验证用户身份。

优势

高可用：通过 Redis 集群保障会话数据不丢失。
快速失效：通过 DEL 命令立即踢出用户。

实时排行榜和计数

核心作用

动态排序：实时更新和展示排名数据（如游戏积分、短视频热度）。
原子计数：支持高并发下的精准计数（如点赞、库存）。

典型场景

游戏积分榜
使用有序集合存储玩家得分，按分数实时排序。

ZADD leaderboard 5000 "PlayerA"  # 添加玩家得分
ZREVRANGE leaderboard 0 9 WITHSCORES  # 获取 Top 10

商品库存扣减
使用原子操作 DECR 防止超卖：

SET inventory:1001 100  # 初始库存
DECR inventory:1001     # 扣减库存，返回当前值

优势

高性能排序：有序集合的排序复杂度为 O(log N)，适合大规模数据。
原子性：避免并发场景下的数据不一致。

消息队列

核心作用

异步解耦：将耗时操作（如发送邮件、处理订单）异步化，提升系统响应速度。
流量削峰：缓冲突发请求，避免后端服务被压垮。

典型场景

订单处理队列
使用 List 结构实现 FIFO（先进先出）队列：


LPUSH orders:pending "{order_id: 1001, items: [...]}"  # 生产者推送订单
BRPOP orders:pending 30  # 消费者阻塞获取订单，超时30秒

发布订阅
实时通知系统事件（如价格变动、库存更新）：

SUBSCRIBE price_updates  # 订阅频道
PUBLISH price_updates "ProductA:99.9"  # 发布消息

优势

轻量级：无需引入 Kafka 等复杂中间件，适合简单场景。
支持阻塞操作：通过 BRPOP 实现消费者等待新消息。

分布式锁

核心作用

协调分布式资源：防止多个节点同时操作共享资源（如秒杀库存、文件写入）。

实现方案

基础加锁
使用 SET 命令的 NX（不存在才设置）和 EX（过期时间）参数：
```
SET lock:resource_123 "client1" NX EX 10  # 加锁，10秒后自动释放
```

安全释放锁
通过 Lua 脚本保证原子性，避免误删其他客户端的锁：

if redis.call("GET", KEYS[1]) == ARGV[1] then
  return redis.call("DEL", KEYS[1])
else
  return 0
end

典型场景

秒杀活动：确保库存扣减的原子性。
定时任务调度：防止多个节点重复执行任务。

实时统计与监控

核心作用

快速聚合数据：实时统计用户行为（如 PV、UV、在线人数）。
节省存储空间：使用概率数据结构（如 HyperLogLog）减少内存占用。

典型场景

网站访问统计
- PV：使用 INCR 统计页面访问量。
```
INCR pv:/product/1001
```
- UV：使用 HyperLogLog 去重统计独立用户。
```
PFADD uv:20231001 "user1" "user2"
PFCOUNT uv:20231001  # 返回近似独立用户数
```

在线用户状态
使用位图记录用户每日登录状态：


SETBIT user:1001:logins 15 1  # 第15天登录
BITCOUNT user:1001:logins      # 统计本月登录天数

优势

低内存消耗：HyperLogLog 仅需 12KB 内存即可统计上亿唯一值。
实时性：数据立即可查，无需离线计算。

地理空间数据处理

核心作用

存储与查询地理位置：支持坐标存储、距离计算、范围搜索。

典型场景

附近的人
存储用户位置，查询指定范围内的其他用户：

GEOADD locations 116.40 39.90 "UserA"   # 添加坐标
GEORADIUS locations 116.41 39.91 10 km  # 查询10公里内的用户

配送路线优化
计算两个地点之间的距离：

GEODIST locations "UserA" "UserB" km  # 返回千米为单位的距离

优势

高效查询：底层使用有序集合存储，支持快速范围搜索。
精准计算：基于 Haversine 公式计算地球表面距离。

Redis于Mysql的优势对比

对比维度	Redis	MySQL
数据模型	键值对、支持多种数据结构（字符串、哈希、列表、集合、有序集合等）	关系型数据模型，基于表格和 SQL 查询
存储介质	内存存储为主，数据读写极快（微秒级）	磁盘存储为主，数据读写速度较慢（毫秒级）
性能	高并发、低延迟，适合实时场景（如缓存、计数器）	适用于复杂查询和事务处理，但高并发时性能可能下降
查询能力	简单查询（基于键值或特定数据结构操作）	支持复杂 SQL 查询（JOIN、子查询、聚合等）
事务支持	支持简单事务（基于 `MULTI/EXEC`），不保证 ACID 完整性	完整 ACID 特性（原子性、一致性、隔离性、持久性）
持久化机制	可选持久化（RDB 快照、AOF 日志）	默认持久化（事务日志、binlog），数据可靠性高
扩展性	天然支持分布式架构（集群、主从复制）	扩展复杂（需分库分表或读写分离）
适用场景	缓存、会话存储、实时排行榜、消息队列、高频读写场景	复杂业务逻辑、事务处理、报表分析、持久化存储
数据容量	受内存限制（可通过集群扩展）	支持海量数据存储（基于磁盘，容量更大）
数据结构灵活性	支持丰富的数据结构（如地理空间、HyperLogLog），适合特定场景优化	基于固定表结构，灵活性较低