概述

redis 是内存中的数据结构存储系统，一个 key-value 类型的非关系型数据库，可持久化的数据库，相对于关系型数据库（数据主要存在硬盘中），性能高，因此我们一般用 redis 来做缓存使用；并且 redis 支持丰富的数据类型，比较容易解决各种问题，因此 redis 可以用来作为注册中心， 数据库、缓存和消息中间件。Redis 的 Value 支持 5 种数据类型，string、hash、list、set、zset（sorted set）;

1）String 类型：一个 key 对应一个 value

2）Hash 类型：它的 key 是 string 类型，value 又是一个 map（key-value），适合存储对象。

3）List 类型：按照插入顺序的字符串链表（双向链表），主要命令是 LPUSH 和 RPUSH，能够支持反向查找和遍历

4）Set 类型：用哈希表类型的字符串序列，没有顺序，集合成员是唯一的，没有重复数据，底层主要是由一个 value 永远为 null 的 hashmap 来实现的。

5）zset 类型：和 set 类型基本一致，不过它会给每个元素关联一个 double 类型的分数（score），这样就可以为成员排序，并且插入是有序的。

你还用过其他的缓存吗？这些缓存有什么区别？都在什么场景下去用？

对于缓存了解过 redis 和 memcache

Memcache 和 redis 的区别：

数据支持的类型：redis 不仅仅支持简单的 k/v 类型的数据，同时还支持 list、set、zset、hash等数据结构的存储；memcache 只支持简单的 k/v 类型的数据，key 和 value 都是 string 类型

可靠性：memcache 不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的；

redis 支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能的代价

性能上：对于存储大数据，memcache 的性能要高于 redis

应用场景

Memcache：适合多读少写，大数据量的情况（一些官网的文章信息等）

Redis：适用于对读写效率要求高、数据处理业务复杂、安全性要求较高的系统

案例：分布式系统，存在 session 之间的共享问题，因此在做单点登录的时候，我们利用 redis来模拟了 session 的共享，来存储用户的信息，实现不同系统的 session 共享；

对 redis 的持久化了解不？

redis 的持久化方式有两种：

RDB（半持久化方式）：

按照配置不定期地通过异步的方式、快照的形式直接把内存中的数

据持久化到磁盘的一个 dump.rdb 文件（二进制的临时文件）中，redis 默认的持久化方式，

它在配置文件（redis.conf）中。

优点：只包含一个文件，将一个单独的文件转移到其他存储媒介上，对于文件备份、灾难恢

复而言，比较实用。

缺点：系统一旦在持久化策略之前出现宕机现象，此前没有来得及持久化的数据将会产生丢

失

RDB 持久化配置：

Redis 会将数据集的快照 dump 到 dump.rdb 文件中。此外，我们也可以通过配置文件来修改Redis 服务器 dump 快照的频率，在打开 6379.conf 文件之后，我们搜索 save，可以看到下面的配置信息：

save 900 1 #在 900 秒(15 分钟)之后，如果至少有 1 个 key 发生变化，则 dump 内存快照。

save 300 10 #在 300 秒(5 分钟)之后，如果至少有 10 个 key 发生变化，则 dump 内存快照。

save 60 10000 #在 60 秒(1 分钟)之后，如果至少有 10000 个 key 发生变化，则 dump 内存快照。

AOF（全持久化的方式）：

把每一次数据变化都通过 write()函数将你所执行的命令追加到一个 appendonly.aof 文件里面，Redis 默认是不支持这种全持久化方式的，需要在配置文件（redis.conf）中将 appendonlyno 改成 appendonly yes

优点：数据安全性高，对日志文件的写入操作采用的是 append 模式，因此在写入过程中即

使出现宕机问题，也不会破坏日志文件中已经存在的内容；

缺点：对于数量相同的数据集来说，aof 文件通常要比 rdb 文件大，因此 rdb 在恢复大数据集时的速度大于 AOF；

AOF 持久化配置:

在 Redis 的配置文件中存在三种同步方式，它们分别是：

1）appendfsync always #每次有数据修改发生时都会都调用 fsync 刷新到 aof 文件，非常慢，

但是安全；

2）appendfsync everysec #每秒钟都调用 fsync 刷新到 aof 文件中，很快，但是可能丢失一秒内的数据，推荐使用，兼顾了速度和安全；

3）appendfsync no #不会自动同步到磁盘上，需要依靠 OS（操作系统）进行刷新，

效率快，但是安全性就比较差；

二种持久化方式区别：

AOF 在运行效率上往往慢于 RDB，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB 一样高效；

如果缓存数据安全性要求比较高的话，用 aof 这种持久化方式（比如项目中的购物车）；

如果对于大数据集要求效率高的话，就可以使用默认的。而且这两种持久化方式可以同时使

用。

做过 redis 的集群吗？你们做集群的时候搭建了几台，都是怎么搭建的？

Redis 的数据是存放在内存中的，不适合存储大数据，大数据存储一般公司常用 hadoop 中的Hbase 或者 MogoDB。redis 主要用来处理高并发的，用我们的项目来说，电商项目如果并发大的话，一台单独的 redis 是不能足够支持我们的并发，这就需要我们扩展多台设备协同合作，即用到集群。

Redis 搭建集群的方式有多种，例如：客户端分片、Twemproxy、Codis 等，但是 redis3.0 之后就支持 redis-cluster 集群，这种方式采用的是无中心结构，每个节点保存数据和整个集群的状态，每个节点都和其他所有节点连接。如果使用的话就用 redis-cluster 集群。集群这块是公司运维搭建的，具体怎么搭建不是太了解。

我们项目中 redis 集群主要搭建了 6 台，3 主（为了保证 redis 的投票机制）3 从（高可用），每个主服务器都有一个从服务器，作为备份机。所有的节点都通过 PING-PONG 机制彼此互相连接；客户端与 redis 集群连接，只需要连接集群中的任何一个节点即可；Redis-cluster中内置了 16384 个哈希槽，Redis-cluster 把所有的物理节点映射到【0-16383】slot 上，负责维护。

redis 有事务吗？

Redis 是有事务的，redis 中的事务是一组命令的集合，这组命令要么都执行，要么都不执行，保证一个事务中的命令依次执行而不被其他命令插入。redis 的事务是不支持回滚操作的。redis 事务的实现，需要用到 MULTI（事务的开始）和 EXEC（事务的结束）命令 ;

缓存穿透

缓存查询一般都是通过 key 去查找 value，如果不存在对应的 value，就要去数据库中查找。如果这个 key 对应的 value 在数据库中也不存在，并且对该 key 并发请求很大，就会对数据库产生很大的压力，这就叫缓存穿透

解决方案：

1. 对所有可能查询的参数以 hash 形式存储，在控制层先进行校验，不符合则丢弃。

2.将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个

bitmap 拦截掉，从而避免了对底层存储系统的查询压力。

3. 如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个

空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存雪崩

当缓存服务器重启或者大量缓存集中在一段时间内失效，发生大量的缓存穿透，这样在失效

的瞬间对数据库的访问压力就比较大，所有的查询都落在数据库上，造成了缓存雪崩。 这

个没有完美解决办法，但可以分析用户行为，尽量让失效时间点均匀分布。大多数系统设计

者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请

求落到底层存储系统上。

解决方案：

1.在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只

允许一个线程查询数据和写缓存，其他线程等待。

1. 可以通过缓存 reload 机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存
2. 不同的 key，设置不同的过期时间，让缓存失效的时间点尽量均匀

4.做二级缓存，或者双缓存策略。A1 为原始缓存，A2 为拷贝缓存，A1 失效时，可以访问

A2，A1 缓存失效时间设置为短期，A2 设置为长期。

redis 的安全机制（你们公司 redis 的安全这方面怎么考虑的？）

漏洞介绍：redis 默认情况下，会绑定在 bind 0.0.0.0:6379，这样就会将 redis 的服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在访问目标服务器的情况下，未授权就可访问 redis 以及读取 redis 的数据，攻击者就可以在未授权访问 redis 的情况下可以利用 redis 的相关方法，成功在 redis 服务器上写入公钥，进而可以直接使用私钥进行直接登录目标主机；

解决方案：

1. 禁止一些高危命令。修改 redis.conf 文件，用来禁止远程修改 DB 文件地址，比如

rename-command FLUSHALL "" 、rename-command CONFIG"" 、rename-command EVAL “”等；

2. 以低权限运行 redis 服务。为 redis 服务创建单独的用户和根目录，并且配置禁止登录；

3.为 redis 添加密码验证。修改 redis.conf 文件，添加 requirepass mypassword；

4. 禁止外网访问 redis。修改 redis.conf 文件，添加或修改 bind 127.0.0.1，使得 redis 服务只在当前主机使用；

5.做 log 监控，及时发现攻击；

6.redis 的哨兵机制（redis2.6 以后出现的）

哨兵机制：

监控：监控主数据库和从数据库是否正常运行；

提醒：当被监控的某个 redis 出现问题的时候，哨兵可以通过 API 向管理员或者其他应用程序发送通知；

自动故障迁移：主数据库出现故障时，可以自动将从数据库转化为主数据库，实现自动切换；

具体的配置步骤参考的网上的文档。要注意的是，如果 master 主服务器设置了密码，记得

在哨兵的配置文件（sentinel.conf）里面配置访问密码

redis 中对于生存时间的应用

Redis 中可以使用 expire 命令设置一个键的生存时间，到时间后 redis 会自动删除；

应用场景：

1. 设置限制的优惠活动的信息；
2. 一些及时需要更新的数据，积分排行榜；
3. 手机验证码的时间；

4. 限制网站访客访问频率；