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

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

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

30个Redis基础知识

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

String、List、Set、SortedSet>hashes

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

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

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

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

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

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

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

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

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

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

过期集合的键。

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

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

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

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

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

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

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

值后不能继续插入新值。

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

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

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

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

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

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

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

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

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

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

3.rediscluster3.0自带的集群，特点在于他的分布式算法不是一致性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集群会有写操作丢失吗？为什么？

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

可能会丢失写操作。

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

异步复制

12、怎么理解Redis事务？

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

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

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

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

MULTLEXEC、DISCARD.WATCH

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

EXPIRE和PERSIST命令。

15、Redis如何做内存优化？

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

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

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

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

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

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

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

略进行回收。

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

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

到边界以下。

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

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

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

LRU算法

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

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

大量数据插入工作。

19、为什么要做Redis分区？

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

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

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

而成倍增长。

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

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

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

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

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

集群可以做到这样。

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

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

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

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

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

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

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

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

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

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

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

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

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

一起。

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

Info

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

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

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

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

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

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

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

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

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

能存放多少元素？

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

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

任何list、set、和sortedset都可以放232个元素。

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

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

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

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

步一次

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

域网内

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

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

Slavel<-Slave2<-Slave3..

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

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

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

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

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

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

到文件末尾。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、常见的Redis集群方案有哪些优缺点？

Twemproxy:

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

算法，转发给对应的RediSo

优点：

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

历史悠久，方案成熟

缺点：

代理影响性能

LVS和Twemproxy会有节点性能瓶颈

Redis扩容非常麻烦

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

Codis:

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

分发Codis-Config的命令

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

Codis-Proxy

无状态代理，兼容Redis协议

对业务透明

Codis-Redis

基于2.8版本，二次开发

加入slot支持和迁移命令

优点：

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

性能比Twemproxy好

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

缺点：

代理依旧影响性能

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

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

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

RedisCluster:

RedisSlave

-----RedisGossipProtocol

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

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

同步节点信息。

优点：

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

性能比proxy模式好

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

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

缺点：

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

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

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

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

二、Redis通用

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

观点一：

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

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

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

观点二：

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

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

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

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

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

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

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

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

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

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

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

观点三：

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

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

2,Redis有哪些应用场景？

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

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

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

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

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

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

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

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

这是笔者的建议：

通读Sentinel官方文档

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

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

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

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

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

三、Redis故障排查

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

客户端TCP状态迁移：

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

ME_WAIT->CLOSED

服务器TCP状态迁移：

CLOSED->LISTEN->SYN

收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

这个状态存在于主动发起断开请杀的一端，如臬服务器存在大量的这个状

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

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

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

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

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

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

看latency的延迟，blocked_clients的数量，rejected_connections的数量等。

解答二：

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

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

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

回答一：常见的运维故障

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

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

即可

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

化

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

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

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

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

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

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

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

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

分析此条失效）

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

获得）

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

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

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

四、Redis性能优化

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

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

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

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

使用前缀管理好key

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

做

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

配置使用ziplist来优化list

合理配置maxmemory

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

利用管道，批量处理命令

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

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

（以上内容由温国兵、liucj2004,赵海等社区专家和会员分享，温国兵整理

汇编。）

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

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

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

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

合小数据高速读写访问。

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

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

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

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

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

盘存储并更新缓存

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

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

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

二、Redis的调优参数

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

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

（1）timeout参数，非常需要关注，官方对timeout的解释如下：该参数表

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

容易。

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

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

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

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

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

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

三、Redis的监控指标

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

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

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

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

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

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

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

件进行监控也是很重要的。可以通过对rdb」ast_save_time进行监控，了解最近

一次dump数据操作的时间，还可以通过对rdb_changes_since_last_save进行监

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

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

QPSo

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

即：(total_commands_processed2-total_commands_processed1)/span,为了实

时得到QPS,可以板定脚本在看台运行，记录过去几分钟的

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

QPS的估计值。

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

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是否有可以应用的

空间呢？

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

满足了

比如说以下场景

1：基于日志的流式计算

2：监控指标的基线

3：数据的统计分析

4：通用的计算周期

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

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

更优质的服务

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

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

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

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

案来替代呢？有必要吗？

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

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

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

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

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

按照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三个节点部署在乙机

房，甲乙两个机房使用波分线路进行大二层透传，能够使某一业务同时在某一都

使用同一网段地址。基于Redis本身，能够实现双数据副本模式，当甲机房单侧

异常时，乙机房单侧接管，重新完成组网，提供服务。

如果是其他集群，请描述，我再补充。我大概明白你的意思了，我猜测1：

你应该没有使用集群模式，而且采取了无状态的三个节点，进行组网。2：你采

取的cluster,三主三从都是部署在单侧机房。目前你的做法是AB两个机房，你

集群部署在A单侧机房，另外在B机房又复制了A机房的集群镜像，当单侧机

房故障时，B机的Redis进行启动进行加载数据提供服务。目前我有个问题，你

们有没有演练过？且应用要不要改Redis的IP?如果你们对Redis的场景没有横

向扩展的要求，建议在Redis集群上加一层代理，比如sentinel、twemproxy通过

代理去路由Redis,同时Redis的主备分别部署两侧机房，当主节点异常，备节

点进行选举接管。

5.多个系统共用Redis集群，如何防止某个系统独占大量资源，导致其他系

统不可用？

答：多个系统共用一套redis的前提，那就是不能对其他业务有影响。

1：key-value的命名规范

2：定义使用场景

3：完善的监控

4：定期巡检慢查询日志

6.Redis生产部署中集群方案是否有简化部署？

目前，在实际生产部署中，已经在使用Redis主备方案的部署，但还仅是依

靠硬件负载均衡设备进行应用分发后，由2台Redis服务器实现主备。基于Redis

在系统仅是做为数据写入缓存的单一功能。想了解一下除了Redis多机集群，是

否有简单的Redis双机部署方案，性能如何？（2台物理机，我们是电力行业系

统，用于将通信端抄送上来的并发数20万左右的报文缓存，然后存于数据库！）

答：20万的数据量不大，可以采用Redis主从方式，搭配sentinel进行自动

主从切换。如果团队开发能力较强，可以研究一下twemproxy开源架构。另外，

Redis是单线程模式运行的，为了充分使用机器的CPU资源，可以搭建多个Redis

实例，部署多套主从架构，或者使用twemproxy开源架构对数据进行分片，适应

将来的业务量上涨。

7.Rediscluster在多活机房中采取怎样的架构？

答：关于双活机房中cluster模式的组网，根据你的业务场景来决定。

如果Redis的使用中并不处在核心链路上，完全当做cache来使用，且在击

穿情况下有后续的数据库来支撑，可以放在同一机房内。如果Redis的使用在核

心链路上，当做数据库来使用，在单侧机房部署，不能保证多机房环境下的多活。

以双活机房为例，集群有A、a、B、b、C、c节点，A、B、C三个节点部署在

甲机房，a、b、c三个节点部署在乙机房，甲乙两个机房使用波分线路进行大二

层透传，能够使某一业务同时在某一都使用同一网段地址。基于Redis本身，能

够实现双数据副本模式，当甲机房单侧异常时，乙机房单侧接管，重新完成组网，

提供服务。

8.RedisCluster什么情况下会导致数据丢失，应该怎么避免？

答：cluster模式下数据丢失，有两种可能1：请求击穿，写入失败，这个要

从代码层面来解决；2：主从切换，从节点的数据跟主节点数据有差异。这个解

决方式可以采取配置always参数，保持数据的大概率的一致性。

9.Redis主从间是异步复制，这里提到强一致是如何做到的？应用层的工作

吗？

答：不得不说，Redis的数据同步，强一致性是有前置条件的，强一致性的

根据有两个前提，1：持久化文件的生成的一致性；2：持久化文件的写入的一致

性。针对1,目前有两种持久化方式，RDB和AOF,针对两者而言，其实都是

异步的，两个都有优缺点，但针对落地数据而言，都是异步的，所以能做到准实

时，不能做到真正意义上的实时。

很多人有疑问了，appendfsyncalways这个参数明明是同步的，是能牺牲性

能保证数据的一致性的。仔细看官网的介绍，AOF持久化中的文件写入操作其

实是将aof_buf缓冲区的内容存放到了内存缓冲区中，这时还没有真正写入到磁

盘中，这个缓冲区达到同步条件时，才会执行fsync将这个缓冲区的内容写入到

硬盘中，完成文件同步。所以持久化和REDIS事务的原子性是解耦的。针对2,

取决于持久化文件的大小，曾遇到一种情况，当持久化文件非常大的时候，同步

也是需要时间的。综上所述，不能做到绝对的强一致性，只能做到可接受的范围

的强一致性。

10.在金融行业，为了保证数据的强一致性，应该选择哪种持久化方式？换

句话说，在主从切换中，通过哪些途径保持数据的强一致性？

答：持久化并且要保证数据不丢失：可以开启aof备份，并且把appendfsync

参数设置为always,保证收到写命令后就立即写入磁盘，但是效率最差，一般

的sata盘只能支持几百的QPS。可以使用高效的SSD磁盘提升性能。但是这也

违背了redis高速缓存的初衷。主从切换：目前原生redis不支持同步复制，它的

主从只能是异步复制，也就是无法保证数据强一致性。有些公司通过修改复制内

核支持主从完全同步的复制。这也牺牲了性能和QPSoredis出现的目的是为了

作为缓存提升访问性能，对数据一致性的支持相对比较弱。

Redis基础知识总

从关系型数据库到非关系型数据库的发展

关系型数据库

自1970年，埃德加・科德提出关系模型之后，关系数据库便开始出现，经过

了40多年的演化，如今的关系型数据库具备了强大的存储、维护、查询数据的

能力。但在关系数据库日益强大的时候，人们发现，在这个信息爆炸的“大数据”

时代，关系型数据库遇到了性能方面的瓶颈，面对一个表中上亿条的数据，SQL

语句在大数据的查询方面效率欠佳。我们应该知道，往往添加了越多的约束的技

术，在一定程度上定会拖延其效率。

非关系型数据库

在1998年，CarloStrozzi提出NOSQL的概念，指的是他开发的一个没有

SQL功能，轻量级的，开源的关系型数据库。注意，这个定义跟我们现在对NoSQL

的定义有很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但

是NoSQL的发展慢慢偏离了初衷，CarloStrozzi也发觉，其实我们要的不是

"nosql",而应该是"norelational"，也就是我们现在常说的非关系型数据库了。

NoSQL的简介

NoSQL的概念

非关系型数据库提出另一种理念，他以键值对存储，且结构不固定，每一个

元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样

就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用

户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需

要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value

就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供想SQL

所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。

他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数

据库显得更为合适。

目前出现的NoSQL（NotonlySQL,非关系型数据库）有不下于25种，除了

Dynamo>Bigtable以外还有很多，比如Amazon的SimpleDB、微软公司的

AzureTable、Facebook使用的Cassandra、类Bigtable的Hypertable、Hadoop的

HBase>MongoDB>CouchDB.Redis以及Yahoo!的PNUTS等等。这些NoSQL

各有特色，是基于不同应用场景而开发的，而其中以MongoDB和Redis最为被

大家追捧。

NoSQL数据库的分类

1键值（key-value）

2、列存储数据库

3、文档型数据库

4、图形（Graph）数据库

关系型数据库的瓶颈

］、高并发读写需求

网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型

数据库来说，硬盘I/O是一个很大的瓶颈

2、海量数据的高效率读写

网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量

数据的表中查询，效率是非常低的

3、高扩展性和可用性

在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统

的用户量和访问量与日俱增的时候，数据库却没有办法像webserver和即pserver

那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需

要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛

苦的事情，往往需要停机维护和数据迁移。

4、对网站来说，关系型数据库的很多特性不再需要了：

事务一致性

关系型数据库在对事物一致性的维护中有很大的开销，而现在很多web2.0

系统对事物的读写一致性都不高

读写实时性

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出这条数据

的，但是对于很多web应用来说，并不要求这么高的实时性，比如发一条消息

之后，过几秒乃至十几秒之后才看到这条动态是完全可以接受的

复杂SQL,特别是多表关联查询

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的

数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品

阶级角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单

表的简单条件分页查询，SQL的功能极大的弱化了

5、在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以

及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，

我们必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一个格

式化的数据结构。每个元组字段的组成都是一样，即使不是每个元组都需要所有

的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于标语表之

间进行链接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因

素。

关系型数据库瓶颈后对应的解决方案

1、Memcached+MySQL：

减轻数据的读取压力；

首次访问时：从RDBMS中取得数据保存到memcached中。

第二次访问时：直接从memcached中取得数据进行返回。

2、MySQL的主从读写分离

Memcached只能缓解读取压力，随着数据库的写入压力增加，读写集中在

一个数据库上让数据库不堪重负；

可以使用主从复制技术来实现读写分离，以提高读写性能和读库的可扩展

性。即Mysql的master-slave模式

3、分表分库

随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从

复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据

量的持续猛增，由于MylSAM使用表锁，在高并发下会出现严重的锁问题，大

量的高并发MySQL应用开始使用InnoDB引擎代替MylSAM。同时，开始流行

使用分表分库来缓解写压力和数据增长的扩展问题。

虽然MySQL推出了MySQLCluster集群，但是由于在互联网几乎没有成功

案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。

MySQL的扩展型瓶颈

1、在互联网，大部分的MySQL都应该是10密集型的，事实上，如果你的

MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需

要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具

有技术挑战性。

2、分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大

的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的

复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可

能又需要一种新的分库方式。

3、MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在

做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB

大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL

将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场

景。

4、MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表

结构更改困难，正是当前使用MySQL的开发人员面临的问题。

NoSQL的优势

1、易扩展

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系

型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上

带来了可扩展的能力。

2、大数据量、高性能

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优

秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用QueryCache,

每次表的更新Cache就失效，是一种大粒度的Cache,在针对web2.0的交互频

繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的

Cache,所以NoSQL在这个层面上来说就要性能高很多了。

3、灵活的数据类型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格

式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量

的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

4、高可用

NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如

Cassandra,HBase模型，通过复制模型也能实现高可用。

NoSQL的应用场景

1、数据模型比较简单；

2、需要灵活性更强的IT系统；

3、对数据库性能要求较高；

4、不需要高度的数据一致性；

5、对于给定key,比较容易映射复杂值的环境。

RedisUbuntu环境安装

卸载软件

sudoapt-getremoveredis-server

清除配置

sudoapt-getremove—purgeredis-server

删除残留文件

1、sudofind/-nameredis：文档查找名字

2、删除

sudorm-rfvar/lib/redis/

sudorm-rf/var/log/redis

sudorm-rf/etc/redis/

sudorm-rf/usr/bin/redis-*

下载新的文档安装包

下载地址：

安装步骤

1、下载安装包

2、解压

tar-zxvfredis-3.2.8.tar.gz

3、copy文件并Is查看

1、sudomkdir-p/usr/local/redis/

2、sudosudomv./redis-3.2.8/usr/local/redis/

3、Is/usr/local/redis/

4、进入安装目录

cd/usr/local/redis/

5、翻译

1、首先打开README.md,翻阅基本build和install方式：sudomake

2、尝试环境是否可以正常使用(Hint:It'sagoodideatorun'maketest';)：sudo

maketest

3、\o/Alltestspassedwithouterrors!：提示测试没有问题

6、生成

sudomake

7、测试,这段运行时间会较口

sudomaketest

9、安装第redis的命令安装至U/usr/local/bin/目录

sudomakeinstall

10、查看编译好的命令文件

Is/usr/local/bin/redis-*

11、修改配置文件

1、sudomkdir/etc/redis

2、sudocpredis.conf/etc/redis/

3、Is/etc/redis/redis.conf

安装后sudomaketest报错

python@ubuntu:/usr/local/redts$sudomaketest

cdsrc&&maketest

make[l]:进入目录”/us「八ocal/「edts/s「c”

CCMakeftle.dep

Youneedtel8.5ornewerinordertoruntheRedistest

Makefile:242:recipefortarget1test1failed

make[l]:***[test]Error1

make[l]:离开目录”/us「八ocal/「edts/s「c”

Makefile:6:recipefortarget1test1failed

make:***[test]Error2

安装tel8.5

sudotarxzvftcl8.6.1-src.tar.gz-C/usr/local/

cd/usr/local/tcl8.6.1/unix/

sudo./configure

sudomake

sudomakeinstall

Redis配置文件位置和简单操作

Redis的配置信息在/etc/redis/redis.conf下

查看

sudocat/etc/redis/redis.conf

修改

sudovim/etc/redis/redis.conf

Redis配置文件redis.conf核心配置说明：

#绑定ip：如果需要远程访问，可将此行注释，或绑定一个真实ip

bind

#端口，默认为6379

port6379

#是否以守护进程运行

#如果以守护进程运行，则不会在命令行阻塞，类似于服务

#如果以非守护进程运行，则当前终端被阻塞

#设置为yes表示守护进程，设置为no表示非守护进程

#推荐设置为yes

daemonizeyes

#数据文件

dbfilenamedump.rdb

#数据文件存储路径

dir/var/lib/redis

#曰志文件

logfile/var/log/redis/redis-server.log

#数据库，默认有16个

database16

#主从复制，类似于双机备份。

slaveof

启动redis：redis-server或redis-server/etc/redis/redis.conf

连接redis服务器：redis-cli

Redis可视化客户端工具

项目地址：

Redis数据持久化

位置：/var/lib/redis/dump.rdb

Redis的应用场景

1、取最新N个数据的操作

比如典型的取你网站的最新文章，我们可以将最新的5000条评论的ID放在

Redis的List集合中，并将超出集合部分从数据库获取。

2、排行榜应用，取TopN操作

这个需求与上面需求的不同之处在于，前面操作以时间为权重,这个是以某个

条件为权重，比如按顶的次数排序，这时候就需要我们的sortedset出马了，将你要

排序的值设置成sortedset的score,将具体的数据设置成相应的value,每次只需要

执行一条ZADD命令即可。

3、需要精确设定过期时间的应用

比如你可以把上面说到的sortedset的score值设置成过期时间的时间戳，那

么就可以简单地通过过期时间排序，定时清除过期数据了，不仅是清除Redis中的

过期数据,你完全可以把Redis里这个过期时间当成是对数据库中数据的索引，用

Redis来找出哪些数据需要过期删除，然后再精准地从数据库中删除相应的记录。

4、计数器应用

Redis的命令都是原子性的，你可以轻松地利用INCR,DECR命令来构建计数

器系统。

5、uniq操作，获取某段时间所有数据排重值

这个使用Redis的set数据结构最合适了，只需要不断地将数据往set中扔就

行了,set意为集合，所以会自动排重。

6、Pub/Sub构建实时消息系统

Redis的Pub/Sub系统可以构建实时的消息系统，比如很多用Pub/Sub构建的

实时聊天系统的例子。

7、构建队列系统

使用list可以构建队列系统，使用sortedset甚至可以构建有优先级的队列系

统。

8、缓存

最常用，性能优于Memcached（被libevent拖慢），数据结构更多样化。

Redis数据类型

String字符串

定义：String是redis最基本的类型，value不仅可以是String,也可以是数

字；使用Strings类型，可以完全实现目前Memcached的功能，并且效率更高。

还可以享受Redis的定时持久化（可以选择RDB模式或者AOF模式）；string

类型是二进制安全的。意思是redis的string可以包含任何数据，比如jpg图片或

者序列化的对象；strin