使用 Redis 过期策略构建高效且可靠的缓存系统 (使用redis实现限流)

Redis 是一种流行的键值存储数据库，以其高性能和可扩展性而闻名。它提供了广泛的数据结构，包括字符串、散列、列表、集合和有序集合，使其适用于各种应用程序场景。

其中一项关键功能是过期策略，它允许在指定的时间段后自动删除密钥及其关联值。这对于缓存系统至关重要，因为它有助于确保缓存中的数据保持最新，并防止废弃数据消耗不必要的内存。

Redis 的过期策略

Redis 提供了多种过期策略，可用于满足不同的需求。这些策略包括：

• TTL（生存时间）：为密钥设置固定生存时间的策略。
• Idle 时间：为密钥设置不活动时间的策略，在此期间密钥未被访问。
• LRU（最近最少使用）：根据密钥最近被访问的时间淘汰密钥的策略。

选择合适的过期策略

选择合适的过期策略取决于应用程序的特定需求。以下是每个策略的优点和缺点：

TTL

优点：简单且易于实现。确保密钥在指定的时间段后被删除。缺点：无法根据密钥的实际使用情况进行调整。可能会导致并发问题，当多个客户端同时访问相同密钥时。

Idle 时间

优点：根据密钥的实际使用情况进行调整。避免并发问题。缺点：实现更复杂。可能导致密钥在不被使用时仍被保留在缓存中。

LRU

优点：淘汰最近最少使用的密钥，释放内存。避免并发问题。缺点：实现更复杂。可能会导致缓存命中率较低。

构建高效且可靠的缓存系统

通过仔细选择和配置过期策略，可以构建高效且可靠的缓存系统。以下是一些最佳实践：

根据数据类型选择适当的策略：对于经常访问且数据很少变化的数据，TTL 策略是合适的。对于不经常访问或数据经常变化的数据，Idle 时间或 LRU 策略可能更适合。设置合理的过期时间：过期时间应足够长以允许客户端从缓存中获取数据，但又不能太长以至于数据过期。使用中间件或库：可以使用中间件或库来简化过期策略的管理。这些工具可以自动根据预定义的规则删除过期的密钥。监控缓存命中率：定期监控缓存命中率以确保缓存得到有效利用。低命中率可能表明需要调整过期策略或解决其他性能问题。测试和调整：在部署缓存系统之前，对其进行全面测试以确保其符合应用程序的需求。根据测试结果，可能需要调整过期策略或其他配置设置。

Redis 限流示例

过期策略还可以用于实现限流，这是一种控制系统中并发请求速率的技术。可以使用 Redis 来实现以下所示的令牌桶算法：

import redis创建 Redis 客户端 r = redis.Redis()创建令牌桶 bucket = "my_token_bucket" max_tokens = 100 fill_rate = 10 每秒填充 10 个令牌检查是否可以获取令牌 def acquire_token():获取令牌计数count = r.get(bucket) or 0如果令牌不足if count < 1:return False否则，获取令牌else:r.decrby(bucket, 1)r.expire(bucket, 1 / fill_rate) 设置过期时间以自动补充令牌return True

此令牌桶算法使用 Redis 的过期策略来控制令牌的补充速率。每当客户端请求令牌时，该算法都会检查令牌计数。如果计数不足，则算法会返回 False，阻止请求。如果计数充足，则算法会获取一个令牌并设置一个过期时间，以自动补充令牌。

结论

Redis 的过期策略是一项强大的工具，可用于构建高效且可靠的缓存系统。通过仔细选择和配置过期策略，可以优化缓存性能、减少内存消耗并防止废弃数据。过期策略还可以用于实现限流，从而控制系统中的并发请求速率。通过利用 Redis 的强大功能，开发者可以创建满足应用程序特定需求的健壮缓存解决方案。

---

分布式限流 redis-cell

redis 4.0 以后开始支持扩展模块， redis-cell 是一个用rust语言编写的基于令牌桶算法的的限流模块，提供原子性的限流功能，并允许突发流量，可以很方便的应用于分布式环境中。

令牌桶算法的原理是定义一个按一定速率产生token的桶，每次去桶中申请token，若桶中没有足够的token则申请失败，否则成功。在请求不多的情况下，桶中的token基本会饱和，此时若流量激增，并不会马上拒绝请求，所以这种算法允许一定的流量激增。

这几个步骤可以采用redis提供的原生命令去实现，但是，但是，但是高并发的时候数据会不一致，所以redis-cell将这个过程原子化，完美解决了分布式环境下数据的一致性问题。

官方提供了安装包和源码编译两种方式，源码编译要安装rust环境，比较复杂，这里介绍安装包方式安装：

执行完以上步骤就可以使用其提供的限流功能了。

该模块只提供了一个命令：

test 100 400 60 3

test：redis key

100：官方叫 max_burst ，没理解什么意思，其值为令牌桶的容量 - 1， 首次执行时令牌桶会默认填满

400：与下一个参数一起，表示在指定时间窗口内允许访问的次数

60：指定的时间窗口，单位：秒

3：表示本次要申请的令牌数，不写则默认为 1

以上命令表示 从一个初始值为100的令牌桶中取3个令牌，该令牌桶的速率限制为400次/60秒 。

1：是否成功，0：成功，1：拒绝

2：令牌桶的容量，大小为初始值+1

3：当前令牌桶中可用的令牌

4：若请求被拒绝，这个值表示多久后才令牌桶中会重新添加令牌，单位：秒， 可以作为重试时间

5：表示多久后令牌桶中的令牌会存满

下面以一个速率稍慢一点的令牌桶来展示一下，连续快速执行以下命令：

通过命令可以看到，每次从桶中取出3个令牌，当桶中令牌不足时，请求被拒绝。

因为业务的原因（周末请求比平时多），最近公司的服务一到周末就嗝屁，消防群里忙的不可开交，有几次跟redis有关系导致服务雪崩，后来架构那边出建议各个业务组减少对其他服务的依赖。

一方面其他服务都不可靠，一方面一些核心业务不能做降级，并且公司日益壮大，服务太多，出错排查的成本太大，基于这些原因，能在自己服务内解决的就不要依赖其他服务。

个人觉得，项目不大的，维护成本不高的话，可以采用 直接使用 redsi-cell ，否则可以考虑细粒度的控制到每个服务节点去限流，配合相应的负载均衡策略去实现。以上为个人理解，仅供参考。

Redis过期淘汰策略实现方法？

Redis 中数据过期策略采用定期删除+惰性删除策略。 定期删除策略：Redis 启用一个定时器定时监视所有的 key，判断key是否过期，过期的话就删除。 这种策略可以保证过期的 key 最终都会被删除，但是也存在严重的缺点：每次都遍历内存中所有的数据，非常消耗 CPU 资源，并且当 key 已过期，但是定时器还处于未唤起状态，这段时间内 key 仍然可以用。 惰性删除策略：在获取 key 时，先判断 key 是否过期，如果过期则删除。 这种方式存在一个缺点：如果这个 key 一直未被使用，那么它一直在内存中，其实它已经过期了，会浪费大量的空间。 2、定期删除+惰性删除策略是如何工作的？这两种策略天然的互补，结合起来之后，定时删除策略就发生了一些改变，不在是每次扫描全部的 key 了，而是随机抽取一部分 key 进行检查，这样就降低了对 CPU 资源的损耗，惰性删除策略互补了为检查到的key，基本上满足了所有要求。 但是有时候就是那么的巧，既没有被定时器抽取到，又没有被使用，这些数据又如何从内存中消失？没关系，还有内存淘汰机制，当内存不够用时，内存淘汰机制就会上场。 Redis 内存淘汰机制有以下几种策略：noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。 （Redis 默认策略）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 Key。 （推荐使用）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 Key。 volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 Key。 这种情况一般是把 Redis 既当缓存，又做持久化存储的时候才用。 volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 Key。 volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。 修改内存淘汰机制只需要在 配置文件中配置 maxmemory-policy 参数即可。

redis常见问题

1. 缓存击穿

缓存击穿是指一个请求要访问的数据，缓存中没有，但数据库中有的情况。这种情况一般都是缓存过期了。

但是这时由于并发访问这个缓存的用户特别多，这是一个热点 key，这么多用户的请求同时过来，在缓存里面没有取到数据，所以又同时去访问数据库取数据，引起数据库流量激增，压力瞬间增大，直接崩溃给你看。

所以一个数据有缓存，每次请求都从缓存中快速的返回了数据，但是某个时间点缓存失效了，某个请求在缓存中没有请求到数据，这时候我们就说这个请求就击穿了缓存。

针对这个场景，对应的解决方案一般来说有三种。

借助Redis setNX命令设置一个标志位就行。设置成功的放行，设置失败的就轮询等待。就是在更新缓存时加把锁

后台开一个定时任务，专门主动更新过期数据

比如程序中设置 why 这个热点 key 的时候，同时设置了过期时间为 10 分钟，那后台程序在第 8 分钟的时候，会去数据库查询数据并重新放到缓存中，同时再次设置缓存为 10 分钟。

其实上面的后台续命思想的最终体现是也是永不过期。

只是后台续命的思想，会主动更新缓存，适用于缓存会变的场景。会出现缓存不一致的情况，取决于你的业务场景能接受多长时间的缓存不一致。

2. 缓存穿透

缓存穿透是指一个请求要访问的数据，缓存和数据库中都没有，而用户短时间、高密度的发起这样的请求，每次都打到数据库服务上，给数据库造成了压力。一般来说这样的请求属于恶意请求。

解决方案有两种：

就是在数据库即使没有查询到数据，我们也把这次请求当做 key 缓存起来，value 可以是 NULL。下次同样请求就会命中这个 NULL，缓存层就处理了这个请求，不会对数据库产生压力。这样实现起来简单，开发成本很低。

3. 缓存雪崩

缓存雪崩是指缓存中大多数的数据在同一时间到达过期时间，而查询数据量巨大，这时候，又是缓存中没有，数据库中有的情况了。

防止雪崩的方案简单来说就是错峰过期。

在设置 key 过期时间的时候，在加上一个短的随机过期时间，这样就能避免大量缓存在同一时间过期，引起的缓存雪崩。

如果发了雪崩，我们可以有服务降级、熔断、限流手段来拒绝一些请求，保证服务的正常。但是，这些对用户体验是有一定影响的。

4. Redis 高可用架构

Redis 高可用架构，大家基本上都能想到主从、哨兵、集群这三种模式。

哨兵模式：

它主要执行三种类型的任务：

哨兵其实也是一个分布式系统，我们可以运行多个哨兵。

然后这些哨兵之间需要相互通气，交流信息，通过投票来决定是否执行自动故障迁移，以及选择哪个从服务器作为新的主服务器。

哨兵之间采用的协议是 gossip，是一种去中心化的协议，达成的是最终一致性。

选举规则：

若对本页面资源感兴趣，请点击下方或右方图片，注册登录后

搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源

如有其他疑问，请咨询右下角【在线客服】，谢谢支持！