redis

redis

redis有几种数据类型？以及应用场景？

• redis主要有五种数据类型。包括：

• String：可以存储字符串、整数、或者浮点数，String主要用来做简单的键值对缓存。

• List：主要用来存储一些列表型的数据结构，类似粉丝列表、文章的评论类型的数据。

• Set：可以存储无序集合，主要用来进行交集、并集、差集的操作。

• Zset：可以存储有序集合，主要用来去重和排序，如获取排名前几名的用户。

• Hash：存储包含键值对的无需散列表，主要应用于存储结构化的数据，如存储一个对象。

• redis的应用场景有哪些？
  1、计数器：对String进行自增自减运算，String适合最简单的k-v存储。
  2、缓存：将热点数据放入缓存中，设置内存的最大使用量以及淘汰策略来保证缓存的命中率。
  3、会话缓存：用户与应用服务器的会话信息。
  4、全页缓存
  5、查找表
  6、消息队列
  7、分布式锁实现
  8、共同好友功能、排行榜功能等

什么是热数据？

• 拿淘宝当例子，淘宝上的秒杀产品就是热数据，即被用户经常访问的数据就是热数据，redis中的热数据是加载到内存的。与热数据对应的就是冷数据，冷数据是并不经常被访问的数据。冷数据存放在磁盘中，只有当用户访问冷数据时，redis才会去磁盘中读取数据返回给用户。

为什么redis要将热数据存储到内存中？

• 如果redis将用户经常访问的热数据存储在磁盘中，那么秒杀商品在开抢的一瞬间，大量的并发访问请求会连接到服务器上，此时有许多线程都去磁盘上进行读取查询操作，而且磁盘速度慢，秒杀就变成了时杀（一个小时才刷新出商品界面）。但是内存快啊，在内存越来越便宜的今天，一个内存条不够那就来十个。假如一个内存条能支撑10000的并发，那么十个可就不是只能支撑10万的并发了，因为资源调度的原因能支撑比10万多的多的并发量。总之，将热数据存放在内存，就是为了提高并发量和服务器的性能。

redis 的持久化机制是什么？

• redis 提供两种持久化机制 RDB（默认） 和 AOF 机制：

---

• RDB：Redis DataBase，RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照保存的时间。

• RDB持久化机制的优点：
  1、只有一个文件 dump.rdb，方便持久化。
  2、容灾性好，一个文件可以保存到安全的磁盘。
  3、性能最大化，使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能。
  4、数据集比较大的时候，比 AOF 的启动效率更高。

• RDB持久化机制的缺点：
  1、数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。

---

• AOF（Append-only file)持久化：指将所有的命令行记录以 redis 命令请求协议的格式完全持久化存储为 aof 文件。也就是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis时会重新从持久化的日志中文件恢复数据。

---

• 当两种方式同时开启时，redis恢复数据会优先选择AOF恢复。
• AOF持久化机制的优点：
  1、数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次写命令操作就记录到 aof 文件中一次。
  2、通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
  3、AOF 机制的 rewrite 模式。当aof文件过大时rewrite模式会对命令进行合并重写。

---

• AOF持久化机制的缺点：
  1、AOF 文件比 RDB 文件大，且恢复速度慢。
  2、数据集较大的时候，比 rdb 启动效率低。

---

• RDB与AOF机制对比：
  1、AOF文件比RDB更新频率高，优先使用AOF还原数据。
  2、AOF比RDB更安全也更大。
  3、RDB性能比AOF好。
  4、如果两个都配置了则优先使用AOF做数据恢复。

什么是缓存雪崩？

• 缓存雪崩是指，缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。
• 缓存雪崩的解决方案有哪些？
  1、缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
  2、如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
  3、设置热点数据永远不过期。

什么是缓存穿透？

• 缓存穿透的概念很简单，用户想要查询一个数据，发现redis缓存没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。
• 缓存穿透的解决方案有哪些？
  1、布隆过滤器，使用多个hash方法来做筛选，将用户请求的redis缓存中不存在的数据过滤掉。

48. 什么是布隆过滤器？

• 布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数。当我们存储a.png时，使用布隆过滤器就是使用多个hash方法来做筛选，将用户请求的redis缓存中不存在的数据过滤掉。如下图所示，将三个hash方法映射到的位置置位1，此时我们的缓存中只有一个a.png。

49. 什么是缓存击穿？

• 缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。和缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
• 缓存击穿解决方案？
  1、设置热点数据永远不过期。
  2、加互斥锁，互斥锁

redis集群有几种？

• redis有三种集群模式：
• 主从模式（单master节点的叫主从模式，多matser节点的主从模式分区也叫客户端分区）
• Sentinel模式（单master节点的叫Sentinel哨兵模式，多master节点的Sentinel模式分区也叫代理分区）
• Cluster模式（官方的集群模式，至少三个master节点，也叫查询路由分区）。

---

19.1. 主从模式

• 主从模式：一主多从，主要用来进行读写分离，如下图。多主多从主要用来实现主节点负责所有的写请求，从节点负责所有的读请求，主节点将数据复制给从节点，主节点与从节点上的数据保持同步。主从结构一般用来支撑“读高并发”。当slave1宕机重启后，只需要再次从主节点同步数据就可再次恢复服务。当master宕机了，不影响slave的“读服务”，但此时不能提供“写服务”，master重启后需要使用RDB或者AOF机制进行数据恢复。master挂了以后，不会在slave节点中重新选一个master。因此主从结构必须配置redis的持久化。

• 主从模式工作机制：当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

---

19.2. sentinel模式

• sentinel模式： sentinel模式是建立在主从模式的基础上，当master挂了以后，sentinel会在slave中选择一个做为master，当挂掉的master重新启动后，它将不再是master而是变成slave节点，并接收新的master的同步数据。sentinel设计为一个sentinel集群是为了保证sentinel的高可用，否则sentinel就没有意义了。而多个sentinel之间也会自动监控。

• sentinel模式工作机制：
  1、每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令 。
  2、如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。
  3、如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态。
  4、当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线 。
  5、在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令 。
  6、当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次 。
  7、若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除。
  8、若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除。

---

19.3. cluster模式

• cluster模式：用于数据量大到一台redis服务器无法承受的时候，比如超高并发条件下。cluster模式的出现就是为了解决单机redis容量有限的问题，将redis的读写请求根据==hash slot（哈希槽）==的规则分配到多台redis节点，如下图中的master1，master2，master3。注意，此时三台master节点上存储的数据是不一样的，三台master节点的数据合起来才是所有的数据。使用cluster集群，只需要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要三个主节点才能正常运行，新增节点非常方便。
• cluster模式采用无中心结构
• cluster模式实现的就是redis的分布式缓存。即数据是分散开存储的。
• 主节点宕机后，相应的从节点会成为新的主节点来保证服务。宕机的主节点重启后就成为了从节点。
• 所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用。
• 不支持同时处理多个key（如MSET/MGET），因为redis需要把key（每个文件都有一个key）均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为。
• redis cluster使用数据分片（也叫hash slot哈希槽）而非一致性哈希（consistency hashing）来实现。
• 什么是hash slot（哈希槽）？
• redis cluster 采用虚拟哈希槽分区，假如客户端要存储一张图片a.png，所有的keys根据哈希函数映射到 0 ~ 16383 整数槽内，计算公式：slot = CRC16(key) & 16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。
• redis cluster过程详解：
  1、通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384 个槽位
  2、每份数据分片会存储在多个互为主从的多节点上
  3、数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)
  4、同一分片多个节点间的数据不保持一致性
  5、读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
  6、扩容时时需要需要把旧节点的数据迁移一部分到新节点
• 在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379，16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。
• 节点间的内部通信机制
• 集群元数据的维护有两种方式：集中式、Gossip 协议。redis cluster 节点间采用 gossip 协议进行通信。

. redis的内存淘汰策略是什么？有哪些？

• 淘汰策略：作为一个内存数据库，redis在内存空间不足的时候，为了保证命中率，就会选择一定的数据淘汰策略；淘汰策略有以下几种：
  1、volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰；
  2、volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰；
  3、volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰；
  4、allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰；
  5、allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰；
  6、noeviction：禁止驱逐数据，当内存使用达到阈值的时候，所有引起申请内存的命令会报错。

• redis不支持回滚：
  1、如果在一个事务中的命令出现错误，那么所有的命令都不会执行；
  2、如果在一个事务中出现运行错误，那么正确的命令会被执行。

---

50. 发生缓存失效后的补救办法？

• 限流降级
  这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

如何保证redis缓存与数据库双写时的一致性？

• 什么是双写：redis做缓存，数据库做持久化存储。那么用户请求写操作（如修改一个文件），缓存中的数据会先修改，再更新数据库中的数据。这就叫双写。而缓存先更新数据库后更新就会导致缓存和数据库出现数据不一致的问题。
• 解决方案：（以下效率很低，适用于强一致性（强一致性：必须保证缓存和数据库的一致性）的部署）
  1、使用中间件使操作串行化；
  2、使用redis做持久化并采用aof机制（aof机制博客上边讲了）