Redis 作为优秀的内存数据库，其拥有非常高的性能，单个实例的 OPS 能够达到 10W 左右。但也正因此如此，当我们在使用 Redis 时，如果发现操作延迟变大的情况，就会与我们的预期不符。

你也许或多或少地，也遇到过以下这些场景：

• 在 Redis 上执行同样的命令，为什么有时响应很快，有时却很慢？
• 为什么 Redis 执行 SET、DEL 命令耗时也很久？
• 为什么我的 Redis 突然慢了一波，之后又恢复正常了？
• 为什么我的 Redis 稳定运行了很久，突然从某个时间点开始变慢了？
• …

如果你并不清楚 Redis 内部的实现原理，那么在排查这种延迟问题时就会一头雾水。

如果你也遇到了以上情况，那么，这篇文章将会给你一个「全面」的问题排查思路，并且针对这些导致变慢的场景，我还会给你一个高效的解决方案。

在正文开始之前，我需要提醒你的是，这篇文章很长，涵盖的 Redis 知识点也非常广，全篇文章接近 2W 字，如果此时你的阅读环境不适合专注阅读，我建议你先收藏此文章，然后在合适的时间专注阅读这篇文章。

如果你能耐心且认真地读完这篇文章，我可以保证，你对 Redis 的性能调优将会有非常大的收获。

如果你准备好了，那就跟着我的思路开始吧！

这篇文章首发在极客时间App《Redis核心技术与实战》专栏。

写这篇文章的背景：

在极客时间App学习《Redis核心技术与实战》专栏时，由于我在评论区持续输出了高质量的内容，之后被此专栏邀请，为专栏供稿加餐内容。这是一篇帮助专栏读者如何高效学习的方法论分享。

另外一篇发表在此专栏的文章：《我是如何学习Redis的？高效学习Redis的路径和方法分享》

你好，我是Kaito。

上一次，我分享了我总结的Redis学习路径，在留言区的交流和互动中，我有了很多新的收获。今天，我想再分享一下我对学习这件事儿的认识以及我的学习方法，包括领先一步的心理建设、事半功倍的学习方法以及提升效率的小技巧。

领先一步：保持好奇+不设限

我认为，任何领域的学习，在研究具体的方法之前，我们都需要先在心理上领先别人一步。什么意思呢？其实就是要建立并保持好奇心，并且不给自己设限。

我发现，很多人是缺乏好奇心的，突出表现在只知其然，不知其所以然，不善于思考和挖掘问题。

给你举个小例子。刚开始接触Redis时，你肯定听说过一句话，Redis是单线程，高性能。很多人听完也就过去了，但是有好奇心的人，会进一步思考：“单线程如何处理多个客户端的网络请求呢？采用单线程的话，只能用到一个CPU核心，怎么达到高性能呢？”

顺着这个思路去学习的话，你就会发现，Redis虽然采用了单线程，但是它使用了多路复用技术，可以处理多个客户端的网络请求。而且，它的数据都存储在内存中，再加上高效的数据结构，所以处理每个请求的速度极快。

你看，带着好奇心去看问题，最终我们得到的远远超出想象。所以，我们要永远保持好奇心和深入探究的精神，它是我们不断进步的核心驱动力。

这篇文章首发在极客时间App《Redis核心技术与实战》专栏。

写这篇文章的背景：

在极客时间App学习《Redis核心技术与实战》专栏时，由于我在评论区持续输出了高质量的内容，之后被此专栏邀请，为专栏供稿加餐内容。这是一篇帮助专栏读者如何高效学习Redis的知识总结分享。

你好，我是Kaito。

很荣幸受到极客时间编辑的邀请，来和你分享一下我学习Redis的方法，希望可以帮助你更加高效地学习Redis。

我先做个自我介绍。

从毕业到现在，我已经工作7年了，目前是北京的一家移动互联网公司的资深研发工程师。我之前主导设计过垂直爬虫采集平台，后来开发面向用户的后端服务系统，现在在从事基础架构和数据库中间件方面的研发工作，主要聚焦在跨数据中心数据层的灾备与多活方面的研发。主要技术栈是Golang。

之前我们提到，为了保证Redis的高可用，主要需要以下几个方面：

• 数据持久化
• 主从复制
• 自动故障恢复
• 集群化

我们简单理一下这几个方案的特点，以及它们之间的联系。

数据持久化本质上是为了做数据备份，有了数据持久化，当Redis宕机时，我们可以把数据从磁盘上恢复回来，但在数据恢复之前，服务是不可用的，而且数据恢复的时间取决于实例的大小，数据量越大，恢复起来越慢。Redis的持久化过程可以参考Redis持久化是如何做的？RDB和AOF对比分析。

而主从复制则是部署多个副本节点，多个副本节点实时复制主节点的数据，当主节点宕机时，我们有完整的副本节点可以使用。另一方面，如果我们业务的读请求量很大，主节点无法承受所有的读请求，多个副本节点可以分担读请求，实现读写分离，这样可以提高Redis的访问性能。Redis主从复制的原理可以参考Redis的主从复制是如何做的？复制过程中也会产生各种问题？。

但有个问题是，当主节点宕机时，我们虽然有完整的副本节点，但需要手动操作把从节点提升为主节点继续提供服务，如果每次主节点故障，都需要人工操作，这个过程既耗时耗力，也无法保证及时性，高可用的程度将大打折扣。如何优化呢？

在上一篇文章：Redis为什么变慢了？常见延迟问题定位与分析，主要分析了Redis常见的导致变慢的场景以及问题定位和分析，主要是由业务使用不合理和运维不当导致的。

我们在了解了导致Redis变慢的原因之后，针对性地优化，就可以让Redis稳定发挥出更高性能。

这篇文章我们就来总结一下，在使用Redis时的最佳实践方式，主要包含两个层面：业务层面、运维层面。

由于我之前写过很多UGC后端服务，在大量场景下用到了Redis，这个过程中也踩过很多坑，所以在使用过程中也总结了一套合理的使用方法。

后来做基础架构，开发Codis、Redis相关的中间件，在这个阶段关注领域从使用层面下沉到Redis的开发和运维，更多聚焦在Redis的内部实现和运维过程中产生的各种问题，在这块也积累了一些经验。

下面就针对这两块，分享一下我认为比较合理的Redis使用和运维方法，不一定最全面，也可能与你使用Redis的方法不同，但以下这些方法都是我在踩坑之后总结的实际经验，供你参考。

重要提示：本篇文章写于2020年，后来内容经过迭代和完善，有了V2版本，内容更全面、细节更丰富，请直接看2021年写的这篇文章：Redis为什么变慢了？一文讲透如何排查Redis性能问题 | 万字长文。

Redis作为内存数据库，拥有非常高的性能，单个实例的QPS能够达到10W左右。但我们在使用Redis时，经常时不时会出现访问延迟很大的情况，如果你不知道Redis的内部实现原理，在排查问题时就会一头雾水。

很多时候，Redis出现访问延迟变大，都与我们的使用不当或运维不合理导致的。

这篇文章我们就来分析一下Redis在使用过程中，经常会遇到的延迟问题以及如何定位和分析。

前两篇文章：Redis的持久化如何做的？RDB和AOF对比分析和Redis的主从复制是如何做的？复制过程中也会产生各种问题？分别介绍了Redis数据持久化和数据复制的工作流程和相关原理。

这篇文章，我们来看Redis是如何实现故障自动恢复的，它的实现正是要基于之前所讲的数据持久化和数据多副本而做的。

Redis作为非常火热的内存数据库，其除了具有非常高的性能之外，还需要保证高可用，在故障发生时，尽可能地降低故障带来的影响，Redis也提供了完善的故障恢复机制：哨兵。

下面就来具体来看看Redis的故障恢复是如何做的，以及其中的原理。

如果Redis的读写请求量很大，那么单个实例很有可能承担不了这么大的请求量，如何提高Redis的性能呢？你也许已经想到了，可以部署多个副本节点，业务采用读写分离的方式，把读请求分担到多个副本节点上，提高访问性能。要实现读写分离，就必须部署多个副本，每个副本需要实时同步主节点的数据。

Redis也提供了完善的主从复制机制，使用非常简单的命令，就可以构建一个多副本节点的集群。

同时，当主节点故障宕机时，我们可以把一个副本节点提升为主节点，提高Redis的可用性。可见，对于故障恢复，也依赖Redis的主从复制，它们都是Redis高可用的一部分。

这篇文章我们就来介绍一下Redis主从复制流程和原理，以及在复制过程中有可能产生的各种问题。

从这篇文章开始，我们来介绍Redis高可用相关的机制。Redis要想实现高可用，主要有以下方面来保证：

• 数据持久化
• 主从复制
• 自动故障恢复
• 集群化

这篇文章我们先介绍Redis的高可用保障的基础：数据持久化。因为Redis的主从复制和自动故障恢复，都需要依赖Redis持久化相关的东西。同时，Redis的数据持久化也可以用来做数据备份，用来保障数据的安全性。

Redis是一个内存数据库，它的数据都保存在内存中，如果实例宕机，那么数据则全部丢失。如何保证数据的完整性和安全性也是提高服务高可用的重要机制之一。

Redis提供了完善的持久化机制，可以把内存中的数据持久化到磁盘上，方便我们进行备份数据和快速恢复数据。

这篇文章我们就来分析Redis的数据持久化是如何实现的？我们经常听的RDB和AOF有什么区别？以及它们不同的使用场景。

众所周知，Redis在内存库数据库领域非常地火热，它极高的性能和丰富的数据结构为我们的开发提供了极大的便利。

但我们也听说了，Redis是单线程的，为什么采用单线程的Redis也会如此之快呢？这篇文章我们来分析一下其中的缘由。

其实，严格来说，Redis Server是多线程的，只是它的请求处理整个流程是单线程处理的。这一点我们一定要清楚了解到，不要单纯地认为Redis Server是单线程的！

我们平时说的Redis单线程快是指它的请求处理过程非常地快！

下面我们就来分下一下为什么请求处理使用单线程，依旧可以达到这么高的性能。

Redis的性能非常之高，每秒可以承受10W+的QPS，它如此优秀的性能主要取决于以下几个方面：

• 纯内存操作
• 使用IO多路复用技术
• 非CPU密集型任务
• 单线程的优势