Redis 100问

什么是Redis？简述优缺点

• 一个Key-Value类型的内存数据库
  优点
• Redis的性能非常出色，每秒可以处理超过 10万次读写操作
• 支持保存多种数据结构 ， string，hash，list，set，zset
• 单个value的最大限 制是1GB，不像 memcached只能保存1MB的数据
• 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
  缺点
• 容量受到物理内存的限制

redis相比memcached有哪些优势？

• 支持数据类型：memcached所有的值均是简单的字符串，redis支持复杂数据类型
  -value大小：redis可达到1G，memcached只有1MB
  -存储方式： redis可以持久化数据，memcached只能在内存

Redis有哪几种数据淘汰策略

• voltile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
• volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
• volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
• allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
• allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
• no-enviction（驱逐）：禁止驱逐数据

过期策略

• 定期删除
  redis 会将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定期遍历这个字典来删除到期的 key。
  Redis 默认会每秒进行十次过期扫描（100ms一次），过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。
  1.从过期字典中随机 20 个 key；
  2.删除这 20 个 key 中已经过期的 key；
  3.如果过期的 key 比率超过 1/4，那就重复步骤 1；
  redis默认是每隔 100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载。
• 惰性删除
  所谓惰性策略就是在客户端访问这个key的时候，redis对key的过期时间进行检查，如果过期了就立即删除，不会给你返回任何东西。
  定期删除可能会导致很多过期key到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。这就是所谓的惰性删除，即当你主动去查过期的key时,如果发现key过期了,就立即进行删除,不返回任何东西.
  总结：定期删除是集中处理，惰性删除是零散处理。

Redis使用场景

• 会话缓存，如购物车
• 全页缓存，如最快速度加载曾浏览过的页面
• 队列，消息队列，本地化操作
• 排行榜（Sort Set），计数器

redis官方为什么不出windows版本

• 操作系统机制的轮询是不太一样的。
  简而言之 linxu轮询用epoll，window 用selector
  性能上来说 epoll是高于selector 的。selector与epoll是多路复用的函数

Redis一个字符串类型的值能存储最大容量是多少
512MB

Redis集群方案

• 客户端分片
• 基于代理的分片
• 路由查询
  Redis Cluster，Codis，

1 集群概念
所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。

1.1 使用redis集群的必要性
（1）单个redis存在不稳定性。当redis服务宕机了，就没有可用的服务了。

（2）单个redis的读写能力是有限的。

1.2 如何学习redis集群
（1）redis集群中，每一个redis称之为一个节点。

（2）redis集群中，有两种类型的节点：主节点(master)、从节点(slave)。

（3）redis集群 ，是基于redis主从复制实现。

所以，学习redis集群，就是从学习redis主从复制模型开始的

Redis主从复制
redis主从中，仅有一个主节点（master），其余是从节点（slave）
master 可读可写，slave 只能读
通过配置文件可以实现

哨兵模式 Sentinel

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）
作用：

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会进行选举，将其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

哨兵模式解决了redis主从复制， 当主挂掉后无法继续往缓存写入的问题
Redis主从复制和哨兵详情

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

• 过期 key 被清理
• 最大内存不足，导致 Redis 自动清理部分 key 以节省空间
• 主库故障后自动重启，从库自动同步
• 单独的主备方案，网络不稳定触发哨兵的自动切换主从节点，切换期间会有数据丢失

Redis主从之间是如何复制的 （RDB文件）

• 从数据库向主数据库发送sync(数据同步)命令。
• 主数据库接收同步命令后，会保存快照，创建一个RDB文件。
• 当主数据库执行完保持快照后，会向从数据库发送RDB文件，而从数据库会接收并载入该文件。
• 主数据库将缓冲区的所有写命令发给从服务器执行。
• 以上处理完之后，之后主数据库每执行一个写命令，都会将被执行的写命令发送给从数据库。

Redis 常见的性能问题都有哪些？如何解决？

• Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。
• Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
• Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
• Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内

Redis持久化
1.RDB持久化
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发

1）触发机制
手动触发分别对应save和bgsave命令

·save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用

·bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短

2）自动触发RDB的持久
1）使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改 时，自动触发bgsave。

2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点，更多细节见6.3节介绍的复制原理。

3）执行debug reload命令重新加载Redis时，也会自动触发save操作。

4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则 自动执行bgsave。

bgsave是主流的触发RDB持久化方式
RDB的优缺点
RDB的优点：
·RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据 快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份， 并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。

·Redis加载RDB恢复数据远远快于AOF的方式。

RDB的缺点：
·RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运 行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

·RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式 的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。
2.AOF持久化
AOF（append only file）持久化：以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用 是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

1）使用AOF
开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名 通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同 RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）

持久化更多详情

Redis 雪崩
缓存层承载着大量的请求，有效保护了存储层。但是如果由于缓存大量失效或者缓存整体不能提供服务，导致大量的请求到达存储层，会使存储层负载增加，这就是缓存雪崩的场景。

1.保持缓存层的高可用性

使用Redis 哨兵模式或者Redis 集群部署方式，即便个别Redis 节点下线，整个缓存层依然可以使用。除此之外，还可以在多个机房部署 Redis，这样即便是机房死机，依然可以实现缓存层的高可用。

2.限流降级组件

无论是缓存层还是存储层都会有出错的概率，可以将它们视为资源。作为并发量较大的分布式系统，假如有一个资源不可用，可能会造成所有线程在获取这个资源时异常，造成整个系统不可用。降级在高并发系统中是非常正常的，比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成整个推荐服务不可用。常见的限流降级组件如 Hystrix、Sentinel 等。

3.缓存不过期

Redis 中保存的 key 永不失效，这样就不会出现大量缓存同时失效的问题，但是随之而来的就是Redis 需要更多的存储空间。

4.优化缓存过期时间

设计缓存时，为每一个 key 选择合适的过期时间，避免大量的 key 在同一时刻同时失效，造成缓存雪崩。

5.使用互斥锁重建缓存

在高并发场景下，为了避免大量的请求同时到达存储层查询数据、重建缓存，可以使用互斥锁控制，如根据 key 去缓存层查询数据，当缓存层为命中时，对 key 加锁，然后从存储层查询数据，将数据写入缓存层，最后释放锁。若其他线程发现获取锁失败，则让线程休眠一段时间后重试。对于锁的类型，如果是在单机环境下可以使用 Java 并发包下的 Lock，如果是在分布式环境下，可以使用分布式锁（Redis 中的 SETNX 方法）。

分布式环境下使用Redis 分布式锁实现缓存重建，优点是设计思路简单，对数据一致性有保障;缺点是代码复杂度增加，有可能会造成用户等待。假设在高并发下，缓存重建期间 key 是锁着的，如果当前并发 1000 个请求，其中 999 个都在阻塞，会导致 999 个用户请求阻塞而等待。

6.异步重建缓存

在这种方案下构建缓存采取异步策略，会从线程池中获取线程来异步构建缓存，从而不会让所有的请求直接到达存储层，该方案中每个Redis key 维护逻辑超时时间，当逻辑超时时间小于当前时间时，则说明当前缓存已经失效，应当进行缓存更新，否则说明当前缓存未失效，直接返回缓存中的 value 值。如在Redis 中将 key 的过期时间设置为 60 min，在对应的 value 中设置逻辑过期时间为 30 min。这样当 key 到了 30 min 的逻辑过期时间，就可以异步更新这个 key 的缓存，但是在更新缓存的这段时间内，旧的缓存依然可用。这种异步重建缓存的方式可以有效避免大量的 key 同时失效。

缓存穿透
缓存穿透也被称为“击穿”。很多朋友对缓存穿透的理解是：由于缓存故障或者缓存过期导致大量请求穿透到后端数据库服务器，从而对数据库造成巨大冲击。
这其实是一种误解。
真正的缓存穿透应该是这样的：
在高并发场景下，如果某一个key被高并发访问，没有被命中，出于对容错性考虑，会尝试去从后端数据库中获取，从而导致了大量请求达到数据库，而当该key对应的数据本身就是空的情况下，这就导致数据库中并发的去执行了很多不必要的查询操作，从而导致巨大冲击和压力。
1、缓存空对象
对查询结果为空的对象也进行缓存，如果是集合，可以缓存一个空的集合（非null），如果是缓存单个对象，可以通过字段标识来区分。这样避免请求穿透到后端数据库。这种方式实现起来成本较低。
如果后面某个为空的记录在数据库中有数据了，该如何处理？
可以提前设置缓存的时效性，等过期之后自然会到后端刷新新数据。
如果时效性要求很高的话，那就采用数据库与缓存双写的模式来实现。
如果时效性要求不高的话，可以设置一个消息队列，专门用来接收数据库记录变更的消息，然后由专门的缓存服务去取出新数据并更新到缓存中。
2、单独过滤处理
对所有可能对应数据为空的key进行统一的存放，并在请求前做拦截，这样避免请求穿透到后端数据库。这种方式实现起来相对复杂。
3、最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存击穿解决方案
key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。
使用互斥锁(mutex key)
业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

缓存穿透：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
缓存击穿：key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
缓存雪崩：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

缓存雪崩与缓存击穿的区别在于存雪崩针对很多key缓存，缓存击穿则是某一个key。

如何选择合适的持久化方式
　　一般来说， 如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。
　　有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug。
如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

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

Redis线程模型
redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。
它采用 IO 多路复用机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件处理器进行处理。
文件事件处理器的结构包含 4 个部分：
多个 socket
IO 多路复用程序
文件事件分派器
事件处理器（包括：连接应答处理器、命令请求处理器、命令回复处理器）
多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用 程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

为啥 redis 单线程模型也能效率这么高？

• 纯内存操作
• 核心是基于非阻塞的 IO 多路复用机制
• 单线程反而避免了多线程的频繁上下文切换问题

redis并发竞争key问题如何解决

• 乐观锁，注意不要在分片集群中使用
• 分布式锁，适合分布式系统环境
• 时间戳，适合有序场景
• 消息队列，串行化处理

什么是RedLock

RedLock 的思想是使用多台 Redis Master ，节点完全独立，节点间不需要进行数据同步，因为 Master-Slave 架构一旦 Master 发生故障时数据没有复制到 Slave，被选为 Master 的 Slave 就丢掉了锁，另一个客户端就可以再次拿到锁。锁通过 setNX（原子操作） 命令设置，在有效时间内当获得锁的数量大于 (n/2+1) 代表成功，失败后需要向所有节点发送释放锁的消息。

什么是缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。
服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户

数据一致性
设置缓存过期时间，保证最终数据一致性