图解Redis适用场景

Redis以其速度而闻名。

1 业务数据缓存

1.1 通用数据缓存

string，int，list，map。Redis 最常见的用例是缓存对象以加速 Web 应用程序。

此用例中，Redis 将频繁请求的数据存储在内存。允许 Web 服务器快速返回频繁访问的数据。这减轻数据库的负载并提高应用程序RT。

规模扩张时，缓存分布在 Redis 服务器集群中。分片可平均分配集群中的缓存负载。

1.2 实时热数据

最新N条数据

2 会话存储

在无状态服务器之间共享会话数据。当用户登录 Web 应用程序时，会话数据与唯一会话 ID 一起存储在 Redis并作为 cookie 返给客户端。

当用户向应用程序发出请求时，请求中包含会话 ID,无状态 Web 服务器使用 ID 从 Redis 检索会话数据。

风险

若 Redis 服务器重启，则存储在 Redis 中的会话数据丢失。尽管 Redis 通过RDB和 AOF 或仅追加文件提供持久性，它们允许将会话数据保存到磁盘并在重启事件中重新加载到内存。但这些选项在生产通常需要太长时间加载，并不实用。相反,在这种情况下使用复制。数据复制到备份实例。在主实例崩溃时，备份实例会很快被提升以接管流量。

Redis 会话存储 V.S JWT 技术

各有优势,选择取决于具体的应用场景和需求:

1. 安全性:JWT 更加安全,因为它不需要服务器端存储会话数据,全部的数据可以通过加密的 JWT 编码在客户端;而 Redis 存储在服务器端,如果 Redis 被攻击可能会洩漏会话数据。

2. 伸缩性:Redis 会话存储更易水平扩展,通过集群可以很好的承载大量会话;JWT 需要应用层进行扩展。

3. 实现难度:Redis 会话存储实现简单,直接利用 Redis API 即可;JWT 需要选用算法和密钥,客户端和服务端都需要一些代码实现。

4. 跨域访问:JWT 更适合跨域场景,因为可以直接在请求头中携带。Redis只能在同域下访问。

5. 适用场景:

• 需要 sessions 的场景更适合 Redis 会话存储,比如要跟踪用户状态的 web 应用。
• 对安全性要求高的 API、跨域应用更适合 JWT。
• 如果是内部系统或者对安全要求不高,Redis会话存储就足够了。

所以,你需要根据应用的具体场景、安全性需求、实现成本等因素权衡考虑,选择更适合的会话管理方案。两者也可以结合使用。

3 全局一致计数

全局流控计数（Rate Limiter）

简单的限流组件，但有问题，不建议使用。还是要用滑动窗口算法。

使用其在某些计数器上递增命令并为这些计数器设置到期时间来用作Rate Limiter。

基本的速率限制算法的工作原理

对于每个传入的请求，请求 IP 或用户ID 作K。

使用incr 命令递增K的请求数。 将当前计数与允许的速率限制比较：

• 若计数在速率限制内，则处理请求
• 若计数超过限制，则拒绝请求

K被设置为在特定时间窗口内过期，如 1min，以便为下一时间窗口重置计数。

诸如漏桶算法类的更复杂Rate Limiter也可用 Redis 实现。

秒杀的库存计算

抢红包

全局唯一ID

4 高效的统计计数

• id去重
  记录访问ip等全局bitmap操作
• UV、PV等访问量
  非严格一致性要求

5 发布订阅与Stream

Pub-Sub 模拟队列 subscribe comments publish comments java

Redis Stream 是 Redis 5.0 版本新增加的数据结构。 Redis Stream 主要用于MQ。

可参考 https://www.runoob.com/redis/redis-stream.html

6 分布式锁

当应用程序中的多个节点需要协调对某些共享资源的访问时，使用分布式锁。 Redis 用作分布式锁，具有原子命令如 SETNX 或如果不存在则设置，使得caller只在K不存在时才能设置K。

工作原理

Client 1试图通过使用 SETNX 命令设置具有唯一值和TTL的K来获取锁。如果该K尚未设置，则 SETNX 返回1表示锁已被Client 1获得。Client 1完成其工作。

通过删除键来释放日志。现在，若K已设置，SETNX返回 0，表示锁已经被另一客户端持有。此时，Client 1会等待并重试 SETNX 操作，直到另一个客户端释放该锁。

对许多用例来说，这个简单的实现可能就足够好了，但它对生产使用来说不是完全容错。许多 Redis 客户端库提供直接开箱即用的高质量分布式锁实现。

获取锁 原子性操作

SET dlock my_random_value NX PX 30000

释放锁，lua脚本，保证原子性+单线程，从而具有事务性

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

7 业务数据处理

• 非严格一致性要求的数据：评论，点击等
• 业务数据去重：订单处理的幂等校验等
• 业务数据排序：排名，排行榜等

本文由博客一文多发平台 OpenWrite 发布！