Redis知识点

Redis知识点

1.什么是NoSQL？

（1）Not Only Sql，指非关系型数据库。

2.什么是关系型数据库？什么是非关系型数据库？

（1）关系型：采用关系模型来组织数据的数据库
（2）非关系型：存储和管理非结构化数据的数据库

3.什么是Redis？

（1）NoSQL的一种，本质上是一个Key-Value的内存数据库，纯内存操作的数据库。

4.Redis主要特性是什么？

（1）速度快：标准C编写，数据存储于内存，所以速度非常快。
（2）数据结构：目前支持五种数据结构，分别是string【字符串】、hash【哈希】、set【集合】、list【列表】、sort set【有序集合】
（3）持久化：所有数据保存于内存中，redis有策略将内存数据持久化到磁盘中【memcache不支持持久化，mongodb部分在内存】
（4）线程安全：redis是单线程程序，所以它是线程安全的
（5）支持多种语言
（6）主-从复制：redis支持主-从复制
（7）支持集群

5.Redis的数据类型有哪些？

（1）string：字符串，二进制安全的，即redis的string可以包含任何数据，最大可以存储512M
（2）hash：哈希，一个string类型的key-value映射表，适合存储对象
（3）set：集合，无序不允许重复集合，通过哈希表实现，所以添加、删除、查找时间复杂度都是O(1)
（4）list：列表，有序的简单的字符串列表，由双向链表实现
（5）sot set：有序集合，有序不允许重复集合，每个类型会关联一个double类型分数，redis通过分数来为集合中元素进行大小排序

6.Redis比Memcache有哪些优势？

（1）memcache只有string类型，redis支持多种类型
（2）Redis 使用单核，而 Memcached 可以使用多核，所以平均每一个核上 Redis 在存储小数据时比 Memcached 性能更高。而在 100k 以上的数据中，Memcached 性能要高于 Redis。虽然 Redis 最近也在存储大数据的性能上进行优化，但是比起 Memcached，还是稍有逊色。
（3）redis支持持久化
（4）redis支持集群

7.Redis常用场景有哪些？

（1）简单缓存：存储变更频率低的数据
（2）分布式自增ID：由于操作是线程安全的，可以做分布式自增id，缺陷是当达到Redis的最大可用值时（默认为2^31-1），会返回错误
（3）队列：redis的list可以做到队列【先入先出】的特性
（4）排行榜：sort set是有序集合，元素不会重复，可以按照score取出对应范围的数据，所以可以做排行榜
（5）发布-订阅：redis支持发布-订阅操作

8.Redis为什么需要淘汰策略？

（1）redis的数据是存储在内存中，然而内存是有限的，所以有淘汰策略

9.Redis的淘汰策略使用的算法有哪些？

（1）lru：最近很少使用的key【根据时间，最不常用淘汰】
（2）lfu：最近很少使用的key【根据计数器，用的次数最少的key淘汰】
（3）random：随机淘汰
（4）ttl：快要过期的淘汰

10.Redis的淘汰策略针对key的算法有哪些？

（1）volatile：有过期时间的key
（2）allkeys：所有的key

11.Redis的淘汰策略有哪些？

（1）volatile-lru：针对设置过期时间的key，使用lru算法淘汰
（2）allkeys-lru：针对所有key，使用lru算法淘汰
（3）volatile-lfu：针对设置过期时间的key，使用lru算法淘汰
（4）allkeys-lfu：针对所有key，使用lfu算法淘汰
（5）volatile-random：针对设置过期时间的key，使用random算法淘汰
（6）allkeys-random：针对所有key，使用random算法淘汰
（7）volatile-ttl：针对设置过期时间的key，使用ttl算法淘汰
（8）noeviction：默认的，不删除键，值返回错误

12.一个字符串类型能存储多大的值？

（1）最大支持值的大小是512M，另外键（Key）的最大长度也是512MB

13.MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据？

（1）redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略

14.Redis哈希槽？

（1）edis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽

15.Redis集群会有写操作丢失吗？

（1）Redis并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

16. Redis集群节点之间是如何复制的？

（1）节点之间是采用的异步复制（asynchronous replication），因此Redis集群是无法保证数据的强一致性的。

17.Redis集群的主从复制模型是怎样的？

（1）为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品；最多支持16384个节点数

18.怎么理解Redis事务？

（1）事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
（2）事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
（3）redis事务相关命令：MULTI、EXEC、DISCARD、WATCH
（4）WATCH是基于特定事物使用，对key添加锁，当key发生变化，终止事务

19.Redis key的过期时间和永久有效分别怎么设置？

（1）EXPIRE和PERSIST命令。

20.为什么要做Redis分区？

（1）分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存
（2）如果没有分区，你最多只能使用一台机器的内存
（3）分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。

21.有哪些Redis分区实现方案？

（1）客户端分区：客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取
（2）代理分区：客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据
（3）查询路由：客户端随机地请求任意一个redis实例，然后由Redis将请求转发给正确的Redis节点，Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个redis节点转发到另一个redis节点，而是在客户端的帮助下直接redirected到正确的redis节点。

22.Redis分区有什么缺点？

（1）涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）。

23.Redis持久化数据和缓存怎么做扩容？

（1）Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。
（2）Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。

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

（1）info

25.Redis的内存用完了会发生什么？

（1）如果达到设置的上限，Redis的写命令会返回错误信息（但是读命令还可以正常返回。）或者你可以将Redis当缓存来使用配置淘汰机制，当Redis达到内存上限时会冲刷掉旧的内容。

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

（1）可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用
（2）如果你想使用多个CPU，你可以考虑一下分片（shard）

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

（1）Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件
（2）如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
（3）为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
（4）尽量避免在压力很大的主库上增加从库
（5）主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…；这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

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

（1）AOF：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
（2）RDB：在指定的时间间隔能对你的数据进行快照存储
（3）可以同时开启两种持久化方式，在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整

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

（1）如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化
（2）定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快

30.触发RDB快照

（1）在指定的时间间隔内，执行指定次数的写操作
（2）执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令
（3） 执行flushall 命令，清空数据库所有数据，意义不大。
（4）执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义…也不大。

31.通过RDB文件恢复数据

（1）将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb

32.RDB 的优缺点

优点：
（1）RDB是一个紧凑的二进制文件，存储效率高，恢复速度也比AOF高
（2）适合大规模的数据恢复。
（1）如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：
（1）数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了，即无法实时持久化。
（2）备份时占用内存，因为Redis 在备份时会独立创建一个子进程（bsave会fork一个子进程），将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
（3）版本不一致的时候，RDB文件不一定可以进行恢复

总结：
（1）Redis 的持久化和数据的恢复要选择在活跃程度低的情况下进行

33.Redis的RDB持久化方式比较

34.AOF写数据的三种策略

（1）每次：每次写入操作都写到日志中，性能较低
（2）每秒：每秒将缓冲区中的内容写到aof文件中，性能较高
（3）系统控制：由操作系统控制写到aof文件中，整体不可控

35.AOF重写

（1）随着命令不断写入aof文件中，文件会越来越大，redis引入aof重写机制压缩文件体积，主要三个作用：降低磁盘使用率、提高持久化效率、提高恢复效率

36.RDB和AOF比较

37.修改配置不重启Redis会实时生效吗？

（1）针对运行实例，有许多配置选项可以通过 CONFIG SET命令进行修改，而无需执行任何形式的重启。

38.Redis数据删除策略

（1）定时删除：创建定时器，扫描过期的key进行删除
（2）定期删除：周期性抽查进行删除
（3）惰性删除：key过期不处理，下次访问时发现过期则进行删除
三种方式对比：

39.Redis集群

（1）主从模式
（2）哨兵模式
（3）集群

40.多台服务器连接方案

41.主从模式

42.高可用集群

（1）主从（master slave）是相对的概念
（2）当master出现问题，可以临时让其中一台slave充当master
（3）当master压力大，可以让某一个slave追加下一级，这种树状拓扑结构也带来一定的问题

master可以有多个，但是需要利用哨兵解决问题

43.主从复制的作用

（1）读写分离：提高服务器读写能力
（2）负载均衡：主从分担负载压力
（3）故障恢复：master出现故障，slave可以提供服务
（4）数据冗余：实现数据热备
（5）高可用基石：基于主从复制，构建哨兵和集群，实现redis高可用集群方案

44.哨兵模式

（1）哨兵是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master

45.哨兵的作用

（1）监控：不断的检查master和slave是否正常运行
（2）通知：当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
（3）自动故障转移：断开master和slave连接，选取一个slave连接到新的master，并告知客户端新的服务器地址

注意：
（1）哨兵也是一台redis服务器，知识不提供数据服务
（2）通常哨兵配置数量为单数

46.企业级解决方案

（1）缓存预热：缓存预热是系统启动前，提前将相关的缓存数据直接加载到缓存系统。避免用户请求的时候，先查询数据库。
（2）缓存雪崩：大量key同时失效，导致对数据库服务器造成压力【较短时间内，缓存中较多的key集中过期】。如能够有效避免过期时间集中供暖，可以有效解决雪崩现象的出现，配合其他策略一起使用，并监控服务器的运行数据，根据运行记录做快速调整。

解决方案：
（1）lru和lfu切换
（2）数据有效期策略调整，根据业务将数据有效期错峰设置
（3）超热数据设置永久
（4）定期维护
（5）加锁【慎用】

（3）缓存击穿：单个key过期，数据访问量较大，未命中redis，发起大量对同一个数据的数据库访问，导致对数据库服务器造成压力。应对策略应该在业务数据分析与预防方面进行，配合运行监控测试与即时调整策略，毕竟单个key的过期监控难度较高，配合雪崩处理策略即可。
（4）缓存穿透：访问了不存在缓存没有和数据库都没有的数据，每次都访问到数据库，导致对数据库服务器造成压力。

47.如何保证缓存(Redis)与数据库(MySQL)的一致性？

大概分成下面四种情况：
（1）先更新数据库，再更新缓存
（2）先更新缓存，再更新数据库
（3）先删除缓存，再更新数据库
（4）先更新数据库，再删除缓存

缓存删除对比缓存更新：
（1）删除缓存：数据只会写入数据库，不会写入缓存，只会删除缓存
（2）数据不但写入数据库，还会写入缓存

删除缓存：
（1）优点：操作简单，无论更新操作是否复杂，直接删除，并且能防止更新出现的线程安全问题
（2）缺点：删除后，下一次查询无法在 cache 中查到，会有一次 Cache Miss，这时需要重新读取数据库，高并发下可能会出现上面说的缓存问题

更新缓存：
（1）优点：命中率高，直接更新缓存，不会有 Cache Miss 的情况
（2）缺点：更新缓存消耗较大，尤其在复杂的操作流程中

总结：无法保证强一致性，保证最终一致性

48.Redis限流-滑动窗口限流

（1）指定时间T内，只允许发生N次。我们可以将这个指定时间T，看成一个滑动时间窗口（定宽）。
（2）采用Redis的zset基本数据类型的score来圈出这个滑动时间窗口。在实际操作zset的过程中，我们只需要保留在这个滑动时间窗口以内的数据，其他的数据不处理即可。

原理：
（1）每个用户的行为采用一个zset存储，score为毫秒时间戳，value也使用毫秒时间戳（比UUID更加节省内存）
（2）只保留滑动窗口时间内的行为记录，如果zset为空，则移除zset，不再占用内存（节省内存）
（3）每次只是处理固定score范围内的请求

49.Redis事务、Pipeline、Lua脚本

（1）事务：无原子性，当指令发生错误直接跳过，并且下一个指令无法获取上一个指令执行结果，无法回滚
（2）Pipeline：只有一次网络开销执行多个命令，而redis事务是N次网络开销执行N次命令。pipeline不具备原子性。
（3）Lua脚本：可以实现原子性

mset和mget是原子性的，pipeline是非原子性的。

后续会陆续补充进来…