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

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

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

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

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

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

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

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

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

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

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

下面就针对这两块，分享一下我认为比较合理的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密集型任务
• 单线程的优势

前言

我们都知道，Redis和Memcached都是内存数据库，它们的访问速度非常之快。但我们在开发过程中，这两个内存数据库，我们到底要如何选择呢？它们的优劣都有哪些？为什么现在看Redis要比Memcached更火一些？

这篇文章，我们就从各个方面来对比这两个内存数据库的差异，方便你在使用时，做出最符合业务需要的选择。

要分析它们的区别，主要从以下几个方面对比：

• 线程模型
• 数据结构
• 淘汰策略
• 管道与事物
• 持久化
• 高可用
• 集群化

最近在公司对redis做一些二次开发时，发现一个randomkey命令可能导致整个redis实例长时间阻塞的问题，redis版本为3.2.9，以此记录。

问题

由于我们公司使用的是redis集群版Codis，Codis内置的redis版本比较低，为3.2.9版本。

我们近期在做Codis双机房时，需要对redis增加一些功能以此支持双机房，在开发和测试中发现，执行randomkey命令有可能导致整个redis长时间阻塞的问题。

背景

用了5年的MacBook Pro 13寸，以零故障的记录光荣退役了。不得不说，前几年的MacBook品控做的是真好，整机非常耐用。

但后来的MacBook由于在硬件层面做了很多调整，之后的机器或多或少都出现过各种问题，身边的同事和朋友都遇到过一些，例如键盘故障、触控板问题，当然苹果售后也很给力，只要检查出故障就会马上换新，甚至连主板都直接换掉。

不过这次，我也终于入手了最新款的MacBook，更换的原因是因为之前的电脑性能实在跟不上了，常年在公司办公，已经变得越来越慢，Chrome打开的网页一多就能感觉到明显的卡顿情况。

这次入手的这款MacBook Pro是16寸的，配置为i9 CPU + 64G内存 + 1T固态硬盘 + 5300M独立显卡，除了硬盘和显卡之外，其他项选择的都是顶配。

有朋友觉得内存没必要选这么大的，我之前的13寸MacBook Pro只有8G内存，小的可怜，这次直接一步到位，再也不会受到内存瓶颈的影响。另外这台新电脑也计划准备陪我再战4-5年，选这个配置也足够为我未来工作和学习的变化提供足够的支撑。

拿到手里第一个感觉真的是：大！视觉冲击很棒！13寸的用了太久，这次尝试体验一下16寸的，新鲜感十足！