Redis 知识总结（基础知识 架构 调优和监控知识及难点解决）

1.Redis概览

Redis和memcache的区别，Redis支持的数据类型应用场景

redis支持的数据结构更丰富（string,hash,list,set,zset）omemcache只支

持key-value的存储；

redis原生支持集群，mcmcachc没有原生的集群模式。

2.Redis单线程模型

redis单线程处理请求流程

redis采用IO多路复用机制来处理请求，采用reactorlO模型，处理流程如下:

首先接收到客户端的sockel请求，多路复用器将socket转给连接应答处理

器；

连接应答处理器将AE_READABLE事件与命令请求处理器关联（这里是把

socket事件放入一个队列）；

命令请求处理器从socket中读到指令,再内存中执行，并将AE_WRITEABLE

事件与命令回复处理器关联；

命令回复处理器将结果返回给socket,并解除关联。

redis单线程效率高的原因

非阻塞10复用（上图流程），I/O多路复用分派事件，事件处理器处理事件（这

个可以理解为注册的一段函数，定义了事件发生的时候应该执行的动作），这里

分派事件和处理事件其实都是同一个线程；

纯内存操作效率高；

单线程反而避免了多线程切换。

3.Redis过期策略

对key设置有效期，redis的删除策略:定期删除+惰性删除。

定期删除指的是redis默认每100ms就随机抽取一些设置了过期事件的key,

检查是否过期，如果过期就删除。如果redis设置了10万个key都设置了过期时

间，每隔几百毫秒就要检查10万个key那CPU负载就很高了，所以redis并不

会每隔100ms就检查所有的key,而是随机抽取一些key来检查。

但这样会导致有些key过期「并没有被删除，所以采取「惰性删除。意思是

在获取某个key的时候发现过期了，如果key过期了就删除掉不会返回。

这两个策略结合起来保证过期的key一定会被删除。

最大内存淘汰（maxmemory-policy）

如果redis内存占用太多，就会进行内存淘汰。有如下策略：

noeviction:如果内存不足以写入数据，新写入操作直接报错；

allkeys-lru:内存不足以写入数据，移除最近最少使用的key（最常用的策略）；

allkeys-random:内存不足随机移除几个key；

volalile-lru:在设置了过期时间的key中，移除最近最少使用；

volatile-random:设置了过期的时间的key中，随机移除几个。

4.Redis主从模式保证高并发和高可用（哨兵模式）

读写分离

单机的Redis的QPS大概就在上万到几万不等，无法承受更高的并发。

读写分离保证高并发（10W+QPS）：对于缓存来说一般都是支撑高并发读，写

请求都是比较少的。采用读写分离的架构（一主多从），master负责接收写请求，

数据同步到slave上提供读服务，如果遇到瓶颈只需要增加slave机器就可以水

平扩容。

主从复制机制

redisreplication机制：

redis菜取异步复制到slave节点；

slave节点做复制操作的时候是不会block自己的，它会使用旧的数据集来提

供服务，复制。完成后，删除旧的数据集，加载新的数据集，这个时候会暂停服

务（时间很短暂）;

如果采用了主从架构，master需要开启持久亿。如果master没有开启持久化

（rdb和aof都关闭了）。master宕机重启后数据是空的，然后经过复制就把所有

slave的数据也弄丢了。

即使采用高可用的的哨兵机制,可能sentinal还没有检测到masterfailurc,

master就自动重启了，还是会导致slave清空故障。

主从同步流程

当slave启动时会发送一个psync命令给master；

如果是重新连接master,则masternode会复制给slave缺少的那部分数据；

如果是slave第一次连接master,则会触发一次全量复制

（fullresynchronization）o开始fullresynchronization的时候，master会生成一份rdb

快照，同时将客户端命令缓存在内存，rdb生成完后，就发送给slave,slave先

写入磁盘在加载到内存。然后master将缓存的命令发送给slave。

aWT

0*协

哨兵（sentinal）模式介绍

哨兵是redis集群架构的一个重要组件，主要提供如下功能:

集群监控：负责监控master和slave是否正常工作；

消息通知：如果某个redis实例有故障，哨兵负责发消息通知管理员；

故障转移:如果masternode发生故障，会自动切换到slave：

配置中心：如果故障转移发生了，通知客户端新的master地址。

哨兵的核心知识：

哨兵至少三个，保证自己的高可用；

哨兵+主从的部署架构是用来保证redis集群高可用的，并非保证数据不丢

失；

哨兵(Senlinel)需要通过不断的测试和观察才能保证高可用。

为什么哨兵只有两个节点无法正常工作

假设哨兵集群只部署了2个哨兵实例，quorum=lo

master宕机的时候，si和s2只要有一个哨兵认为master宕机j就可以进行

切换，并且会从si和s2中选取一个来进行故障转移。这个时候是需要满足

majority,也就是人多数哨兵是运行的，2个哨兵的majoriiy是2,如果2个哨兵

都运行着就允许执行故障转移。如果Ml所在的机器宕机了，那么si哨兵也就

挂了，只剩s2一个，没有majority］来允许执行故障转移，虽然集群还有一台机

器R1,但是故障转移也不会执行。

如果是经典的三哨兵集群，如下：

+------+

此时majority也是2,就算Ml所在的机器宕机了，哨兵还是剩下两个$2和

S3,它们满足majority就可以允许故障转移执行。

哨兵核心底层原理

sdown和odown两种失败状态；

sdown是主观宕机，就是一个哨兵觉得master宕机了，达成条件是如果一个

哨兵pingmaster超过了is-master-down-after-milliseconds指定的毫秒数后就认为

主观宕机；

odown是客观宕机，如果一个哨兵在指定时间内收到了majority（大多数）数

量的哨兵也认为那个master宕机了，就是客观宕机。

哨兵之间的互相发现：哨兵是通过redis的pub/sub实现的。

5.Rcdis数据的恢复（Redis的持久化）

RDB

RDB原理

RDB（RedisDataBase）是将某一个时刻的内存快照（Snapshot）,以二进制

的方式写入磁盘的过程。

RDB有两种方式save和bgsave:

save:执行就会触发Redis的持久化，但同时也是使Redis处于阻塞状态，直

到RDB持久化完成，才会响应其他客户端发来的命令；

bgsave:bgsave会fork。一个子进程来执行持久化，整个过程中只有在fork（）

子进程时有短暂的阻塞，当子进程被创建之后，Redis的主进程就可以响应其他

客户端的请求

RDB配置

除了使用save和bgsave命令触发之外，RDB支持自动触发。

自动触发策略可配置Redis在指定的时间内，数据发生了多少次变化时，会

自动执行bgsave命令。在redis配置文件中配置：

在时间m秒内，如果Redis数据至少发生了n次变化，那么就自动执行

BGSAVE命令。

savemn

RDB优缺点

RDB的优点

RDB会定时生成多个数据文件，每个数据文件都代表了某个时刻的redis全

量数据，适合做冷备，可以将这个文件上传到一个远程的安全存储中，以预定好

的策略来定期备份redis中的数据；

RDB对rcdis对外提供读写服务的影响非常小，redis是通过fork主进程的

一个子进程操作磁盘10来进行持久化的；

相对于A0F,直接基于RDB来恢复reids数据更快。

RDB的缺点：

如果使用RDB来恢复数据，会丢失一部分数据，因为RDB是定时生成的

快照文件；

‘RDB,每次来fork出子进程的时候，如果数据文件特别大，可能会影响对外

提供服务，暂停数秒（主进程需要拷贝自己的内存表给子进程，实例很大的时候

这个拷贝过程会很长）。latest_fork_usec代表fork导致的延时；Redis上执行NFO

命令查看latest_fork_usec；当RDB比较大的时候，应该在slave节点执行备份，

并在低峰期执行。

A0F

AOF原理

redis对每条写入俗令进行日志记录，以append-only的方式写入一个日志文

件，rcdis重启的时候通过重放日志文件来恢复数据集。（由于运行久了A0F文件

会越来越大，redis提供一种rewrite机制，基于当前内存中的数据集，来构建一

个更小的A0F文件，将旧的庞大的A0F文件删除）。rewrite即把日志文件压缩,

通过bgrewriteaof触发重写。AOFrewrite后台执行的方式和RDB有类似的地方，

fork一个子进程，主进程仍进行服务，子进程执行A0F持久化，数据被dump

到磁盘上。与RDB不同的是，后台子进程持久化过程中，主进程会记录期诃的

所有数据变更（主进程还在服务），并存储在server.aof_rewrite_buf_blocks中；

后台子进程结束后，Redis更新缓存追加到AOF文件中，是RDB百久化所不具

备的。

A0F的工作流程如下：

Redis执行写命令后，把这个命令写入到AOF文件内存中（write系统调用）;

Redis根据配置的A0F刷盘策略，把A0F内存数据刷到磁盘上（fsync系统

调用）；

根据rewrite相关的配置触发rewrite流程。

AOF配置

appendonly:是否启用AOF（yes|no）；

appcndfsync:刷盘的机制：

always：主线程每次执行写操作后立即刷盘，此方案会占用比较大的磁盘IO

资源，但数据安全性最高；

everysec：主线程每次写操作只写内存就返回，然后由后台线程每隔1秒执

行一次刷盘操作（触发fsync系统调用），此方案对性能影响相对较小，但当Redis

宕机时会丢失1秒的数据；

no：主线程每次写操作只写内存就返回，内存数据什么时候刷到磁盘，交由

操作系统决定，此方案对性能影响最小，但数据安全性也最低，Rcdis宕机时丢

失的数据取决于操作系统刷盘时机。

auto-aof-rewrite-percenlage:当aof文件相较于上一版本的aof文件大小的百分

比达到多少时触发AOF重写。举个例子，auto-aof-rewrite-percentage选项配置为

100,上一版本的aof文件大小为I00M,那么当我们的aof文件达到200M的时

候，触发AOF重写；

auto-aof-rewite-min-size：最小能容忍aof文件大小，超过这个大小必须进行

AOF重写；

no-appendfsync-on-rewrite:设置为yes表示rewrite期间对新写操作不fsync,

暂时存在内存中，等rewrite完成后再写入，默认为no。

AOF优缺点

AOF的优点：

可以更好的保证数据不丢失，一般AOF每隔1s通过一个后台线程来执行

fsync（强制刷新磁盘页缓存），最多丢失1s的数据；

AOF以appcnd-only的方式写入（顺序追加），没有磁盘寻址开销，性能很高;

AOF即使文件很天，触发后台rewrite的操作的时候一般也不会影响客户端

的读写，（rewrite的时候会对其中指令进行压缩，创建出一份恢复需要的最小日

志出来）

"在创建新的日志文件的时候，老的文件还是照常写入，当新的文件创建完成

后再交换新老日志。但是还是有可能会影响到主线程的写入，如：

当磁盘的IO负载很高，那这个后台线程在执行AOFfsync刷盘操作（fsync

系统调用）时就会被阻塞住，，紧接着，主线程又需要把数据写到文件内存中（write

系统调用），但此时的后台子线程由于磁盘负载过高，导致fsync发生阻塞，迟

迟不能返回，那主线桂在执行write系统调用时，也会被阻塞住，直到后台线程

fsync执行完成后，主线程执行wrile才能成功返回。这时候主线程就无法响应客

户端的请求，可能会导致客户端请求redis超时。

AOF日志文件通过非常可读的方式进行记录，这个特性适合做灾难性的误

操作的紧急恢复，比如不小心使用flushall清空了所有数据，只要rewrite没有发

生，就可以立即拷贝AOF,将最后一条flushall命令删除，再回放AOF恢复数

据。

AOF的缺点：

同一份数据•，因为AOF记录的命令会比RDB快照文件更大;

AOF开启后，支持写的QPS会比RDB支持写的QPS要低，毕竟AOF有写

磁盘的操作。

总结

总结AOF和RDB该如何选择：两者综合使用，将AOF配置成每秒fsync

一次。RDB作为冷备，AOF用来保证数据不丢失的恢复第一选择，当AOF文件

损坏或不可用的时候还可以使用RDB来快速恢复。

6.Redis集群模式（rediscluster）

在主从部署模式上，虽然实现了一定程度的高并发，并保证了高可用，但是

有如下限制：

master数据和slave数据一模样，master的数据量就是集群的限制瓶颈；

redis集群的写能力也受到了master节点的单机限制。

在高版本的Rcdis已经原生支持集群（cluster）模式，可以多master多slave部

署,横向扩展Redis集群的能力。RedisCIuster支持N个masternode,每个

masternode可以挂载多个slavenode。

rediscluster介绍

自动将数据切片，每个master上放一部分数据；

提供内置的高可用支持，部分master不可用时还是能够工作；

rediscluster模式下，每个redis要开放两个端口：6379和10000+以后的端口

（如16379）o16379是用来节点之间通信的，使用的是clustcrbus集群总线。

clusterbus用来做故障检测，配置更新，故障转移授权。

rediscluster负载均衡

rediscluster采用一致性hash+虚拟节点来负载均衡。rediscluster有固定的

16384个slol（2八14）,对每个key做CRC16值计算，然后对16384mod。可以获取

每个key的slotorediscluster每个master都会持有部分slot,比如三个master那

么每个master就会持有5000多个slotohashsloti±node的添加和删除变得很简

单，增加一个master,就将其他master的slot移动部分过去，减少一个就分给其

他master,这样让集群扩容的成本变得很低。

cluster基础通信原理（gossip协议）

与集中式不同（如使用zooke叩er进行分布式协调注册），rediscluster使用的

是gossip协议进行通信。并不是将集群元数据存储在某个节点上，而是不断的互

相通信，保持整个集群的元数据是完整的。gossip协议所有节点都持有一份元数

据，不同节点的元数据发生了变更，就不断的将元数据发送给其他节点，让其他

节点也进行元数据的变更。

集中式的好处：元数据的读取和更新时效性很好，一旦元数据变化就更新到

集中式存储，缺点就是元数据都在一个地方，可能导致元数据的存储压力。

对于gossip来说：元数据的更新会有延时，会降低元数据的压力，缺点是操

作是元数据更新可能会导致集群的操作有一些滞后。

rediscluster主备切换与高可用

判断节点宕机：如果有一个节点认为另外一个节点宕机，那就是pfaiL主观

宕机。如果多个节点认为一个节点宕机，那就是fail,客观宕机。跟哨兵的原理

一样；

对宕机的master,从其所有的slave中选取一个切换成masternode,再次之

前会进行一次过滤，检查每个slave与master的断开时间，如果超过了

cluster-node-timeout*clusler-slave-validity-factor就没有资格切换成master；

从节点选取：每个从节点都会根据从master复制数据的offset,来设置一个

选举时间，offset越大的从节点，选举时间越靠前，maslemode开始给slave选举

投票，如果大部分mast?r（n/2+l）都投给了某个slave,那么选举通过（与zk有点像，

选举时间类似于epochid）；

整个流程与哨兵类似，可以说redisclustcr集成了哨兵的功能，更加的强大；

Redis集群部署相关问题redis机器的配置，多少台机器，能达到多少qps?

机器标准:8核+32G

集群:5主+5从（每个master都挂一个slave）

效果:每台机器最高峰每秒大概5W,5台机器最多就是25W,每个master

都有一个从节点，任何一个节点挂了都有备份可切换成主节点进行故障转移

脑裂问题哨兵模式下：

master卜'挂载了3个slave,如果master由于网络抖动被哨兵认为宕机了，

执行了故障转移，从slave里面选取了一个作为新的master,这个时候老的master

又恢复了，刚好又有clienl连的还是老的masler,就会产生脑裂，数据也会不一

致，比如incr全局id也会重复。

redis对此的解决方案是：min-slaves-to-write1至少有一个slave连接

min-slaves-max-lag1Oslave与master主从复制延迟时间如果连接到master的slave

数小于最少slave的数量，并且主从复制延迟时间超过配置时间，master就拒绝

写入12oclient连接redis多tep连接的考量首先redisserver虽然是单线程来处理

请求，但是他是多路复用的，单tep连接肯定是没有多tep连接性能好，多路复

用一个i。周期得到的就绪i。事件越多，处理的就越多。这也不是绝对的，如果

使用pipeline的方式传输，单连接会比多连接性能好，因为每一个pipeline的单

次请求过多也会导致单周期到的命令太多，性能下降多少个连接比较合适这个问

题，rediscluser控制在每个节点100个连接以内。

本文包括：30个Redis基础知识；10个Redis架构和运维必懂的知识；Redis

调优、监控知识和10个具体应用难点。

30个Redis基础知识

1、Redis支持哪几种数据类型？

StringList>Set、SortedSet、hashes

2、Redis主要消耗什么物理资源？

Redis是一种基于内存高性能的数据库一主要依赖于内存

3、Redis哪几种数据淘汰策略？

nocviction：返回错误当内存限制达到并且客户端尝试执行会让更多内存被

使用的命令（大部分的写入指令，但DEL和几个例外）

allkeys-lru：尝试回收最少使用的键（LRU）,使得新添加的数据有空间存放。

volatile-lru：尝试回收最少使用的键（LRU）,但仅限于在过期集合的键，使

得新添加的数据有空间存放。

allkeys-random：回收随机的键使得新添加的数据有空间存放。

volatile-random：回收随机的键使得新添加的数据有空间存放，但仅限于在

过期集合的键。

volatile-tt：回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,

使得新添加的数据有空间存放。

4、为什么Redis需要把所有数据放到内存中？

Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将

数据写入磁盘。所以redis具有快速和数据持久化的特征。如果不将数据放在内

存中，磁盘I/O速度为严重影响redis的性能。在内存越来越便宜的今天，redis

将会越来越受欢迎。如果设置了最大使用的内存，则数据已有记录数达到内存限

值后不能继续插入新值。

5、Rcdis集群方案应该怎么做？都有哪些方案？

l.twemproxy,大概概念是，它类似于一个代理方式，使用方法和普通redis

无任何区别，设置好它下属的多个redis实例后，使用时在本需要连接redis的地

方改为连接twemproxy,它会以一个代理的身份接收请求并使用一致性hash算

法，将请求转接到具休redis,将结果再返回twemproxy。使用方式简便（相对redis

只需修改连接端口），对旧项目扩展的首选。问题：twemproxy自身单端口实例

的压力，使用一致性hash后，对redis节点数量改变时候的计算值的改变，数据

无法自动移动到新的节点。

2.codis,目前用的最多的集群方案，基本和twemproxy一致的效果，但它支

持在节点数量改变情况下，旧节点数据可恢复到新hash节点。

3.rediscluster3.O自带的集群，特点在于他的分布式算法不是一致性hash,而

是hash槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。

4.在业务代码层实现，起几个亳无关联的redis实例，在代码层，对key进

行hash计算，然后去对应的redis实例操作数据。这种方式对hash层代码要求

比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢

复，实例的监控，等等。

6、Redis集群方案什么情况下会导致整个集群不可用？

有A,B,C三个节点的集群，在没有复制模型的情况下，如果节点B失败了，

那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。

7、Redis如何设置密码及验证密码？

设置密码：

授权密码：

8、说说Redis哈希槽的概念？

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有

16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽,

集群的每个节点负责一部分hash槽。

9、Redis集群的主从复制模型是怎样的？

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所

以集群使用了主从复制模型，每个节点都会有N-1个复制品.

10、Redis集群会有写操作丢失吗？为什么？

Rcdis并不能保证数据的强一致性，这意味着在实际中集群在特定的条件下

可能会丢失与操作。

11、Redis集群之间是如何复制的？

异步复制

12、怎么理解Redis事务？

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。

事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

13、Redis事务相关的命令有哪几个?

MULTkEXEC、DISCARD、WATCH

14、Rediskey的过期时间和永久有效分别怎么设置？

EXPIRE和PERSIST命令。

15、Rcdis如何做内存优化？

尽可能使用散列表（hashes）,散列表（是说散列表里面存储的数少）使用

的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比

如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密

码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面。

16、Redis回收进程如何工作的？

一个客户端运行了新的命令，添加了新的数据。

Redi检查内存使用情况，如果大于maxmemory的限制，则根据设定好的策略

进行回收。

一个新的命令被执行，等等。

所以我们不断地穿越内存限制的边界，通过不断达到边界然后不断地回收回

到边界以下。

如果一个命令的结果导致大量内存被使用（例如很大的集合的交集保存到一

个新的键），不用多久内存限制就会被这个内存使用量超越。

17、Redis回收使用的是什么算法？

LRU算法

18、Rcdis如何做大量数据插入？

Redis2.6开始redis-cli支持一种新的被称之为pipemode的新模式用于执行大

量数据插入工作。

19、为什么要做Redis分区？

分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如

果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简

单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加

而成倍增长。

20、Redis持久化数据和缓存怎么做扩容？

如果Rcdis被当做缓存使用，使用一致性哈希实现动态扩容缩容。

如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射

关系，节点的数量一旦确定不能变化。否则的话（即Redis节点需要动态变化的

情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis

集群可以做到这样。

21、分布式Rcdis是前期做还是后期规模上来了再做好？为什么？

既然Redis是如此的轻量（单实例只使用1M内存），为防止以后的扩容，最

好的办法就是一开始就启动较多实例。即便你只有一台服务器，你也可以一开始

就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。

一开始就多设置几个Redis实例，例如32或者64个实例，对大多数用户来

说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。

这样的话，当你的数据不断增长，需要更多的Redis服务器时，你需要做的

就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已（而不用考虑重新

分区的问题）。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第

一台机器迁移到第二台机器。

22、都有哪些办法可以降低Redis的内存使用情况呢？

如果你使用的是32位的Redis实例，可以好好利用Hash,list,sorledset,set等

集合类型数据，因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到

一起。

23、查看Rcdis使用情况及状态信息用什么命令？

Info

24、Rcdis的内存用完了会发生什么？

如果达到设置的上限，Redis的写命令会返回错误信息(但是读命令还可以

正常返回。)或者你可以将Redis当缓存来使用配置淘汰机制，当Redis达到内存

上限时会冲刷掉旧的内容。

25.Redis是单线程的，如何提高多核CPU的利用率？

可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来

使用，在某些时候，无论如何一个服务器是不够的，所以，如果你想使用多个

CPU,你可以考虑一下分片(shard)。

26、一个Redis实例最多能存放多少的keys?List、Set、SortedSet他们最多

能存放多少元素？

理论上Redis可以处理多达232的keys,并且在实际中进行了测试，每个实

例至少存放了2亿5千万的keyso我们正在测试一些较大的值。

任何listsset^和sortedset都可以放232个元素。

换句话说，Rcdis的存储极限是系统中的可用内存值。

27、Rcdis常见性能问题和解决方案？

(l)Master最好不要做任何持久化工作，如RDB内存快照和AOF日志叉件

(2)如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同

步一次

(3)为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域

网内

(4)尽量避免在压力很大的主库上增加从库

(5)主从复制不要用图状结构，用单向链表结构更为稳定，即：

Master<-Slave1<-Slave2<-Slave3

这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master

挂了，可以立刻启用Slave1做Master,其他不变。

28、Redis提供了哪几种持久化方式？

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。

AOF持久化方式汜录每次对服务器写的操作，当服务器重启的时候会重新

执行这些命令来恢复原始的数据，AOF命令以rcdis协议追加保存每次写的操作

到文件末尾。Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至

于过大。

如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久

化方式。

你也可以同时开启两种持久化方式，在这种情况下，当redis重启的时候会

优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据

集要比RDB文件保存的数据集要完整。

最重要的事情是了解RDB和AOF持久化方式的不同，让我们以RDB持久

化方式开始。

29、如何选择合适的持久化方式？

一般来说，如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使

用两种持久化功能。如果你非常关心你的数据，但仍然可以承受数分钟以内的数

据丢失，那么你可以只使用RDB持久化。

有很多用户都只使用AOF持久化，但并不推荐这种方式:因为定时生成RDB

快照(snapshot)非常便于进行数据库备份，并且RDB恢复数据集的速度也要比

AOF恢复的速度要快，除此之外，使用RDB还可以避免之前提到的AOF程序

的bugo

30、修改配置不重启Redis会实时生效吗？

针对运行实例，有许多配置选项可以通过CONFIGSET命令进行修改，而无

需执行任何形式的重启。从Redis2.2开始，可以从AOF切换到RDB的快照持久

性或其他方式而不需要重启RediSo检索＜CONFIGGET,命令获取更多信息。

但偶尔重新启动是必须的，如为升级Redis程序到新的版本，或者当你需要

修改某些目前CONFIG命令还不支持的配置参数的时候。

10个Redis架构和运维必懂的知识

一、高可用相关

1、Redis常用高可用架构有哪些？

Redis高可用架构如下：

RedisSentinel集群+内网DNS+自定义脚本

RedisSentinel集群+VIP+自定义脚本

封装客户端直连RedisSentinel端口

JedisSentinelPool,适合Java

PHP基于phpredis自行封装

RedisSentinel集群+Keepalived/Haproxy

RedisM/S+Keepalived

RedisCluster

Twemproxy

Codis

2、Redis高可用架构优劣对比？

—RedisSentinel集群+内网DNS+自定义脚本

优点：

秒级切换

脚本自定义，架构可控

对应用透明

缺点：

维护成本略高

依赖DNS,存在解析延时

Sentinel模式存在短时间的服务不可用

—RedisSentinel集群+VIP+自定义脚本

优点：

秒级切换

脚本自定义，架构可控

对应用透明

缺点：

维护成本略高

Sentinel模式存在短时间的服务不可用

一封装客户端直连RedisSentinel端口

优点：

服务探测故障及时

DBA维护成本低

缺点：

依赖客户端支持Sentinel

Sentinel服务器需要开放访问权限

对应用有侵入性

—RedisSentinel集群+Keepalived/Haproxy

优点：

秒级切换

对应用透明

缺点：

维护成本高

存在脑裂

Sentinel模式存在短时间的服务不可用

一RedisM/S+Keepalived

优点：

秒级切换

对应用透明

部署简单，维护成本低

缺点：

需要脚本实现切换功能

存在脑裂

（RedisCluster^Twemproxy>Codis优劣对比见下个问题）

3、常见的Rcdis集群方案有哪些优缺点？

Twemproxy:

多个同构Twcmproxy（配置相同）同时工作，接受客户端的请求，根据hash

算法，转发给对应的Redis。

优点：

开发简单，对应用几乎透明

历史悠久，方案成熟

缺点：

代理影响性能

LVS和Twcmproxy会有节点性能瓶颈

Redis扩容非常麻烦

Twitler内部已放弃使用该方案，新使用的架构未开源

Codis:

ZooKeeper

存放路由表和代理节点元数据

分发Codis-Config的命令

Codis-Config集成管理工具，有web界面

Codis-Proxy

无状态代理，兼容Rcdis协议

对业务透明

Codis-Rcdis

基于2.8版本，二次开发

加入slot支持和迁移命令

优点：

开发简单，对应用几乎透明

性能比Twcmproxy好

有图形化界面，扩容容易，运维方便

缺点：

代理依旧影响性能

组件过多，需要很多机器资源

修改了Redis代码，导致和官方无法同步，新特性跟进缓慢

开发团队准备主推基于Redis改造的reborndb

RedisCluster:

P2P模式，无中心化。把key分成16384个slol,每个实例负责一部分slol。

客户端请求若不在连接的实例，该实例会转发给对应的实例。通过Gossip协议

同步节点信息。

优点：

组件all・in-box,部署简单，节约机器资源

性能比proxy模式好

自动故障转移、Slot迁移中数据可用

官方原生集群方案，更新与支持有保障

缺点：

架构比较新，最佳实践较少

多键操作支持有限（驱动可以曲线救国）

为了性能提升，客户端需要缓存路由表信息

节点发现、rcshard操作不够自动化

二、Redis通用

1、Redis相对MySQL、PostgreSQL这些关系型数据库，有什么优缺点？

期占—'•

Redis主要是用来做缓存，它有持久化，但也只是为了缓存的可靠而已，优

点是数据全放内存，速度快。缺点就是，数据大小不能超过内存大小。两个用在

不同业务场景，Redis无法取代传统关系型数据库。

观点二：

Redis首先它是一种内存数据库，最大的优势在于效率高;尤其在某些特定

场合下，例如热点数据量非常大，而数据从内存和磁盘之间的换入换出代价比较

高的情况下，Redis就会体现它的价值。

传统关系型数据库在于它对数据的一致性保障，它的数据模型范式是遵循严

格事务规则的结构化数据，由于其数据的高度抽象化，它调度到内存的数据一般

场合下不会占用很大的内存空间。

总的来说，两种数据库各有各的优点和缺点。不同的业务场合有特定的追求

目标，redis首要的是效率，适用的是一些单纯二维结构化数据无法表达的数据

模型，而关系型数据库处理的是可以用范式模型表达的二维数据，追求的是数据

的高度一致性。随着IT的发展，每一类型的数据库都会在其特定的场合内发挥

出无可比拟的优势，最终的趋势是大家趋于平衡，没有最好，只有最适合。

观点三：

记窘一句话：任何数据库都有自己的应用场景，应该关注数据流、数据属性。

个人的经验来说，Rcdis不可能取代MySQL或者PG。

2、Redis有哪些应用场景？

Rcdis是一个高性能的缓存，一般应用在Session缓存、队列、排行榜、计数

器、最近最热文章、最近最热评论、发布订阅等。

更多应用场景，可以参考此处。

可以这样讲，Redis适用于数据实时性要求高、数据存储有过期和淘汰特征

的，不需要持久化或者只需要保证弱一致性，逻置简单的场景。

3、新接手一个复杂的Redis集群（Sentinel模式），如何了解它

刚刚接手一套Redis集群，想要了解这套集群的相关配置。应该如何入手。

难道只能通过info命令去查看各个配置吗？

这是笔者的建议：

通读Sentinel官方文档

Google搜索RedisSentinel,找几篇中英文的文章看看

进入Sentinel集群后，使用inf。查看集群信息

查看Sentinel配置文件，配合文档搞清楚每个参数的含义

使用几台虚拟机模拟线上环境，然后做测试，在实践中深入理解

思考当前Sentinel集群是否有不合理的地方，如有，提出并改进

三、Redis故障排查

1、Redis实例中，存在大量的FIN_WAIT2连接

客户端TCP状态迁移：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TI

ME_WAIT->CLOSED

服务器TCP状态迁移：

CLOSED->L1STEN->SYN收至l]

->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

这个状态存在于主动发起时开请求的一端，如果服务器存在大量的这个状

态，那么这个服务器就充当客户端的角色，如网络爬虫，出现的原因是由于客户

端发起FIN请求结束连接之后，收到了服务端的应答之后进入FIN_WAIT2,之

后就没收到服务端发送的FIN信号导致。

PS：线上Web客户端用的什么语言？

2、如何知道当前Rcdis实例是处于阻塞状态？

解答一：随便get一个key,然后卡着不动就行，简单粗暴。优雅一点是看

latency的延迟，blockcd_clients的数量，rejected_connections的数量等。

解答二：_

方法一：登录Redis,执行info,查看blocked_clients

方法二：执行redis-cli-Iatency-h-p查看延时情况

3、Redis运维的故障有哪些？

回答一：常见的运维故障

使用keys*把库堵死，——建议使用别名把这个命令改名

超过内存使用后，部分数据被删除一一这个有删除策略的，选择适合自己的

即可

没开持久化，却重启了实例，数据全掉一一记得非缓存的信息需要打开持久

化

RDB的持久化需要vm.overcommit_memory=l,否则会持久化失败

没有持久化情况下，主从，主重启云快，从还没认为主挂的情况下，从会清

空自己的数据一一人为重启主节点前，先关闭从节点的同步

回答二：我简单说下Rcdis故障的排查方法吧。

了解清楚业务数据流是怎么样的

结合Redis监控查看QPS、缓存命中率、内存使用率等信息

确认机器层面的资源是否有异常

故障时及时上机，使用redis-climonilor打印出操作日志，然后分析（事后分

析此条失效）

和研发沟通，确认是否有大Key在堵塞（大Key也可以在日常的巡检中获

得）

和组内同事沟通，确实是否有误操作

和运维同事、研发一起排查流量是否正常，是否存在被刷的情况

更多的排查需要走线上系统的分析。

四、Redis性能优化

1、提高Redis内存数据库的性能，有哪些措施？

这个问题有点偏题了，还是回答下吧。整理下工作中积累的经验：

根据不同业务选择数据类型，有必要时对数据结构进行审核，减少数据冗余

精简犍名和键值，控制键值的大小

使用前缀管理好key

使用scan代替keys,将遍历RedisDB中所有key的操作放到客户端来做

避免使用0（N）复杂度的命令

配置使用ziplist来优化list

合理配置maxmemory

数据量大的情况，做好key和value的压缩

利用管道，批量处理命令

根据不同业务选择短链接或者长链接

定期使用redis-cli-big-keys检测大Key

Redis调优、监控知识和10个具体应用难点

一、Redis数据库的优缺点及适用场景

Redis持久服务的特点，key-value键值类型存储系统，支持数据可靠存储，

单进程单线程高性能服务器，恢复比较慢单机qps（秒并发）可以达到10W,适

合小数据高速读写访问。

Rcdis存储系统优、缺点：可以持久化存储数据，支持每秒10W的读写频率,

支持丰富的数据类型，所有操作都是原子性的，支持异机主从复制，内存管理开

销大（低于物理内存的3/5）,不同命令延迟差别大，官方网站：

主要使用场景分为两大块：

1、缓存：热点数据放到缓存里，大部分情况命中缓存，不命中时，访问磁

盘存储并更新缓存

2、键值存储，独立使用缓存作为数据提供方。依赖于缓存服务的可靠性不

高，业务对事务和数据的一致性要求不高。具体的，一般由架构师和开发人员，

根据业务的特性，设计出具体的使用方法。

二、Redis的调优参数

Redis的参数调优问题，根据场景不同，有不同的调优方法，以下列举踩过

的一些坑的参数调优。我们的场景的海量数据，高并发。

(1)timeout参数,非常需要关注,官方对timeout的解释如下:该参数表

示当某一个客户端连接上来并闲置timeout(单位秒)的时间后，Redis服务端就

主动关闭这个客户端连接。我们发现如果客户端对连接处理比较差的时候，存在

连接不释放的问题，导致连接池耗尽，单个redis默认的连接数是1000.所以需要

在timeoul参数做文章，强制释放无效连接，我们的参数调整为limeout30000

(2)持久化参数，RDB和AOF究竟开哪个，很多人很纠结。其实选择很

简单，两者的区别是持久化的颗粒度不一样，如果你关注数据的强一致性，选择

AOF,如果你选择更好的性能，选型RDBo如果你选择极致的性能，又能容忍

数据的丢失，那你可以完全不用开启持久化，当然了，集群是一定要开持久化的。

(3)tcp-backlog和maxclient,这两个参数可能大家也比较迷糊，maxclient

模式10000,一般情况下是够了，但是在高并发海量访问的时候，还是会出现客

户端缓慢的情况，那就是系统的限制，就是backlog参数，你可以理解为在三次

握手时进入acceptqueue队列的最大值，也就是send_Q,所以这个值设大点是没

有坏处的，我们的设置是1024

(4)重点提一下安全的参数，requirepassfoobared个人认为，如果你们觉得

你们hold住，那就不用开，如果在DMZ区，数据又比较重要，那就开。个人认

为，密码的作用不是你想象中的带给你安全，第一rcdis一分钟可以访问你想象

不到的次数，如果弱密码，分分钟破解，第二auth命令是明文的，破解也很容

易。

(5)maxmemory,这个参数比较常见，但是也非常的坑。如果你选择用，

有个原则，你是当数据库用还是当缓存用，如果当数据库用，就不要开，如果当

缓存用，可以开。曾经有个BUG,多个salve的情况下，会导致擦除主节点的数

据。如果你开启这个参数，记得预留一些空间给系统的buffer。

遵循你的使用场景和你对参数的了解。宁愿逐步踩坑逐步解决问题逐步深入

了解，也不要盲从的调整参数。

三、Redis的监控指标

内存使用。如果Redis使用的内存超出了可用的物理内存大小，那么Redis

很可能系统会被杀掉。针对这一点，你可以通过info命令对used_memory和

used_memory_peak进行监控，为使用内存量设定阀值，并设定相应的报警机制。

当然，报警只是手段，重要的是你得预先计划好，当内存使用量过大后，你应该

做些什么，是清除一些没用的冷数据，还是把Rcdis迁移到更强大的机器上去。

持久化。如果因为你的机器或Redis本身的问题导致Redis崩溃了，那么你

唯一的救命稻草可能就是dump出来的rdb文件了，所以，对Rcdisdump文件进

行监控也是很重要的。可以通过对rdb_last_save_time进行监控，了解最近一次

dump数据操作的时间，还可以通过对rdb_changes_since」asl_save进行监控来获

得如果这时候出现故障，会丢失(即已改屋)多少数据。

Keyso通过获取Keyspace中的结果得到各个数据库中key的数量

QPSo即每分钟执行的命令个数，即：

(total_commands_processed2-total_commands_processed1)/span,为了实时得

到QPS,可以他定脚本在后台运行，记录过去几分钟的

total_commands_processedo在计算QPS时，利用过去的信息和当前的信息得出

QPS的估计值。

四、如何更好更合理的使用Redis------1（）个具体应用难点解读

l.Redis与Oracle中存有同一份数据，当数据发生变化时，应用程序是先写

Redis然后再同步到Oracle,还是先写Oracle然后再同步到Redis呢，使用何种

同步机制可以有效的解决这个时间差中两份数据的不一致性呢？

答：如果你是当数据库用，那就类似于电商抢购场景。抢购的场景中有个需

要解决的问题是超买和超卖，意思就是说，我要控制库存数量，而且要保证可用

库存的数量为0,不能出现负数。一般是把数据从Oracle刷到Redis,贴合题主

的问题，那就是同样有一份数据，当数据变化的时候，是先写Redis还是先写

Oracle?是先写Redis,再写Oracle,因为代码层面保证数据的一致性，在高并发

情况下，悲观锁机制并不会很友好，而且影响性能。而redis天然的原子性事务,

是可以保证数据的一致性。

如果你当缓存用，又要确保数据的强一致性，是可以先写Redis,也可以先

写Oracle,如果先写Redis,参考前一段话，采取Redis的强一致性；如果先写

Oracle,那就采取悲观锁来实现。

2.目前的监控系统是Python至Oracle取配置信息，经过运算之后再写回

Oracle,然后根据阀值来触发告警，在这样的模式之下Redis是否有可以应用的

空间呢？

答：当你的监控的需求具备秒级监控的能力后，你的wcb-db的架构就不再

满足了

比如说以下场景

1：基于日志的流式计算

2：监控指标的基线

3：数据的统计分析

4：通用的计算周期

5：多维度的告警规则：如无数据告警、基于同环比的告警、基于基线的告

警、越来越多的监控场景、监控指标、触发器，「cdis的作用就是提供你更快、

更优质的服务

3.我们的系统现在使用了两套Rcdis；分别用作热点数据缓存、会话保持保

存全局ID。热点数据缓存采用的是一主一从三哨兵（分别独立，共五个节点）；

会话保持采用的是一主三从四个哨兵（共四个节点，每个节点上启动了一个哨兵

进程）；这个是乙方给的方案，请教大神，这个方案可靠吗？能否使用cluster方

案来替代呢？有必要吗？

答：你有两套Redis,A作为热数据缓存，B作为回话保持。

缺点：A有5个节点，B有4个节点，9个节点中只有2个节点是主节点，

提供服务，备节点只是冗余，存在比较大的资源浪费。

优点：sentinel集群，客户端可以随意地连接任意一个sentinel来获得关于

redis集群中的信息，做到代理层的可用性。切换至clusler后在资源使用率方面,

按照9节点的规模，实际组网只能有8台，4主4从，资源使用率得到很大的提

升，而且代理层分别由8个节点负担，因此，也能保证了可用性。

4.主机房部署了Redis集群，并数据持久化。问题：要求在主机房发生灾难

并不可修复的情况下，容灾机房能在一定时间内承担起主机房的业务能力。如何

保隙容灾机房的Redis集群数据跟主机房一致？如何操作？

答：主要看你采用集群的方式，如果是cluster,请参考，关于双活机房中

cluster模式的组网，根据你的业务场景来决定。如果redis的使用中并不处在核

心链路上，完全当做cache来使用，且在击穿情况下有后续的数据库来支撑，可

以放在同一机房内。如果Redis的使用在核心链路上，当做数据库来使用，在单

侧机房部署，不能保证多机房环境下的多活。以双活机房为例，集群有A、a、B、

b、C、c节点，A、B、C三个节点部署在甲机房，a、b、c