浅谈redis

redis

 

1.Redis的基本数据结构类型？

大多数小伙伴都知道，Redis有以下这五种基本类型：

• String（字符串）
• Hash（哈希）
• List（列表）
• Set（集合）
• zset（有序集合）

它还有三种特殊的数据结构类型

• Geospatial
• Hyperloglog
• Bitmap

 

2. Redis为什么这么快？

1.基于内存实现：内存读写是比在磁盘快很多的，Redis基于内存存储实现的数据库，相对于数据存在磁盘的MySQL数据库，省去磁盘I/O的消耗。

2.高效的数据结构(哈希，跳跃表，压缩列表

3.合理的线程模型（单线程减少上下文切换，i/o多路复用）：多路I/O复用技术可以让单个线程高效的处理多个连接请求，而Redis使用用epoll作为I/O多路复用技术的实现。并且，Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。

4.虚拟内存机制

 

 

3.Redis集群有哪几种模式？

Redis 实现高可用有三种部署模式：主从模式，哨兵模式，集群模式。

 3.1主从模式

 

 

主从模式中，Redis部署了多台机器，有主节点，负责读写操作，有从节点，只负责读操作。从节点的数据来自主节点，实现原理就是主从复制机制

主从复制包括全量复制，增量复制两种。一般当slave第一次启动连接master，或者认为是第一次连接，就采用全量复制，全量复制流程如下：

1.slave发送sync命令到master。
2.master接收到SYNC命令后，执行bgsave命令，生成RDB全量文件。
3.master使用缓冲区，记录RDB快照生成期间的所有写命令。
4.master执行完bgsave后，向所有slave发送RDB快照文件。
5.slave收到RDB快照文件后，载入、解析收到的快照。
6.master使用缓冲区，记录RDB同步期间生成的所有写的命令。
7.master快照发送完毕后，开始向slave发送缓冲区中的写命令;
8.salve接受命令请求，并执行来自master缓冲区的写命令

redis2.8版本之后，已经使用psync来替代sync，因为sync命令非常消耗系统资源，psync的效率更高。

slave与master全量同步之后，master上的数据，如果再次发生更新，就会触发增量复制。

主从复制的优缺点

    优点：

    1）避免单点故障，将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。

    2）master能自动将数据同步到slave，可以进行读写分离，分担master的读压力

    3）master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求

    缺点：

    1）不具备自动容错与恢复功能，master或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复

    2）master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题

    3）难以支持在线扩容，Redis的容量受限于单机配置

主从复制的目的

    1）一个是读写分离，分担 "master" 的读写压力

    2）一个是方便做容灾恢复

 

3.2哨兵模式

哨兵模式，由一个或多个Sentinel实例组成的Sentinel系统，它可以监视所有的Redis主节点和从节点，并在被监视的主节点进入下线状态时，自动将下线主服务器属下的某个从节点升级为新的主节点。但是呢，一个哨兵进程对Redis节点进行监控，就可能会出现问题（单点问题），因此，可以使用多个哨兵来进行监控Redis节点，并且各个哨兵之间还会进行监控。

简单来说，哨兵模式就三个作用：

• 发送命令，等待Redis服务器（包括主服务器和从服务器）返回监控其运行状态；
• 哨兵监测到主节点宕机，会自动将从节点切换成主节点，然后通过发布订阅模式通知其他的从节点，修改配置文件，让它们切换主机；
• 哨兵之间还会相互监控，从而达到高可用。

哨兵模式的作用

  1）通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器；

   2）当哨兵监测到 master 宕机，会自动将 slave 切换成 master ，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

哨兵模式故障切换的过程是怎样的呢

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

哨兵模式的优缺点

    优点：

    1）哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。

    2）主从可以自动切换，系统更健壮，可用性更高(可以看作自动版的主从复制)。

    缺点：

    Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

 

3.3集群cluster模式

在redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容。

在 Redis 的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的 Key到达的时候，Redis 会根据 crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

Redis集群的主从复制模型

     为了保证高可用，redis-cluster集群引入了主从复制模型，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点 ping 一个主节点 A 时，如果半数以上的主节点与 A 通信超时，那么认为主节点 A 宕机了。如果主节点 A 和它的从节点 A1 都宕机了，那么该集群就无法再提供服务了。

 集群的特点

     1）所有的 redis 节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽。

     2）节点的 fail 是通过集群中超过半数的节点检测失效时才生效。

     3）客户端与 Redis 节点直连，不需要中间代理层.客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

 

 

4.什么是缓存击穿、缓存穿透、缓存雪崩？

缓存穿透：指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。

如何避免缓存穿透呢？ 一般有三种方法。

1.如果是非法请求，我们在API入口，对参数进行校验，过滤非法值。
2.如果查询数据库为空，我们可以给缓存设置个空值，或者默认值。但是如有有写请求进来的话，需要更新缓存哈，以保证缓存一致性，同时，最后给缓存设置适当的过期时间。（业务上比较常用，简单有效）
3.使用布隆过滤器快速判断数据是否存在。即一个查询请求过来时，先通过布隆过滤器判断值是否存在，存在才继续往下查。

缓存击穿：key中对应数据存在，当key中对应的数据在缓存中过期，而此时又有大量请求访问该数据，缓存中过期了，请求会直接访问数据库并回设到缓存中，高并发访问数据库会导致数据库崩溃。

2）解决方案：

①预先设置热门数据：在redis高峰访问时期，提前设置热门数据到缓存中，或适当延长缓存中key过期时间。

②实时调整：实时监控哪些数据热门，实时调整key过期时间。

③对于热点key设置永不过期。

 

缓存雪崩： 指缓存中数据大批量到过期时间，而查询数据量巨大，请求都直接访问数据库，引起数据库压力过大甚至down机

解决方案就有两种：

1.使用互斥锁方案。缓存失效时，不是立即去加载db数据，而是先使用某些带成功返回的原子操作命令，如(Redis的setnx）去操作，成功的时候，再去加载db数据库数据和设置缓存。否则就去重试获取缓存。
2. “永不过期”，是指没有设置过期时间，但是热点数据快要过期时，异步线程去更新和设置过期时间。

 

5.热点Key是怎么产生的呢？主要原因有两个：

• 用户消费的数据远大于生产的数据，如秒杀、热点新闻等读多写少的场景。
• 请求分片集中，超过单Redi服务器的性能，比如固定名称key，Hash落入同一台服务器，瞬间访问量极大，超过机器瓶颈，产生热点Key问题。

如何解决热key问题？

• Redis集群扩容：增加分片副本，均衡读流量；
• 将热key分散到不同的服务器中；
• 使用二级缓存，即JVM本地缓存,减少Redis的读请求。

 

 

 6.Redis 过期策略和内存淘汰策略

过期策略：

1.定时过期

2.惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

3.定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。

Redis中同时使用了惰性过期和定期过期两种过期策略。

假设Redis当前存放30万个key，并且都设置了过期时间，如果你每隔100ms就去检查这全部的key，CPU负载会特别高，最后可能会挂掉。
因此，redis采取的是定期过期，每隔100ms就随机抽取一定数量的key来检查和删除的。
但是呢，最后可能会有很多已经过期的key没被删除。这时候，redis采用惰性删除。在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间并且已经过期了，此时就会删除。

 

7.Redis 内存淘汰策略

volatile-lru：当内存不足以容纳新写入数据时，从设置了过期时间的key中使用LRU（最近最少使用）算法进行淘汰；
allkeys-lru：当内存不足以容纳新写入数据时，从所有key中使用LRU（最近最少使用）算法进行淘汰。
volatile-lfu：4.0版本新增，当内存不足以容纳新写入数据时，在过期的key中，使用LFU算法进行删除key。
allkeys-lfu：4.0版本新增，当内存不足以容纳新写入数据时，从所有key中使用LFU算法进行淘汰；
volatile-random：当内存不足以容纳新写入数据时，从设置了过期时间的key中，随机淘汰数据；。
allkeys-random：当内存不足以容纳新写入数据时，从所有key中随机淘汰数据。
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰；
noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。

LRU（The Least Recently Used，最近最久未使用算法）：如果一个数据在最近一段时间没有被访问到，那么可以认为在将来它被访问的可能性也很小。因此，当空间满时，最久没有访问的数据最先被置换（淘汰）。是以时间维度来统计的。

LFU（Least Frequently Used ，最近最少使用算法）：如果一个数据在最近一段时间很少被访问到，那么可以认为在将来它被访问的可能性也很小。因此，当空间满时，最久没有访问的数据最先被置换（淘汰）。是以次数来统计的。

 

 

8.Redis 的持久化机制有哪些？优缺点说说

Redis提供了RDB和AOF两种持久化机制

RDB，就是把内存数据以快照的形式保存到磁盘上，RDB持久化，是指在指定的时间间隔内，执行指定次数的写操作，将内存中的数据集快照写入磁盘中，它是Redis默认的持久化方式。

执行完操作后，在指定目录下会生成一个dump.rdb文件，Redis 重启的时候，通过加载dump.rdb文件来恢复数据。RDB触发机制主要有以下几种：

 

 RDB 的优点：适合大规模的数据恢复场景，如备份，全量复制等

RDB缺点：没办法做到实时持久化/秒级持久化；新老版本存在RDB格式兼容问题

 

AOF（append only file） 持久化，采用日志的形式来记录每个写操作，追加到文件中，重启时再重新执行AOF文件中的命令来恢复数据。它主要解决数据持久化的实时性问题。默认是不开启的。

AOF的优点：数据的一致性和完整性更高

AOF的缺点：AOF记录的内容越多，文件越大，数据恢复变慢。

 

 

9.redis为什么要加过期时间？

防止网络抖动，或者宕机的时候redis没来的及释放锁。