Redis知识点

Redis知识点

一、Redis基础

1、什么是Redis？

• Redis(C语言编写)是一款NoSQL(非关系性)数据库，采用key-value存储方式，数据存储在内存中，读写速度非常快。

2、Redis常用的数据类型？

• Redis提供了丰富的数据类型

  • string（相当于与Java中的String） 它是一个二进制安全的字符串，意味着它不仅能够存储字符串、JSNO、还能存储图片、视频等多种类型（生成二进制或者序列化的对象）, 最大长度支持512M

  • hash（相当于java中的HashMap）采用key-value 存储对象 ,hash类型下的value只能存储字符串，不允许存储其他类型数据，不存在嵌套现象。如果数据未获取到，对应的值为(nil)

  • list：(相当于Java中的Likelist) 存储有序集合，底层使用双向链表存储结构实现

  • set：(相当于Java中的HashSet）存储无序集合，不可存储重复数据

  • zse：(相当于Java中的TreeSet）存储有序集合，不可存储重复数据，zset对每个元素都会关联一个 double 类型的分数，利用该分数作为排序的依据。有序集合可以利用分数进行从小到大的排序。虽然有序集合的成员是唯一的,但是分数(score)却可以重复。就比如在一个班中，学生的学号是唯一的，但是每科成绩却是可以一样的，redis可以利用有序集合存储学生成绩快速做成绩排名功能

3、Redis持久化机制？

• Rdis提供了两种持久化机制分别为：RDB AOF

• RDB（默认持久化机制）：采用快照的方式全量备份数据，以二进制序列化形式的文件存储，并且在存储上非常紧密，但是无法做到实时持久化

  • RDB持久化触发机制分为：手动触发和自动触发

    • 手动触发：

      • save命令：该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB完成为止，如果数据量大的话会造成长时间的阻塞，所以线上环境一般禁止使用。
      • bgsave命令:执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体流程如下：
        • 执行bgsave命令时，Redis主进程会fork一个子进程来完成RDB的过程，会先将数据写入到一个临时二进制文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件（可以理解为Copy On Write机制）。Redis主进程阻塞时间只有fork阶段的那一下。相对于save，阻塞时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

    • 自动触发：配置redis.conf，触发规则，自动执行

      # 当在规定的时间内，Redis发生了写操作的个数满足条件，会触发发生BGSAVE命令。
      # save <seconds> <changes>
      # 当用户设置了多个save的选项配置，只要其中任一条满足，Redis都会触发一次BGSAVE操作
      save 900 1 
      save 300 10 
      save 60 10000
      # 以上配置的含义：900秒之内至少一次写操作、300秒之内至少发生10次写操作、
      # 60秒之内发生至少10000次写操作，只要满足任一条件，均会触发bgsave
      

• AOF：采用日志的方式记录对数据操作的命令，可做到实时持久化，AOF默认是关闭的，通过redis.conf配置文件进行开启

  • AOF持久化触发机制：
    • （1）每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
    • （2）每秒同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失。
    • （3）不同步：appendfsync no 从不同步

二、Redis高级

1、什么是Redis的事务？

• redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

  • **Redis事务没有隔离级别的概念：**批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到
  • **Redis不保证原子性：**Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行

• Redis事务的三个阶段：

  • 开始事务
  • 命令入列
  • 执行事务

• Redis事务相关命令：

  • watch key1 key2 … : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ）
  • multi : 标记一个事务块的开始（ queued ）
  • exec : 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ）
  • discard : 取消事务，放弃事务块中的所有命令
  • unwatch : 取消watch对所有key的监控

2、Redis做缓存会遇到的问题？

1.缓存穿透

• 缓存穿透是指查询一个数据库一定不存在的数据，其次redis缓存中也没有该数据（比如id=-1）
  • 解决方案：
    • （1) 缓存空对象 ：如果从数据库查询的对象为空，也放入缓存，key为用户提交过来的主键值，value为null，只是设定的 缓存过期时间较短，比如设置为60秒。这样下次用户再根据这个key查询redis缓存就可以查询到值了 （当然值为null），从而保护我们的数据库免遭攻击。
    • （2) 布隆过滤器：判定不存在的数据，那么该数据一定不存在，利用它的这一特点可以防止缓存穿透。

2.缓存击穿

• 缓存击穿，是指一个key非常热点（例如双十一期间进行抢购的商品数据），在不停的扛着大并发，大 并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求到数据库 上，就像在一个屏障上凿开了一个洞。
  • 解决方案:
    • （1）设置热点数据永不过期
    • （2）加互斥锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权 限，因此只能等待。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

3.缓存雪崩

• 缓存雪崩是指缓存中大批量的 key 同时过期，而此时数据访问量又非常大，从而导致后端数据库压力突然暴增，甚至会挂掉，这种现象被称为缓存雪崩。它和缓存击穿不同，缓存击穿是在并发量特别大时，某一个热点 key 突然过期，而缓存雪崩则是大量的 key 同时过期，因此它们根本不是一个量级
  • 解决方案：
    • （1）redis高可用：搭建集群
    • （2）限流降级：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对 某个key只允许一个线程查询数据和写缓存，其他线程等待。
    • （3）数据预热：数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数 据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让 缓存失效的时间点尽量均匀。

3、Redis的集群方案

• 单机Redis的读写速度非常快，能够支持大量用户的访问。虽然Redis的性能很高，但是对于大型网站来 说，每秒需要获取的数据远远超过单台redis服务所能承受的压力，所以我们迫切需要一种方案能够解决 单台Redis服务性能不足的问题。这就需要使用到Redis的集群了。Redis集群有多种方案，下面分别进行 讲解。

1.主从复制(Replication)

• 指将一台Redis服务器的数据，复制到其他的Redis服务器

  • 角色：前者称为主节点(master/leader)，后者称为从节点(slave/follower)

  • 原则：数据的复制是单向的，只能由主节点到从节点

  • 同步：Master以写为主，Slave 以读为主，Slave启动时会连接master来同步数据（读写分离）

  • 默认情况下，每台Redis服务器都是主节点,且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点

• 主从复制的作用：数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

  • 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余

    • 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务
      • 即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点，分担服务器负载；尤其是 在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

  • 高可用（集群）基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础

    • 单台Redis最大的实用内存不应该超过20G

2.哨兵(sentinel)

• sentinel(哨兵)是用于监控redis集群中Master状态的工具，其本身也是一个独立运行的进程，是Redis的高可用解决方案

  • 原理：哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例

• 故障切换（failover）

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

• 优点：

  • 在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用 （HA）（选举）

  • 基于主从复制模式，所有的主从配置优点，它全有

  • 哨兵可以做集群

  • 主从自动切换，故障可以转移，提高系统可用性

• 缺点：

  • Redis不好在线扩容，集群一旦到达上线，在线扩容就十分麻烦
  • 哨兵模式的配置比较麻烦

切换，保证系统的高可用 （HA）（选举）

• 基于主从复制模式，所有的主从配置优点，它全有

• 哨兵可以做集群

• 主从自动切换，故障可以转移，提高系统可用性

• 缺点：

  • Redis不好在线扩容，集群一旦到达上线，在线扩容就十分麻烦
  • 哨兵模式的配置比较麻烦