本文主要是介绍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分离
相关指令
数据库操作指令：
启动redis，默认16个库(编号从0至15)，select 编号 选择指定库
清空当前库：FLUSHDB
清空全部库：FLUSHALL
客户端显示中文：./redis-cli -p 700 --raw
操作key相关指令：
DEL KEY[KEY...] 删除单个或多个Key，返回删除数量，不存在的key忽略
EXISTS KEY;判断key是否存在,存在返回1，否则返回0
EXPIRE KEY seconds;为key设置生存时间,秒为单位，生存时间为0自动删除。成功返回1
KEYS PATTERN;查找符合pattern的key
MOVE KEY DB;将Key移动到指定db中
PEXPIRE KEY milliseconds;为key设置生存时间，毫秒为单位。成功返回1，否则返回0
PEXPIREAT KEY milliseconds-timestap;为Key设置生存时间，以毫秒为单位设置过期的时间戳
TTL KEY ;以秒为单位，返回指定key的剩余存活时间
PTTL KEY ;以毫秒为单位，返回指定key的剩余存活时间
RANDOMKEY;随机返回一个key
RENAME KEY NEWKEY;将Key命名修改为newkey
TYPE KEY ;返回KEY对应VALUE的类型。none(key不存在),string,list(列表),set(集合),zset(有序集合),hash(哈希表)
5种数据类型
String:基础存储类型，在redis中二进制安全，存入和取出数据相同，最大容纳数据长度512M。
常用命令：
set key value;例如：set company "sunny";key存在则进行覆盖，返回 OK
get key;返回key对应的值
del key;删除 key
哈希类型-hash：适合存储值对象信息，value是一个键值对，key 无序
常用命令
hset key field value 为指定key设置field/value键值对。给同一个field设置，后者会覆盖前者
hmset key1 field/value key2 field/value 为多个key设定field/value
hget key field 返回指定Key中field的值
hmget key field1 field2 field3 返回指定Key中多个field的值
hdel key field [field … ] 删除1个或多个字段，返回被删除字段的个数
hgetall key 获取Key的所有数据
列表类型-list：有序可重复，类似双端队列的数据结构，可作为redis实现消息队列的数据结构
常用命令：
lpush key values[value1 value2…] 在指定key关联的list头部添加这些元素，如果key不存在，则新建元素。添加成功，返回元素个数
lpop key 返回key关联链表的头部元素
rpop key 从尾部弹出元素
lrange key start end 输出该key的所有数据。示例：lrange key 0 10;输出key对应list的索引0至索引10的数据，即前11个元素
列表类型-set(无序且不可重复)
常用命令：
sadd key values[value1、value2…] 向key对应set中添加数据
smembers key 显示key对应set中所有数据
srem key members[member1、member2…] 删除key对应set中指定数据
有序列表类型-zset(sortedSet,可排序，可保证不重复)，value中的每个元素都会关联一个double类型的份数，redis中正式通过分数来为元素实现从小到大的排序
特点：可排序的set集合，相当于java中的treeSet
常用命令：
zadd key values[value1、value2…] 向key对应set添加元素
zrange key start end 通过索引区间返回指定范围内的元素，升序
zrevrange key start end 通过索引区间返回指定范围内的元素，降序
zrange key start end [withscores] 通过索引区间返回指定范围内的元素及其对应score数字，升序
zrevrange key start end [withscores] 通过索引区间返回指定范围内的元素及其对应score数字，降序
redis通用命令
key pattern ;pattern表示格式，作用是获取与pattern匹配的Key。* 表示任意1个或多个字符，?表示任意1个字符
exists key ；判断key是否存在，存在返回1 否则返回0
type key ;返回key对应的value数据类型。none、string、list、set、zset、hash
expire key time;设置key的存活时间
3种特殊数据类型
Hyperloglog 基数统计算法，类似于set数据类型，允许容错，使用此类型。不允许容错使用set即可
Bitmap 位存储，操作二进制位来记录。
Geospatial 地理位置
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来实现布隆过滤器
这篇关于Redis及其他缓存的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
