redis缓存

什么是Redis

• Redis(Remote Dictionary Server)
• 键只能为字符串，值：字符串、列表、集合、散列表、有序集合。
• Redis 用来做分布式锁。支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

Redis为什么这么快

• 完全基于内存，
• 数据结构简单
• 采用单线程

Redis有哪些数据类型

String，List，Set，Zset，Hash

Redis的应用场景

计数器

可以对 String 进行自增自减运算，从而实现计数器功能
可用于分布式锁限流

缓存

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

会话缓存

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

数据类型

string——适合最简单的k-v存储，类似于memcached的存储结构，短信验证码，配置信息等，就用这种类型来存储。
hash——一般key为ID或者唯一标示，value对应的就是详情了。如商品详情，个人信息详情，新闻详情等。
list——因为list是有序的，比较适合存储一些有序且数据相对固定的数据。如省市区表、字典表等。因为list是有序的，适合根据写入的时间来排序，如：最新
的***，消息队列等。
set——可以简单的理解为ID-List的模式，如微博中一个人有哪些好友，set最牛的地方在于，可以对两个set提供交集、并集、差集操作。例如：查找两个人
共同的好友等。
Sorted Set——是set的增强版本，增加了一个score参数，自动会根据score的值进行排序。比较适合类似于top 10等不根据插入的时间来排序的数据。

什么是Redis持久化？

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

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

RDB（默认） 和 AOF 机制

RDB

RDB：

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

优点：

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

AOF：持久化

• Append Only File持久化
• 每次写命令记录到日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。
• 当两种方式同时开启时，优先选择AOF恢复。

优点：

• 数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次

缺点：

• AOF 文件比 RDB 文件大，且恢复速度慢。

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

• 要数据安全性 选 AOF
• 其他情况选RDB，RDB方便备份，恢复也快

Redis的过期键的删除策略

• 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资
  源去处理过期的数据，
• 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。节省CPU资源，对内存不友好。占用大量内存。
• 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。

(expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key某个键的指针，value是该键的过期时间。键空间是指该Redis集群中保存的所有键。)
Redis中同时使用了惰性过期和定期过期两种过期策略。

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

EXPIRE和PERSIST命令。

Redis的内存淘汰策略有哪些

缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。
全局的键空间选择性移除

• noeviction：新写入操作会报错。
• allkeys-lru：移除最近最少使用的key。（这个是最常用的）
• allkeys-random：当随机移除某个key。

设置过期时间的键空间选择性移除

• volatile-lru：在设置了过期时间的键中，移除最近最少使用的key。
• volatile-random：在设置了过期时间的键中，随机移除某个key。
• volatile-ttl：在设置了过期时间的键中，有更早过期时间的key优先移除。

Redis事务的概念

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

• 一次执行完
• 按照顺序执行
• 其他命令插不进来

Redis事务的三个阶段

1. 事务开始 MULTI
2. 命令入队
3. 事务执行 EXEC

收到有EXEC、DISCARD、WATCH、MULTI之外的请求，将会把请求放入队列中排队

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）
  事务前后数据的完整性必须保持一致。
• 隔离性（Isolation）
  多个事务并发执行时，一个事务的执行不应影响其他事务的执行
• 持久性（Durability）
  持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。提交到磁盘。

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

Redis事务支持隔离性吗

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

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

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

Redis事务其他实现

• 基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行，其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完

项目运用：
利用Lua脚本判断用户是否已达最大参与次数

 //4.扣减活动可参与总次数-剩余次数
        String script = "local signUpTimes = redis.call('get', KEYS[1]) " +
                "local decr = tonumber(ARGV[1]) " +
                "if signUpTimes and tonumber(signUpTimes) >= decr " +
                "then return redis.call('decrby', KEYS[1], decr) else return -1 end ";
        RedisScript<Long> redisScript = new DefaultRedisScript<>(script, Long.class);
        Long result = stringTemplate.execute(redisScript, Collections.singletonList(signUpNumKey), String.valueOf(1));
        if (RedisConstant.LUA_SCRIPT_FAIL.equals(result)) {
            log.info("该用户已达最大参与次数");
            throw new DefinitelyRuntimeException("报名人数已满");
        }

Redis实现分布式锁

当且仅当 key 不存在，将 key 的值设为 value。 若给定的 key 已经存在，则SETNX 不做任何动作
SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
返回值：设置成功，返回 1 。设置失败，返回 0 。

使用SETNX完成同步锁的流程：

1. 使用SETNX命令获取锁，若返回0则获取失败，反之获取成功
2. 为了防止获取锁后程序出现异常，导致其他线程调用SETNX命令总是返回0而进入死锁状态，需要为该key设置一个“合理”的过期时间释放锁

自定义分布式锁注解

redis实现限流

Redis四种缓存方式

单机，主从，哨兵，集群

缓存击穿

定义

• 指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。和缓存雪崩不同的是，缓存击穿指并发查同
  一条数据，缓存雪崩是很多数据都查不到从而查数据库。

总结：

• 缓存击穿：一条数据查不到
• 缓存雪崩：多条数据查不到

解决方案

1. 设置热点数据永远不过期。
2. 加互斥锁（这个没懂，给谁加互斥锁？）

缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。用户直接查询事先被预热的缓存数据！

解决方案

1. 直接写个缓存刷新页面，上线时手工操作一下；
2. 数据量不大，可以在项目启动的时候自动进行加载；
3. 定时刷新缓存；

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

目的是保证核心服务可用，即使是有损的。而且有些服务是无法
降级的（如加入购物车、结算）。

哪些可降级；比如可以参考日志级别设置预案：

• 服务正在上线而超时
• 些服务在一段时间内成功率有波动
• 可用率低于90%，或者数据库连接池被打爆了

热点数据和冷数据

热点数据，缓存才有价值
对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占
用内存，而且价值不大。频繁修改的数据，看情况考虑使用缓存
对于热点数据，比如我们的某IM产品，生日祝福模块，当天的寿星列表，缓存
以后可能读取数十万次。再举个例子，某导航产品，我们将导航信息，缓存以后
可能读取数百万次。
数据更新前至少读取两次，缓存才有意义。这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。
那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的某助手产品的，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到
Redis缓存，减少数据库压力。

缓存热点key

缓存中的一个Key(比如一个促销商品)，在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压
垮。
解决方案
对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，这样缓存就有数据了，然后解锁；其他进程如果发现有锁就等待，然后等解锁后，此时缓存就有数据了，不需要再查数据库

Redis Mysql如何保证一致性

• 延迟双删：先删除缓存，然后去更新数据库，更新完再删一遍缓存【第二次删是防止A线程去更新数据库时，B线程又把数据库的旧数据存到redsis上了】
• MySQL binlog 消息推送更新

Redis Mysql如何保证一致性

使用Redis做过消息队列吗，是如何实现的

使用list类型保存数据信息，rpush生产消息，lpop消费消息，当lpop没有消息时，可以sleep一段时间，然后再检查有没有信息，如果不想sleep的话，可以使用blpop, 在没有信息的时候，会一直阻塞，直到信息的到来。redis可以通过pub/sub主题订阅模式实现一个生产者，多个消费者，当然也存在一定的
缺点，当消费者下线时，生产的消息会丢失

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

512M

redis场景应用