为 Redis 选择最佳过期策略：一致性和性能 (为redis添加密码验证)

Redis 是一个流行的开源键值存储，以其高性能和灵活性而闻名。它支持多种过期策略，允许在键过期后以不同的方式处理数据。

过期策略类型

Redis 提供了以下过期策略：无过期(noexpire)： 键永远不会过期。过期 (expire)： 在指定时间后键过期。过期与逐出 (expireat)： 在特定时间键过期。过期并修改 (expirewith)： 在指定时间后键过期，同时更新另一个键。惰性过期 (lazyexpire)： 只有在键被访问时才会检查其过期设置。

选择最佳策略

选择最佳过期策略取决于应用程序的具体需求。以下是一些需要考虑的因素：一致性： 某些策略比其他策略更能保证数据一致性。性能： 某些策略比其他策略更能提高性能。应用程序行为： 应用程序如何使用键会影响过期策略的选择。

一致性和性能比较

下表比较了不同过期策略的一致性和性能：| 过期策略 | 一致性 | 性能 | |---|---|---| | 无过期 | 低 | 高 | | 过期 | 中等 | 中等 | | 过期与逐出 | 高 | 低 | | 过期并修改 | 高 | 低 | | 惰性过期 | 低 | 高 |从表中可以看出：无过期提供最高性能，但一致性最低。过期在一致性和性能之间提供了良好的平衡。过期与逐出和过期并修改具有最高一致性，但性能可能较低。惰性过期提供高性能，但一致性最低。

特定场景下的最佳策略

对数据一致性要求高且性能要求低的场景： 使用过期与逐出或过期并修改策略。对性能要求高且数据一致性要求低的场景： 使用无过期或惰性过期策略。对性能和一致性要求都高的场景： 使用过期策略或根据需要在过期与逐出和过期并修改策略之间切换。

为 Redis 添加密码验证

为了保护 Redis 服务器免受未经授权的访问，强烈建议添加密码验证。以下是如何为 Redis 添加密码验证：1. 在 Redis 配置文件中添加以下行：requirepass mysecretpassword2. 其中mysecretpassword是您希望使用的密码。 3. 保存并重新启动 Redis 服务器。 4. 现在，每当您连接到 Redis 服务器时，都会被要求提供密码。

结论

选择正确的过期策略和实施密码验证对于确保 Redis 应用程序的可靠性和安全性至关重要。通过在一致性、性能和应用程序行为之间取得适当的平衡，您可以优化 Redis 的性能并保护其免受未经授权的访问。

---

Redis怎么设置密码

redis密码设置有两种方式，一种需要重启redis服务，一种不需要重启redis服务。 下面本篇文章就来给大家介绍一下这两种方式，希望对你们有所帮助。 方法一：通过配置文件（/etc/）进行设置这种方法在设置密码后需要重启redis生效。 首先找到redis的配置文件—文件，然后修改里面的requirepass（requirepass 是配置redis访问密码的参数），这个本来是注释起来了的，将注释去掉，并将后面对应的字段设置成自己想要的密码，保存退出。 重启redis服务，即可。 （推荐学习：Redis视频教程）我这里是设置密码成了123方法二：通过命令设置密码这种方法相对简单，不需要重启redis服务。 连接redis之后，通过命令设置，如下：config set requirepass 如此，便将密码设置成了设置之后，可通过以下指令查看密码config get requirepass密码设置之后，当你退出再次连上redis的时候，就需要输入密码了，不然是无法操作的。 这里有两种方式输入密码，一是连接的时候直接输入密码，而是连接上之后再输入密码，分别如下所示：注：通过命令行修改了密码之后，配置文件（/etc/）的requirepass字段后面的密码是不会随之修改的。 更多redis相关技术知识，请访问Redis使用入门教程栏目学习！

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 过期策略 和 回收策略

惰性策略就是在客户端访问这个 key 的时候，redis 对 key 的过期时间进行检查，如果过期了就立即删除。 Redis 默认会每秒进行十次过期扫描，过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。 1.从过期字典中随机 20 个 key； 2.删除这 20 个 key 中已经过期的 key； 3.如果过期的 key 比率超过 1/4，那就重复步骤 1； 同时，为了保证过期扫描不会出现循环过度，导致线程卡死现象，算法还增加了扫描时间的上限，默认不会超过 25ms。 从库不会进行过期扫描，从库对过期的处理是被动的。 主库在 key 到期时，会在 AOF 文件里增加一条 del 指令，同步到所有的从库，从库通过执行这条 del 指令来删除过期的 key。 因为指令同步是异步进行的，所以主库过期的 key 的 del 指令没有及时同步到从库的话，会出现主从数据的不一致 这是由 redis 的过期策略来决定。 redis 过期策略是： 定期删除+惰性删除 。 所谓定期删除，指的是 redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。 假设 redis 里放了 10w 个 key，都设置了过期时间，你每隔几百毫秒，就检查 10w 个 key，那 redis 基本上就死了，cpu 负载会很高的，消耗在你的检查过期 key 上了。 注意，这里可不是每隔 100ms 就遍历所有的设置过期时间的 key，那样就是一场性能上的灾难。 实际上 redis 是每隔 100ms 随机抽取一些 key 来检查和删除的。 但是问题是，定期删除可能会导致很多过期 key 到了时间并没有被删除掉，那咋整呢？所以就是惰性删除了。 这就是说，在你获取某个 key 的时候，redis 会检查一下 ，这个 key 如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。 但是实际上这还是有问题的，如果定期删除漏掉了很多过期 key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期 key 堆积在内存里，导致 redis 内存块耗尽了，咋整？ 答案是：走内存淘汰机制。

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

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

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