概述

什么是Redis

Redis是一个使用C语言写成，凯源的高性能key-value非关系缓存数据库。他支持存储的value类型比较多，包括String(字符串)、list(集合)、set(集合)、zset(sorted-set–有序集合) 和 hash (哈希类型）。Redis都是基于缓存的，所以很快，每秒都可以处理10万读写操作，是一直性能最好的key-value DB。redis也可以实现数据写入磁盘中，保证了数据的安全不丢失，而且redis的操作时原子性的

Redis 有那些优缺点

优点：

  • 读写性能优异，redis能读的速度是110000次/s，写的速度是810000次/s
  • 支持数据持久化，支持AOF和RDB两种持久化方式
  • 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操控台合并的原子执行
  • 数据结构丰富，除了支持String类型的value 外还支持hash、set、zset、list等数据结构
  • 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离

缺点：

  • 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

  • Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

  • 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

  • Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

使用redis 有哪些好处

  • 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势在于查找和操作的时间复杂度低
  • 支持丰富数据类型，支持String，list，set，zset， hash
  • 支持事务，操作都是原子性
  • 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后自动删除

为什么要用 Redis 而不用 map/guava 做缓存?

  • 缓存分为本地缓存和分布式缓存。以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。
  • 使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性。缺点是需要保持 redis 或 memcached服务的高可用，整个程序架构上较为复杂。

Redis为什么这么快

  • 完全基于内存，绝大部分请求内存操作，影响速度的内存和网络速度，而非CPU
  • 数据结构简单：Redis的数据结构是为自身专门量身打造的，而这些数据结构查找和操作的时间复杂度都是O(1)
  • 避免上下文切换：因为单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的开销，而且单线程不会导致死锁
  • 多路复用和非阻塞I/O：Redis 使用 I/O 多路复用功能来监听多个 socket 连接客户端，这样就可以使用一个线程来处理多个情况，从而减少线程切换带来的开销，同时也避免了 I/O 阻塞操作，从而大大地提高了 Redis 的性能
  • 使用底层模型不同，他们之间底层实现方式以及客户端之间通信的应用协议不一样，Redis直接构建了VM机制，因为一般的系统调用系统函数的话，会浪费一定时间去移动和请求

Redis有哪些数据类型

  • Redis主要有5种数据类型，包括String、List、Set、Zset、Hash满足大部分使用要求

image-20210901105110111

Redis的应用场景

  • 计数器

    可以对String 进行自增自减运算，从而实现计数器功能。Redis这种内存型数据库的读写性能非常高，很适合存储频繁读写的计数量

  • 缓存

    将热点数据放到内存中，设置内存的最大使用两以及淘汰策略来保证缓存的命中率

  • 会话缓存

    可以使用 Redis 来统一存储多台应用服务器的会话信息。当应用服务器不再存储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容易实现高可用性以及可伸缩性。

  • 全页缓存 FPC

    除基本的会话token之外，Redis还提供很简便的FPC平台。以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。

  • 查找表

    例如DNS记录就很适合使用 Redis 进行存储。查找表和缓存类似，也是利用了 Redis 快速的查找特性。但是查找表的内容不能失效，而缓存的内容可以失效，因为缓存不作为可靠的数据来源。

  • 消息队列（发布/订阅功能）

    List是一个双向链表，可以通过 lpush 和 rpop 写入和读取消息。不过最好使用 Kafka、RabbitMQ 等消息中间件。

  • 分布式锁实现

    在分布式场景下，无法使用单机环境下的锁来多个节点上的进程进行同步。可以使用Redis自带的SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现。

  • 其他

    Set 可以实现交集，并集等操作，从而实现共同好友等功能。ZSet 可以实现有序性操作，从而实现排行榜等功能。

持久化

  • 什么是Redis 持久化 持久化就是把内存的数据写到磁盘中区，防止服务器宕机了内存数据丢失

Redis 的持久化机制是什么？ 各自的优缺点？

  • Redis 提供两种持久话机制RDB(默认) 和 AOF 机制：

RDB：是Redis DataBase缩写快照

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

在这里插入图片描述

优点：

  • 只有一个文件dumb.rdb，方便持久化
  • 容灾性好，一个文件可以保存到安全的磁盘
  • 性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化，使用单子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
  • 相对于数据集大时，比AOF的启动效率更高

缺点：

  • 数据安全性低，RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失，所以这种方式更是华数据要求不严谨的时候
  • AOF（Append-only file)持久化方式： 是指所有的命令行记录以 redis 命令请 求协议的格式完全持久化存储)保存为 aof 文件。

AOF：持久化

  • AOF持久化（即Append Only File 持久化）， 则是将Redis 执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志文件恢复数据
  • 当两种方式同时开启，数据恢复Redis会有限选择AOF恢复

在这里插入图片描述

优点：

  • 数据安全，aof持久化可以配置appendfsync属性，有always，每进行一次命令操作就记录在aof文件中一次
  • 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
  • AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)

缺点：

  • AOF文件比RDB文件大，且恢复速度慢
  • 数据集大的时候，比RDB启动效率低

两种持久化的优缺点是什么

  • AOF文件比RDB更新频率高，优先使用AOF还原数据
  • AOF比RDB更安全也更大
  • RDB性能比AOF好
  • 如果两个都配了有限加载AOF

如果选择合适的持久化方式

  • 一般来说，如果想达到足以媲美PostgreSQL的安全性，你应该同时使用两种持久化功能，在这种情况下，当Redis重启的时候回有限载入AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据要完整

  • 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。

  • 有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug。

  • 如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

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

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

Redis的过期键的删除策略

Redis是Key - value数据库，我们可以设置Redis中缓存的key的过期时间，Redis的过期缓存策略就是指当 Redis 中缓存的key过期了，Redis如何处理，通常有三种：

  • 定时过期：每个 设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据对内存很友好，但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的相同和吞吐量

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

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

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

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

  • expire和persist命令。

我们知道通过expire来设置key 的过期时间，那么对过期的数据怎么处理呢?

  • 除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：
    • 定时去清理过期的缓存；
    • 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

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

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

Redis的内存淘汰策略有哪些

1
Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。
  • 全局的键空间选择性移除
    • noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
    • allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。（这个是最常用的）
    • allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。
  • 设置过期时间的键空间选择性移除
    • volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
    • volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
    • volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。
  • 总结
1
Redis的内存淘汰策略的选取并不会影响过期的key的处理。内存淘汰策略用于处理内存不足时的需要申请额外空间的数据；过期策略用于处理过期的缓存数据。

Redis主要消耗什么物理资源？

  • 内存。

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

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

Redis如何做内存优化？

  • 可以好好利用Hash,list,sorted set,set等集合类型数据，因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面

线程模型

  • Redis基于Reactor模式开发了网络事件处理器，这个事件处理器称为文件事件处理器（file event handler)。它的组成结构分为四部分：多个套接字，IO多路复用程序，文件事件分派器，时间处理器。因为文件分派器队列的消费是单线程的，所以Redis是单线程模型

image-20210901152454724

image-20210901152509838

  • 文件事件处理器使用IO多路复用程序同时监听套接字，并根据套接字目前执行的任务为套接字关联不同的时间处理器。
  • 当被监听的套接字准备好执行连接应答（accept），读取（read）、写入（write）、关闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事假处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器以单线程方式运行，但通过使用IO多路复用程序来监听多个套接字，文件事件处理器实现了高性能的网络通信模型，又可以很好地与redis服务器中其他 以单线程方式运行的模块进行对接，保持了redis内部单线程设计的简单性

时间事件：时间事件记录着那些在指定时间点运行的事件，多个时间事件以无序链表结构保存在服务器状态中。服务器需要定期对自身的资源和状态进行检查、整理， 保证服务器维持在一个健康稳定状态， 这类操作被统称为常规操作（cron job）。在 Redis 中， 常规操作由 redis.c/serverCron 实现，包括如下操作： - 更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等 - 清理数据库中的过期键值对 - 对不合理的数据库进行大小调整 - 关闭和清理连接失效的客户端 - 尝试进行 AOF 或RDB 持久化操作 - 如果服务器是主节点的话，对附属节点进行定期同步 - 如果处于集群模式的话，对集群进行定期同步和连接测试。Redis 将 serverCron（后文简称为sC） 作为时间事件运行， 确保它能够定期自动运行一次，又因 sC 需要在 Redis 服务器运行期一直定期运行， 所以它是一个循环时间事件：sC 会一直定期执行，直至服务器关闭。

两种事件的调度：简单地说， Redis 里面的两种事件呈协作关系， 它们之间包含如下属性： - 一种事件会等待另一种事件执行完后，才开始执行，事件之间不会出现抢占 - 事件处理器先处理文件事件（即处理命令请求），再执行时间事件（调用 sC） - 文件事件的等待时间（类 poll 函数的最大阻塞时间），由距离到达时间最短的时间事件决定。这表明， 实际处理时间事件的时间， 通常会比事件所预定的时间要晚， 延迟时间取决于时间事件执行前， 执行完成文件事件所耗时间。

Redis事务

  • 事务是一个单独的隔离操作：事务中所有命令都会序列化、按顺序执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
  • 事务是一个原子操作：事务中的命令要么全部被执行，要门全部都不执行

Redis事务的概念

  • Redis 事务的本质是通过MULTI、EXEC、WATCH等一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
  • 总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

Redis事务的三个阶段

  • 事务开始MULTI
  • 命令入队
  • 事务执行EXEC

事务执行过程中，如果服务端收到EXEC、DISCARD、WATCH、MULTI之外的请求，将会请求放入队列排队

Redis事务相关命令

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的

Redis会将一个事务中的所有命令序列化，然后按顺序执行。

  1. redis 不支持回滚，“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。
  2. 如果在一个事务中的命令出现错误，那么所有的命令都不会执行；
  3. 如果在一个事务中出现运行错误，那么正确的命令会被执行。
  • WATCH 命令是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为。 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。
  • MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
  • EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。 当操作被打断时，返回空值 nil 。
  • 通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。
  • UNWATCH命令可以取消watch对所有key的监控。

事务管理（ACID） 概述

  • 原子性（Atomicity）

    原子性是指事务是一个不可分割的工作，要么事务中的操作都发生，要么都不发生

  • 一致性（Consistency)

    事务前后数据的完整性必须保持一致

  • 隔离性（lsolation）

    多个事务并发执行时，一个事务不影响其他事务的执行

  • 持久性（Durability）

    持久性是一个事务一旦被提交的，他对数据库中的数据的改变是永久的，接下来即使数据库发生故障也不应该对其有任何影响

Redis的事务总是具有ACID中的一致性和隔离性，其他特性是不支持的。当服务器运行在_AOF_持久化模式下，并且appendfsync选项的值为always时，事务也具有耐久性

Redis事务支持隔离性吗

  • Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。

Redis事务保证原子性吗，支持回滚吗

  • Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

Redis事务其他实现

  • 基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行，
    其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完
  • 基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐