Redis及其他缓存

1.NOSQL、Redis概述，通用命令，redis五大数据类型，三大特殊数据类型

NOSQL概述：

(NOT ONLY SQL-不仅仅是SQL),泛指非关系型数据库，为解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用问题

常见nosql:redis,hbase。

和关系型数据的对比区别：数据之间没有关联关系，数据存储在内存中，操作数据相对较快。关系型数据库数据之间存在关联关系，数据存储在磁盘中，操作数据非常耗时。

优点：成本低、查询速度快、支持多种数据格式(基本数据类型、集合、对象、图片、文档等格式)、扩展性相对关系型数据库较好。

非关系型数据库优势：复杂查询较方便，事务的支持导致安全性很高。

总结：关系型数据库和非关系型数据库并非对立而是互补的关系，从而弥补对方的劣势。一般将数据存储在关系型数据库中，非关系型数据库中备份关系型数据库的数据(热点数据、高频访问且不常修改的数据)。

主流的nosql:

key-value存储数据库：redis。典型用于内容缓存，处理大量数据的高访问负载

列存储数据库：Hbase。典型用于分布式的文件系统

文档型数据库：Mongdb。典型用于web应用

图形数据库：Neo4J。典型用于社交网络

Redis概述：

C语言开发的高性能键值对数据库，在内存中就是一个Map集合。支持多种键值数据类型。key为字符串，value可是任意类型。

value类型分类：

字符串类型-String：Map<String,String>

散列类型-hash：Map<String,Map<String,String>>

列表类型-list:Map<String,List<String>> 数据可重复

集合类型-set:Map<String,Set<String>> 数据不可重复

有序集合类型-sortedset:Map<String,sortedset<String>> 数据不可重复，支持排序

应用场景：缓存、聊天室好友在线列表、任务队列(秒杀、抢购、12306抢票)、应用排行榜、网站访问统计、数据过期处理、分布式集群架构中session分离

2.redis持久化机制、RDB持久化、AOF持久化

REDIS持久化概述：

redis高性能原因是因为将数据保存在内存中，为了保证redis重启后数据不丢失，将数据从内存保存到硬盘中，过程称为持久化。

持久化支持RDB和AOF两种方式，可以单独使用1种，也可以将2种进行结合使用。

默认支持RDB持久化，无序配置。此机制是在固定时间间隔将内存的数据集快照写入磁盘。

AOF持久化以日志的形式记录服务器所处理的写操作，在redis启动之初会读取此文件来重建redis数据库。以保证重启后数据完整。

持久化可通过配置来禁用

可同时使用RDB和AOF持久化

RDB持久化，也称快照(Snapshot)

RDB持久化特点：将内存种数据以一定时间间隔，将内存数据写入硬盘中，默认持久化的方式，保存的文件以.rdb为后缀

快照生成方式：客户端方式(BGSAVE和SAVE指令)、服务器配置自动触发

客户端方式之BGSAVE操作(并行操作)：客户端使用BGSAVE命令创建快照，当redis服务器收到客户端发送的BGSAE命令，服务器会调用fork创建1个子线程，

子线程负责快照写入磁盘，主线程继续处理命令请求

客户端方式之SAVE操作(串行操作)：客户端使用SAVE命令创建快照，redis服务器收到客户端发送的SAVE命令，服务器在快照完毕之前不会响应其他命令。此模式不常用

配置自动触发：和Mysql的redo机制类似。如果在redis.conf种设置了save配置选项，redis会在选项满足之后自动触发一次BGSAVE命令，如果设置多个save配置选项，

其中一个满足，也会执行一次BGSAVE命令

服务器接受客户端shutdown指令：服务器收到客户端的shutdown指令后，会执行一个save命令，阻塞所有客户端，不再执行任何客户端命令，并再save命令执行完毕后关闭服务器

配置生成快照名称和位置:

修改生成快照名称：dbfilename dump.rdb

修改生成位置 dir./

RDB(快照)持久化的缺点：

无法保证系统高可用性质，即无法避免最大程度的数据丢失。因为一旦在持久化之前出现服务宕机，未来得及保存进入磁盘的数据就会丢失

AOF只追加日志文件

特点：可将客户端执行的所有set命令记录到日志文件中，AOF持久化会将被执行的写命令保存到AOF文件的末尾，以此来记录数据变化；

恢复内存数据，只需要将AOF文件中包含的写命令从头到尾执行一次即可；

redis服务器启动之初会读取该文件，来重新构建redis数据库，从而保证数据完整

开启AOF持久化:

redis.conf默认配置中的AOF持久化机制是关闭的，需要配置中开启。

开启步骤：修改 appendonly yes 开启持久化；修改appendfilename "appendonly.aof"; 指定生成文件名称

日志追加频率：

always:每次写操作，都写入磁盘，可最大程度减少数据的丢失，但是此同步策略需要对磁盘大量操作，因此redis处理速度会受到磁盘性能的限制。谨慎使用

everysec:每秒执行一次同步，显式的将多个命令存入磁盘。使用此方式和不使用此方式时性能相差无几，同时每秒一次即便系统崩溃也只会丢失1S的数据。推荐使用

no:由操作系统决定何时同步。不会对性能带来影响，但是会丢失不定量数据。不推荐

修改同步频率：通过 appendfsync always/everysec/no 指定

AOF文件的重写

AOF(日志文件)的缺点：持久化文件越来越大，为了压缩AOF持久化文件，redis提供了AOF重写(ReWriter)机制

AOF重写可在一定程度上减小AOF文件的体积

触发重写方式

客户端方式触发重写：执行 BGREWRITEAOF 命令，不会阻塞redis服务

服务端方式配置自动重写：修改redis.conf文件中的 auto-aof-rewrite-percentage和auto-aof-rewrite-min-size。

例如：auto-aof-rewrite-percentage值为100和auto-aof-rewrite-min-size 64mb。在开启AOF持久化时，当AOF文件大于64M，并且AOF文件比上次重写后体积大了至少几倍，自动触发

重写原理：将内存中的数据库用命令的方式重写生成了一个AOF文件，来替换原来的文件

重写流程：

持久化总结

RDB和AOF两种方案可同时使用，也可单独使用，也可都不使用。使用那种取决于用户的数据和应用决定

无论是使用RDB还是AOF，持久化文件都是保存在磁盘的，有必要除了持久化外，还应该对持久化文件进行备份(最好备份在多个地方)

RDB和AOF的选择问题：

对数据非常敏感，选择AOF。但是文件体积较大，恢复速度较慢

数据呈现阶段有效性，选择rdb，可做到阶段内数据无丢失，恢复速度较快。但是利用RDB实现紧凑的持久化会使得redis性能降低很多

总之如果不能承受数分钟以内的数据丢失，对业务数据非常敏感选择AOF;可以承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选择RDB。

灾难恢复选用RDB

双重保险策略，同时开启AOF和RDB，重启后先使用AOF进行数据恢复，降低丢失数据，两者同时开启，数据恢复时会选择忽略RDB，选择AOF进行恢复，从而避免数据不一致或重复问题

3.java操作redis、jedis连接池、使用redis缓存不常修改的数据

jedis基本使用：

redis不仅可通过命令操作，主流语言都有客户端支持。官方推荐java客户端使用jedis和redisson。企业中jedis使用居多

实现步骤：引入jedis依赖；创建jedis对象；调用jedis对方的方法实现对string、list、set、zset、hash的操作

jedis连接池的基本概念：jedis资源的创建和消费非常消耗性能，jedis提供了池化技术，jedispool在创建时初始化一些连接资源存储到池中，使用jiedis连接资源时间无需创建，从连接池中获取,使用完毕后将jedis还给连接池，供其他请求使用。使用GenericObjectPoolConfig 和JedisPool来创建连接池

4.spring boot整合redis核心api

springboot data redis 提供了stringredistemplate和redistemplate,stringredistemplate是redistemplate的子类。

区别在于stringredistemplate的key和value只能是string,而redistemplate的key和value可以是object任意类型的数据。

使用redistemplate默认是将对象序列化到redis中，因此放入的对象必须实现对象序列化接口 serializable

实现步骤：引入依赖；配置连接；使用redistemplate进行操作

5.redis事务、watch锁、redis实现分布式锁、数据的删除策略、淘汰策略

redis事务

定义：一系列预定义命令保证成一个整体(队列)，执行时一次性按照添加顺序依次执行，中途不会中断或干扰。

本质：一组命令的集合

没有隔离级别的概念，所有命令在事务中并未直接执行，只有在执行exec命令时才会执行

redis单条命令保证原子性，事务不保证原子性

执行步骤：开启事务(multi)，执行操作，提交事务(exec)

事务操作

开启事务 multi (设定事务开启位置，后续所有指令均加入到事务中)

取消事务 discard 终止当前事务的定义，在multi之后，exec之前

执行事务 exec 设定事务的结束位置，同时执行事务，与multi成对出现。可保证事务的一致性

注意事项：定义事务中，命令存在语法错误，则事务中所有命令都不会执行；

如果命令格式语法正确，但是无法正确执行，则正确的命令会执行，运行错误的命令不会执行(例如对list执行incr)，已经执行完毕的命令对应数据不会自动回滚，需要自行回滚。

watch锁：

问题：线程1监听某个key，当事务还未执行完，事务2操作了这个key，watch会通知线程1事务失败

基于特定条件的事务执行：假如对已售空的商城进行补货，多个采购员都可以进行，为了避免数据重复操作，所以在操作某一数据前，先锁定要操作的数据，一旦发生变化，终止当前事务

基于特定条件的事务执行(锁)：对key添加监视锁，在执行exec操作前，如果Key发生了变化，则终止事务执行。watch key1[kye2...].取消所有key的监视 unwatch;

watch锁操作：

悲观锁：认为什么时候都会出问题，无论做什么都会加锁

乐观锁：认为什么时候都不会出现问题，所以不会加锁，更新数据时候判断一下，在此期间是否有人更改此数据(获取version,更新的时候比较version)

redis中数据的删除策略

定时删除、惰性删除、定期删除

淘汰策略

6.mybatis自身本地缓存结合redis实现分布式缓存

redis实现分布式缓存

缓存：计算机内存中的一段数据

内存中数据特点：读写快、断电立即丢失

缓存解决的问题：提高网站吞吐量，网络运行效率快，解决数据库访问压力

数据库中极少修改的数据适合使用缓存，更多用于数据查询

本地缓存和分布式缓存的区别：本地缓存保存在应用服务器内存中(mybatis的一级和二级缓存就是本地缓存)；分布式缓存存储在应用服务器之外的数据

集群：将一种服务创建多个节点，放在一起共同对系统提供服务的过程称为集群

分布式：多个不同服务集群共同对系统提供服务的系统称为分布式系统。

利用mybatis自身本地缓存结合redis缓存实现分布式缓存：todo

7.主从复制简介、工作流程、常见问题

主从复制简介

redis集群实现高可用：避免单机redis服务故障，准备多台服务器，互相连通，将数据复制多个副本保存在多个服务器上，连接在一起，并保证数据式同步的。

即便其中1台服务宕机，其他服务器依然可以继续提供服务，实现redis的高可用，同时实现数据冗余备份。

主从复制定义：即将master中的数据及时、有效的复制到slave中.master支持读写，在进行写时间，将出现变化的数据自动同步至slave。

主从复制作用：

读写分离：master负责写，slave负责读取，提高服务器的读写负载能力

负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求变化，改变slave数量，通过多个从节点分担数据读取负载，大大提高了redis服务器并发量和吞吐量

故障恢复：master出现问题，slave提供服务，实现快速的故障恢复

数据冗余：实时数据热备份，持久化之外的一种数据冗余方式，slava和master数据同步

高可用基石：基于主从机制，构建哨兵模式和集群，实现redis高可用方案

主从复制流程

建立连接：准备阶段，slave连接master。

连接的三种方式：

客户端发送命令：slaveof masterip masterport;

驱动服务器参数：redis-server -slaveof masterip masterport

服务器配置：slaveof masterip masterport

断开连接：slaveof no one;断开连接后之前接受数据不会删除，只是不在接收新的master数据

数据同步: master数据同步slave

命令传播:master后续执行写入操作，将数据同步slave

8.哨兵机制Sentinel、哨兵原理

哨兵机制sentinel

哨兵概念：是redis的高可用性解决方案，由1个或多个sentinel实例构成的sentinel系统可监视多个主服务器，以及这些主服务器下的所有子服务器。

当被监视的主服务器下线时，自动将下线主服务器中的某个从服务器升级为新的主服务器。简单来说哨兵就是带有自动故障转移功能的主从架构。

哨兵是一个分布式系统，用于对主从结构中的每台服务器进行监控，当master出现故障时，选择新的master,并将所有slave连接到新的master

哨兵作用

监控：不断检查master和slave是否正常运行，master存活检测,master和slave运行情况检测

通知：当被监控的服务器出现问题时，向其他(哨兵、客户端)发送通知

自动故障转移：如果master宕机，断开master和slave的连接，从slave中选取一个作为新的master,将其他slave和新的master建立连接，并告知客户端新的master地址

注意：哨兵也是一台服务器，只是不提供服务。通常哨兵配置数量为单数。(避免选举master同票)

启动哨兵机制

配置多个哨兵：将redis中的sentinel.conf拷贝2份，在sentinel.conf中修改端口，以及设置master的端口地址，最后通过 redis-sentinel sentinel-端口号.conf即可启动哨兵

哨兵机制原理

主从切换：哨兵在主从切换中经历了监控、通知、故障转移 3个阶段。

监控阶段：启动哨兵服务之后，哨兵之间会互相监控，包括master及master下所有的slave节点信息。多个哨兵之间可相互通信，之间通过发布订阅来互相通知

通知阶段：哨兵之间相互通知，哨兵通知客户端

故障转移阶段：某个哨兵向master服务器发送指令，此时master没反应，也拿不到信息，哨兵意识到master宕机，将此消息告知另外2个哨兵，另外两哨兵也向master发送请求，也得不到响应，此时master确定下线，随后多个哨兵中会选出一个领头的哨兵将master清楚，并在slave中选出一个新的master，将slave切换为新的master

9.redis集群原理、缓存预热、缓存击穿、缓存穿透、缓存雪崩的解决方案

集群架构

集群架构概念

概念产生背景：业务发展过程中遇到的瓶颈。redis提供服务OPS可达到10万/S,当前业务ops已达到10万/s；内存单机容量为256G，当前业务需求内存容量为1T。使用集群可解决上述问题

集群：将同一个服务的多个节点放在一起，共同对系统提供服务的过程称为集群。换言之集群就是将若干台网络连接起来，并提供统一的管理方式，对外呈现单机的服务效果。

分布式：有多个不同服务集群共同对系统提供服务的系统称为分布式系统

集群架构作用：

分散单台服务器的访问压力，实现负载均衡

分散单台服务器的存储压力，实现可扩展性

降低单台服务宕机带来的宕机灾难

redis集群原理

所有redis节点彼此互联，通过二进制协议优化传输速度和带宽，每个redis节点都包含自己的master和slave,

集群中节点宕机是集群中超过半数的节点检测失效时才失效

客户端只需要连接集群中任意一个节点即可

客户端执行set命令时，会通过CRC16算法，计算出其哈希槽的位置，根据该位置存储到对应的node节点。执行get操作时，会根据哈希槽的位置，去指定节点内读取数据。

故障转移将宕机的master节点的哈希槽由选出来的slave来接管，不会新创建哈希槽

redis集群搭建

https://blog.csdn.net/m0_37989980/article/details/107778257 二

redis企业解决方案

缓存预热

定义：系统启动前，提前将相关的缓存数据直接加载到缓存系统，避免用户先查询数据库，再将数据缓存的问题！

解决问题：解决用户请求先查询数据库，再将数据缓存的问题

作用：用户直接查询事先被预热的缓存数据，加快查询速度

解决方案：

统计访问频率较高的热点数据，并将统计数据分类，根据级别排序，优先加载级别较高的热点数据，热点数据主从预热

脚本程序固定触发脚本预热

缓存雪崩

定义：同一时间大面积的缓存失效，后面的请求都会直接请求数据库，造成数据库短时间内接收大量请求而崩溃

后果：数据库服务器崩溃

原因：较短时间内，缓存中较多的key集中过期

解决方案(道)：

更多的页面静态化处理(模板+动态数据)、构建多级缓存架构、针对慢SQL进行执行计划分析，进而优化SQL、

限流降级短时间内牺牲用户体验，限制一部分请求，降低应用服务器压力，请求低速运转后再逐步放开访问

解决方案(术):

数据有效期策略调整，根据业务有效期进行分类错峰，过期时间使用固定时间+随机值的方式，稀释集中过期的key

超热数据使用永久key

缓存击穿

定义：缓存中没有但数据库中有的数据，一般是缓存时间到期，此时大量并发请求同一条数据，缓存中没有，查询数据库，从而造成数据库崩溃

原因：缓存中某一个热点key过期，该Key访问量巨大，多个请求都压在这个Keys上，但是均为命中，redis短时间内发起了大量对数据库中同一数据的访问

解决方案(术)：

设置热点数据永不过期、现场调整Key的过期时间、后台定时刷新热点key有效期

缓存穿透(布隆过滤器解决)

定义：缓存和数据库中都没有的数据，导致所有请求都落在数据库上，造成数据库短时间接到大量请求而崩掉

示例：例如数据库及缓存中的数据都是从id为0开始自增，有人恶意请求id=-1的数据，即缓存穿透

解决方案：

接口层增加校验，如用户鉴权校验，id基础校验，小于等于0的直接拦截

缓存和数据库中都没取到，可以设置为key-null,有效期短一点，30秒左右，可防止用户针对同一个key进行暴力攻击

使用布隆过滤器，判断请求的key是否存在

布隆过滤器：

定义：是一个很长的二进制向量(bit数组)和一系列哈希函数(hash),用于检索一个元素是否在一个集合中。

优点：因为基于位数组和哈希算法，空间效率和查询时间远超一般算法

缺点：有一定的误识别率和删除困难，但是可以通过增加位数组大小和hash函数来降低误识别率(无法避免)

添加数据过程：初始化之后，位数组中值都为0，当增加变量，会通过多个hash函数将元素映射到位数组中各个位上，将对应位置设置为1

查询数据过程：通过多个hash函数将元素映射到位数组中各个位上，如果各个位都是1，则元素可能存在，但如果其中有位不为1，则元素一定不存在

缓存降级

定义：流量骤增，造成响应速度较慢，可对非核心缓存业务进行降级

目的：保证核心服务可用。有些服务无法降级(如加入购物车、结算)

服务降级目的：防止redis故障，导致数据库一起发生雪崩问题，因此可对不重要的缓存数据，采用服务降级策略。

例如redis出现问题，不去数据库查询数据，而是直接返回默认值(兜底默认值)

10.布隆过滤器解决缓存穿透问题

人工智能学习网站：https://www.captainai.net/itcoke/

目的：redis实现布隆过滤器

使用场景：准确判断某个数据是否在大数据集合中，并且不占用内存

简介：一种数据结构，一串很长的二进制向量组成，可看作一个二进制数组，初始默认值都是0

添加数据：通过多个hash函数，计算出在二进制数组中的位置，将其设置为1

判断数据是否存在：将元素通过hash函数算出在二进制数组中的位置，看其是否为1，如果都为1则可能存在，否则一定不存在

优点：二进制数据，占用内存极少，插入和查询速度很快

缺点：随着数据增加，误判率增加；无法判断数据一定存在；无法删除数据

redis实现布隆过滤器：

在redis中，bitmaps提供了一套命令来操作类似字符串中的每一位(setbit、getbit、bitcount等)，因此redis实现布隆过滤器底层是通过bitmap数据结构。

Redission是在java中操作redis的库，因此可利用Redission来实现布隆过滤器，也可用guava来实现布隆过滤器