目录Redis 为什么快1. 纯内存 KV 操作2. 单线程操作3. I/O 多路复用4. Reactor 设计模式Redis 合适的应用场景1. 会话缓存Session Cache2. 全页缓存FPC3. 队列4. 排行榜/计数器5. 发布/订阅Redis 6.0 之前为什么一直不使用多线程Redis 6.0 为什么要引入多线程Redis 有哪些高级功能为什么要用 RedisRedis 与 Memcached 相对有哪些优势怎么理解 Redis 中的事务为什么要使用 PipelineRedis 的过期策略以及内存淘汰机制什么是缓存穿透如何避免什么是缓存雪崩如何避免使用 Redis 如何设计分布式锁怎么使用 Redis 实现消息队列基于 List 的 LPUSH BRPOP 实现基于 Sorted-Set 的实现PUB/SUB 订阅/发布模式基于 Stream 类型的实现什么是 BigKey会有什么影响BigKey 的危害Redis 如何解决 Key 冲突怎么提高缓存命中率Redis 持久化方式有哪些有什么区别RDB 的优缺点AOF 的优缺点为什么 Redis 需要把所有数据放到内存中如何保证缓存与数据库双写时的数据一致性第一种方案采用延时双删策略第二种方案异步更新缓存基于订阅 Binlog 的同步机制Redis 集群方案应该怎么做Redis 集群方案什么情况下会导致整个集群不可用说一说 Redis 哈希槽的概念Redis 集群会有写操作丢失吗为什么Redis 常见性能问题和解决方案有哪些一、缓存穿透二、缓存击穿三、缓存雪崩四、三者的对比总结综合防御架构建议热点数据和冷数据是什么什么情况下可能会导致 Redis 阻塞什么时候选择 Redis什么时候选择 MemcachedRedis 过期策略都有哪些LRU 算法知道吗Redis 为什么快1. 纯内存 KV 操作Redis 的操作都是基于内存的CPU 不是 Redis 的性能瓶颈Redis 的瓶颈是机器内存和网络带宽。在计算机的世界中CPU 的速度是远大于内存的速度的同时内存的速度也是远大于硬盘的速度。Redis 的操作都是基于内存的绝大部分请求是纯粹的内存操作非常迅速。2. 单线程操作使用单线程可以省去多线程时 CPU 上下文切换的时间也不用去考虑各种锁的问题不存在加锁释放锁操作没有死锁问题导致的性能消耗。对于内存系统来说多次读写都是在一个 CPU 上没有上下文切换效率就是最高的既然单线程容易实现而且 CPU 不会成为瓶颈那就顺理成章地采用单线程的方案了。Redis 单线程指的是网络请求模块使用了一个线程即一个线程处理所有网络请求其他模块该使用多线程的仍会使用多个线程。3. I/O 多路复用为什么 Redis 中要使用 I/O 多路复用这种技术呢首先Redis 是跑在单线程中的所有的操作都是按照顺序线性执行的但是由于读写操作等待用户输入或输出都是阻塞的所以 I/O 操作在一般情况下往往不能直接返回这会导致某一文件的 I/O 阻塞导致整个进程无法对其他客户提供服务而 I/O 多路复用就是为了解决这个问题而出现的。4. Reactor 设计模式Redis 基于 Reactor 模式开发了自己的网络事件处理器称之为文件事件处理器File Event Handler。Redis 合适的应用场景1. 会话缓存Session Cache最常用的一种使用 Redis 的情景是会话缓存Session Cache。用 Redis 缓存会话比其他存储如 Memcached的优势在于Redis 提供持久化。当维护一个不是严格要求一致性的缓存时如果用户的购物车信息全部丢失大部分人都会不高兴的。幸运的是随着 Redis 这些年的改进很容易找到怎么恰当使用 Redis 来缓存会话的文档。甚至广为人知的商业平台 Magento 也提供 Redis 的插件。2. 全页缓存FPC除基本的会话 Token 之外Redis 还提供很简便的 FPC 平台。回到一致性问题即使重启了 Redis 实例因为有磁盘的持久化用户也不会看到页面加载速度的下降这是一个极大改进类似 PHP 本地 FPC。再次以 Magento 为例Magento 提供一个插件来使用 Redis 作为全页缓存后端。此外对 WordPress 的用户来说Pantheon 有一个非常好的插件 wp-redis这个插件能帮助你以最快速度加载曾浏览过的页面。3. 队列Redis 在内存存储引擎领域的一大优点是提供 List 和 Set 操作这使得 Redis 能作为一个很好的消息队列平台来使用。Redis 作为队列使用的操作就类似于本地程序语言如 Python对 List 的 Push/Pop 操作。如果你快速在 Google 中搜索Redis queues马上就能找到大量的开源项目这些项目的目的就是利用 Redis 创建非常好的后端工具以满足各种队列需求。例如Celery 有一个后台就是使用 Redis 作为 Broker。4. 排行榜/计数器Redis 在内存中对数字进行递增或递减的操作实现得非常好。集合Set和有序集合Sorted Set也使得我们在执行这些操作的时候变得非常简单。所以我们要从排序集合中获取到排名最靠前的 10 个用户——我们称之为user_scores只需要执行ZRANGE user_scores 0 10即可。当然这是假定根据用户的分数做递增的排序。如果想返回用户及用户的分数需要这样执行ZRANGE user_scores 0 10 WITHSCORES。Agora Games 就是一个很好的例子用 Ruby 实现的它的排行榜就是使用 Redis 来存储数据的。5. 发布/订阅最后但肯定不是最不重要的是 Redis 的发布/订阅功能。发布/订阅的使用场景确实非常多。可以在社交网络连接中使用还可作为基于发布/订阅的脚本触发器甚至用 Redis 的发布/订阅功能来建立聊天系统。Redis 6.0 之前为什么一直不使用多线程官方曾做过类似问题的回复使用 Redis 时几乎不存在 CPU 成为瓶颈的情况Redis 主要受限于内存和网络。例如在一个普通的 Linux 系统上Redis 通过使用 Pipelining 每秒可以处理 100 万个请求所以如果应用程序主要使用 O(N) 或 O(log(N)) 的命令它几乎不会占用太多 CPU。使用了单线程后可维护性高。多线程模型虽然在某些方面表现优异但是它却引入了程序执行顺序的不确定性带来了并发读写的一系列问题增加了系统复杂度同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。Redis 通过 AE 事件模型以及 I/O 多路复用等技术处理性能非常高因此没有必要使用多线程。单线程机制使得 Redis 内部实现的复杂度大大降低Hash 的惰性 Rehash、LPush 等等线程不安全的命令都可以无锁进行。TipRedis的版本很多3.X、4.X、6.X版本不同架构也是不同的不限定版本问是否单线程也不太严谨。版本3.×最早版本也就是大家口口相传的Redis是单线程版本4.×严格意义来说也不是单线程而是负责处理客户端请求的线程单线程但是开始加了点多线程的东西异步删除版本6.x 开始全面支持多线程。Redis 6.0 为什么要引入多线程Redis 将所有数据放在内存中内存的响应时长大约为 100 纳秒对于小数据包Redis 服务器可以处理 80,000 到 100,000 QPS这也是 Redis 处理的极限了。对于 80% 的公司来说单线程的 Redis 已经足够使用了。但随着越来越复杂的业务场景有些公司动不动就上亿的交易量因此需要更大的 QPS。常见的解决方案是在分布式架构中对数据进行分区并采用多个服务器但该方案有非常大的缺点例如要管理的 Redis 服务器太多维护代价大某些适用于单个 Redis 服务器的命令不适用于数据分区数据分区无法解决热点读/写问题数据偏斜重新分配和放大/缩小变得更加复杂等等。Redis 有哪些高级功能消息队列、自动过期删除、事务、数据持久化、分布式锁、附近的人、慢查询分析、Sentinel 和集群等多项功能。为什么要用 Redis使用缓存的目的就是提升读写性能。而实际业务场景下更多的是为了提升读性能带来更好的性能带来更高的并发量。Redis 的读写性能比 MySQL 好得多我们可以把 MySQL 中的热点数据缓存到 Redis 中提升读取性能同时也减轻了 MySQL 的读取压力。Redis 与 Memcached 相对有哪些优势数据类型丰富Memcached 所有的值均是简单的字符串Redis 作为其替代者支持更为丰富的数据类型。性能更优Redis 的速度比 Memcached 快很多。持久化支持Redis 可以持久化其数据。高可用架构Redis 支持数据的备份即 Master-Slave 模式的数据备份。底层模型优化使用底层模型不同它们之间底层实现方式以及与客户端之间通信的应用协议不一样。Redis 直接自己构建了 VM 机制因为一般的系统调用系统函数的话会浪费一定的时间去移动和请求。Value 大小限制Redis 最大可以达到 1GB而 Memcached 只有 1MB。怎么理解 Redis 中的事务事务是一个单独的隔离操作事务中的所有命令都会序列化、按顺序地执行事务在执行的过程中不会被其他客户端发送来的命令请求所打断。事务是一个原子操作事务中的命令要么全部被执行要么全部都不执行。不过 Redis 的是弱事务。事务是 Redis 实现在服务器端的行为用户执行 MULTI 命令时服务器会将对应这个用户的客户端对象设置为一个特殊的状态在这个状态下后续用户执行的查询命令不会被真的执行而是被服务器缓存起来直到用户执行 EXEC 命令为止服务器会将这个用户对应的客户端对象中缓存的命令按照提交的顺序依次执行。Redis 提供了简单的事务之所以说它简单主要是因为它不支持事务中的回滚特性同时无法实现命令之间的逻辑关系计算当然也体现了 Redis 的Keep It Simple的特性。为什么要使用 PipelinePipeline流水线机制能改善上面这类问题它能将一组 Redis 命令进行组装通过一次 RTT 传输给 Redis再将这组 Redis 命令的执行结果按顺序返回给客户端。没有使用 Pipeline 执行了 n 条命令整个过程需要 n 次 RTT。使用 Pipeline 执行了 n 次命令整个过程需要 1 次 RTT。Redis 的过期策略以及内存淘汰机制Redis 采用的是定期删除 惰性删除策略。为什么不用定时删除策略定时删除用一个定时器来负责监视 Key过期则自动删除。虽然内存及时释放但是十分消耗 CPU 资源。在大并发请求下CPU 要将时间应用在处理请求而不是删除 Key因此没有采用这一策略。定期删除 惰性删除是如何工作的定期删除Redis 默认每个 100ms 检查是否有过期的 Key有过期 Key 则删除。需要说明的是Redis 不是每个 100ms 将所有的 Key 检查一次而是随机抽取进行检查如果每隔 100ms 全部 Key 进行检查Redis 岂不是卡死。因此如果只采用定期删除策略会导致很多 Key 到时间没有删除。惰性删除也就是说在你获取某个 Key 的时候Redis 会检查一下这个 Key 如果设置了过期时间那么是否过期了如果过期了此时就会删除。内存淘汰策略noeviction返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令。allkeys-lru尝试回收最少使用的键LRU使得新添加的数据有空间存放。volatile-lru尝试回收最少使用的键LRU但仅限于在过期集合的键使得新添加的数据有空间存放。allkeys-random回收随机的键使得新添加的数据有空间存放。volatile-random回收随机的键使得新添加的数据有空间存放但仅限于在过期集合的键。volatile-ttl回收在过期集合的键并且优先回收存活时间TTL较短的键使得新添加的数据有空间存放。什么是缓存穿透如何避免缓存穿透指查询一个一定不存在的数据如果从存储层查不到数据则不写入缓存这将导致这个不存在的数据每次请求都要到 DB 去查询可能导致 DB 挂掉。解决方案缓存空值查询返回的数据为空仍把这个空结果进行缓存但过期时间会比较短。布隆过滤器将所有可能存在的数据哈希到一个足够大的 Bitmap 中一个一定不存在的数据会被这个 Bitmap 拦截掉从而避免了对 DB 的查询。什么是缓存雪崩如何避免缓存雪崩设置缓存时采用了相同的过期时间导致缓存在某一时刻同时失效请求全部转发到 DBDB 瞬时压力过重雪崩。与缓存击穿的区别雪崩是很多 Key击穿是某一个 Key 缓存。解决方案将缓存失效时间分散开比如可以在原有的失效时间基础上增加一个随机值比如 1-5 分钟随机这样每一个缓存的过期时间的重复率就会降低就很难引发集体失效的事件。使用 Redis 如何设计分布式锁基于 Redis 实现的分布式锁一个严谨的流程如下加锁SET lock_key $unique_id EX $expire_time NX操作共享资源释放锁Lua 脚本先 GET 判断锁是否归属自己再 DEL 释放锁怎么使用 Redis 实现消息队列基于 List 的 LPUSH BRPOP 实现足够简单消费消息延迟几乎为零但是需要处理空闲连接的问题。如果线程一直阻塞在那里Redis 客户端的连接就成了闲置连接闲置过久服务器一般会主动断开连接减少闲置资源占用这个时候 BLPOP 和 BRPOP 会抛出异常所以在编写客户端消费者的时候要小心如果捕获到异常还要重试。其他缺点包括做消费者确认 ACK 麻烦不能保证消费者消费消息后是否成功处理的问题宕机或处理异常等通常需要维护一个 Pending 列表保证消息处理确认。不能做广播模式如 Pub/Sub 消息发布/订阅模型。不能重复消费一旦消费就会被删除。不支持分组消费。基于 Sorted-Set 的实现多用来实现延迟队列当然也可以实现有序的普通消息队列但是消费者无法阻塞地获取消息只能轮询不允许重复消息。PUB/SUB 订阅/发布模式优点典型的广播模式一个消息可以发布到多个消费者。多信道订阅消费者可以同时订阅多个信道从而接收多类消息。消息即时发送消息不用等待消费者读取消费者会自动接收到信道发布的消息。缺点消息一旦发布不能接收。换句话说就是发布时若客户端不在线则消息丢失不能寻回。不能保证每个消费者接收的时间是一致的。若消费者客户端出现消息积压到一定程度会被强制断开导致消息意外丢失通常发生在消息的生产远大于消费速度时。可见Pub/Sub 模式不适合做消息存储、消息积压类的业务而是擅长处理广播、即时通讯、即时反馈的业务。基于 Stream 类型的实现基本上已经有了一个消息中间件的雏形可以考虑在生产过程中使用。什么是 BigKey会有什么影响BigKey 是指 Key 对应的 Value 所占的内存空间比较大。例如一个字符串类型的 Value 最大可以存到 512MB一个列表类型的 Value 最多可以存储 2^32-1 个元素。如果按照数据结构来细分一般分为字符串类型 BigKey和非字符串类型 BigKey字符串类型体现在单个 Value 值很大一般认为超过 10KB 就是 BigKey但这个值和具体的 OPS 相关。非字符串类型哈希、列表、集合、有序集合体现在元素个数过多。BigKey 无论是空间复杂度和时间复杂度都不太友好。BigKey 的危害BigKey 的危害体现在三个方面内存空间不均匀平衡例如在 Redis Cluster 中BigKey 会造成节点的内存空间使用不均匀。超时阻塞由于 Redis 单线程的特性操作 BigKey 比较耗时也就意味着阻塞 Redis 可能性增大。网络拥塞每次获取 BigKey 产生的网络流量较大。假设一个 BigKey 为 1MB每秒访问量为 1000那么每秒产生 1000MB 的流量。对于普通的千兆网卡按照字节算是 128MB/s的服务器来说简直是灭顶之灾。而且一般服务器会采用单机多实例的方式来部署也就是说一个 BigKey 可能会对其他实例造成影响其后果不堪设想。Redis 如何解决 Key 冲突遇到 Hash 冲突采用链表进行处理。怎么提高缓存命中率需要在业务需求、缓存粒度、缓存策略、技术选型等各个方面去通盘考虑并做权衡。尽可能地聚焦在高频访问且时效性要求不高的热点业务上通过缓存预加载预热、增加存储容量、调整缓存粒度、更新缓存等手段来提高命中率。Redis 持久化方式有哪些有什么区别Redis 提供RDB、AOF、混合持久化三种方式。RDB 的优缺点优点RDB 持久化文件速度比较快而且存储的是一个二进制文件传输起来很方便。缺点RDB 无法保证数据的绝对安全有时候就是 1 秒也会有很大的数据丢失。AOF 的优缺点优点AOF 相对 RDB 更加安全一般不会有数据的丢失或者很少。官方推荐同时开启 AOF 和 RDB。缺点AOF 持久化的速度相对于 RDB 较慢存储的是一个文本文件到了后期文件会比较大传输困难。为什么 Redis 需要把所有数据放到内存中Redis 为了达到最快的读写速度将数据都读到内存中并通过异步的方式将数据写入磁盘所以 Redis 具有快速和数据持久化的特征。如果不将数据放在内存中磁盘 I/O 速度会严重影响 Redis 的性能。如何保证缓存与数据库双写时的数据一致性第一种方案采用延时双删策略具体的步骤就是先删除缓存再写数据库休眠 500 毫秒再次删除缓存。第二种方案异步更新缓存基于订阅 Binlog 的同步机制技术整体思路MySQL Binlog 增量订阅消费 消息队列 增量数据更新到 Redis。Redis 集群方案应该怎么做Redis Sentinel体量较小时选择 Redis Sentinel单主 Redis 足以支撑业务。Redis ClusterRedis 官方提供的集群化方案体量较大时选择 Redis Cluster通过分片使用更多内存。TwemproxyTwemproxy 是 Twitter 开源的一个 Redis 和 Memcached 代理服务器主要用于管理 Redis 和 Memcached 集群减少与 Cache 服务器直接连接的数量。CodisCodis 是一个代理中间件当客户端向 Codis 发送指令时Codis 负责将指令转发到后面的 Redis 来执行并将结果返回给客户端。一个 Codis 实例可以连接多个 Redis 实例也可以启动多个 Codis 实例来支撑每个 Codis 节点都是对等的这样可以增加整体的 QPS 需求还能起到容灾功能。客户端分片在 Redis Cluster 还没出现之前使用较多现在基本很少使用了。在业务代码层实现起几个毫无关联的 Redis 实例在代码层对 Key 进行 Hash 计算然后去对应的 Redis 实例操作数据。这种方式对 Hash 层代码要求比较高考虑部分包括节点失效后的替代算法方案、数据震荡后的自动脚本恢复、实例的监控等等。Redis 集群方案什么情况下会导致整个集群不可用当访问一个 Master 和 Slave 节点都挂了的槽的时候会报槽无法获取。当集群 Master 节点个数小于 3 个的时候或者集群可用节点个数为偶数的时候基于 Fail 的这种选举机制的自动主从切换过程可能会不能正常工作。一个是标记 Fail 的过程一个是选举新的 Master 的过程都有可能异常。说一说 Redis 哈希槽的概念Slot称为哈希槽。Redis 集群中内置了16384 个哈希槽。当需要在 Redis 集群中放置一个 Key-Value 时Redis 先对 Key 使用 CRC16 算法算出一个结果然后把结果对 16384 求余数这样每个 Key 都会对应一个编号在 0-16383 之间的哈希槽。Redis 会根据节点数量大致均等地将哈希槽映射到不同的节点。使用哈希槽的好处就在于可以方便地添加或移除节点当需要增加节点时只需要把其他节点的某些哈希槽挪到新节点就可以了当需要移除节点时只需要把移除节点上的哈希槽挪到其他节点就行了。Redis 集群会有写操作丢失吗为什么以下情况可能导致写操作丢失过期 Key 被清理最大内存不足导致 Redis 自动清理部分 Key 以节省空间主库故障后自动重启从库自动同步单独的主备方案网络不稳定触发哨兵的自动切换主从节点切换期间会有数据丢失。Redis 常见性能问题和解决方案有哪些一、缓存穿透就是查询一个压根就不存在的数据即缓存中没有数据库中也没有。典型场景恶意攻击构造大量不存在的 ID 进行查询业务误用查询已被删除或从未存在的数据解决方案布隆过滤器在访问缓存前先用布隆过滤器判断 key 是否存在。优点是空间效率极高适合大数据量场景缺点是有一定误判率可能误判为存在但不会误判为不存在且不支持删除操作。缓存空值数据库查询为空时也将空值写入缓存设置较短 TTL如 5 分钟。这样下次同样的查询会直接命中缓存。优点是实现简单有效缺点是会占用部分缓存空间如果攻击者构造大量不同的无效 key可能导致缓存被撑满。参数校验对请求参数进行合法性校验拦截明显非法的请求。这是成本最低的方案应该在系统入口层就实施比如 ID 格式校验、范围校验等。二、缓存击穿数据库中有缓存中没有。缓存击穿实际就是一个并发问题。一般来说查询数据先查询缓存有直接返回没有再查询数据库并放到缓存中之后返回。但这种场景在并发情况下就会有问题假设同时有 100 个请求执行上面逻辑的代码则可能会出现多个请求都查询数据库因为大家同时执行都查到了缓存中没有数据。简单来说就是一个热点 key在缓存过期的瞬间大量并发请求同时打到数据库。典型场景热点数据过期如微博热搜、秒杀商品信息高并发下缓存失效解决方案互斥锁分布式锁缓存失效时只允许一个线程去查询数据库并重建缓存其他线程等待或重试。优点是保证数据一致性缺点是等待线程会有延迟实现复杂度较高需要处理锁的获取、释放和超时问题。如果是单机部署则可以使用 JVM 级别的锁如 Lock、Synchronized。如果是集群部署则需要使用分布式锁如基于 Redis、ZooKeeper、MySQL 等实现的分布式锁。逻辑过期不设置 Redis 的 TTL而是在 value 中存储一个逻辑过期时间字段。当发现数据过期时由一个线程异步去重建缓存其他线程返回旧数据。优点是系统响应无延迟可用性高缺点是短时间内可能返回旧数据存在数据不一致窗口期。永不过期对于热点 key 不设置过期时间通过后台异步任务定期更新或手动触发更新。优点是彻底避免击穿风险缺点是只适用于更新频率较低的热点数据需要额外的更新机制。三、缓存雪崩大量缓存 key同时失效、过期新的缓存又没来或缓存服务宕机导致大量的请求都去访问数据库而导致的服务器压力过大、宕机、系统崩溃。典型场景批量设置缓存时使用了相同的过期时间Redis 集群故障或重启缓存服务网络中断解决方案随机过期时间在基础过期时间上增加一个随机偏移量比如基础 1 小时加上 0-10 分钟的随机值。这样可以分散 key 的过期时间点避免集中失效。这是最简单有效的预防手段应该在所有缓存设置中作为默认策略。多级缓存构建本地缓存如 Caffeine、Guava Cache 分布式缓存Redis的两级架构。本地缓存作为第一级访问速度极快且不受 Redis 影响Redis 作为第二级。即使 Redis 挂掉本地缓存仍能支撑一段时间为系统恢复争取时间。缓存高可用部署 Redis 哨兵模式Sentinel或集群模式Cluster实现故障自动发现和主从切换。同时做好持久化配置RDB AOF确保故障后能快速恢复数据。熔断降级当检测到数据库压力过大或响应变慢时触发熔断机制直接返回默认值、缓存数据或错误提示而不是继续打到数据库。这能防止故障扩散保护核心系统。常用框架有 Hystrix、Sentinel 等。提前预热在业务高峰期前如秒杀开始前通过定时任务或手动操作主动将热点数据加载到缓存中并设置为永不过期或较长过期时间避免在高峰期出现缓存失效。四、三者的对比总结缓存穿透是查询不存在的数据数据库也查不到核心防御是布隆过滤器和空值缓存。缓存击穿是热点 key 过期导致的高并发问题核心防御是互斥锁和逻辑过期。缓存雪崩是大量 key 同时过期或缓存宕机核心防御是随机过期时间、多级缓存和高可用架构。综合防御架构建议一个完整的缓存防御体系应该分层构建最外层是参数校验和限流拦截非法请求然后是布隆过滤器快速判断 key 是否存在接着是本地缓存层用于防热点击穿和降低 Redis 压力再往下是 Redis 分布式缓存层采用随机过期时间和热点数据永不过期策略最后是熔断降级层保护数据库不被压垮最底层才是数据库。实际生产环境中这三种问题往往同时存在需要根据业务特点一致性要求、并发量、数据更新频率组合使用多种方案不能依赖单一手段。热点数据和冷数据是什么对于冷数据而言大部分数据可能还没有再次访问到就已经被挤出内存不仅占用内存而且价值不大。频繁修改的数据看情况考虑使用缓存。对于上面两个例子寿星列表、导航信息都存在一个特点就是信息修改频率不高读取通常非常高的场景。对于热点数据比如某 IM 产品的生日祝福模块当天的寿星列表缓存以后可能读取数十万次。再举个例子某导航产品将导航信息缓存以后可能读取数百万次。什么情况下可能会导致 Redis 阻塞数据集中过期不合理地使用 API 或数据结构CPU 饱和持久化阻塞。什么时候选择 Redis什么时候选择 Memcached实际业务分析如果业务中更加侧重性能的高效性对持久化要求不高那么应该优先选择Memcached。如果业务中对持久化有需求或者对数据涉及到存储、排序等一系列复杂的操作比如业务中有排行榜类应用、社交关系存储、数据排重、实时配置等功能那么应该优先选择Redis。Redis 过期策略都有哪些LRU 算法知道吗Redis 提供以下内存淘汰策略noeviction返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令。allkeys-lru尝试回收最少使用的键LRU使得新添加的数据有空间存放。volatile-lru尝试回收最少使用的键LRU但仅限于在过期集合的键使得新添加的数据有空间存放。allkeys-random回收随机的键使得新添加的数据有空间存放。volatile-random回收随机的键使得新添加的数据有空间存放但仅限于在过期集合的键。volatile-ttl回收在过期集合的键并且优先回收存活时间TTL较短的键使得新添加的数据有空间存放。