1、Redis特点
1、Redis是一个高性能且基于内存的数据库，所有的数据形式都是以键值对的方式来存储的
2、Redis支持丰富的数据类型，例如string,list,set,sorted set,hash，这些类型指的是键值对中的值的类型
3、Redis支持持久化
4、Redis单线程,单进程，由于是单线程和单进程的，所以它的线程是安全的。2、Redis持久化机制
Redis提供了两种快照持久化机制：第一种方式是RDB持久化，官方说法叫快照持久化，也是redis的默认的持久化方式，这种方式可以将某一时刻的所有数据都写入硬盘中。
它的快照生成方式有两种，一种是服务器配置自动触发，还有一种是在客户端使用BGSAVE或SAVE手动创建快照。更推荐使用BGSAVE来创建快照，因为BGSAVE相对于SAVE来说可以在创建快照的同时，还能同一时刻处理用户的请求。第二种方式是AOF持久化，这种方式可以将所有客户端执行的写命令记录到日志文件中,AOF持久化会将被执行的写命令写到AOF的文件末尾,以此来记录数据发生的变化,因此只要redis从头到尾执行一次AOF文件所包含的所有写命令,就可以恢复AOF文件的记录的数据集.3、AOF文件的重写
redis7.0之前：
在7.0之前，只有一个aof文件，触发重写机制时，旧的aof文件经过重写产生一个新的aof文件，同时也会生成一个临时文件去存放在重写期间内的用户请求，之后再将临时文件追加到新的aof文件中去替换旧的aof文件。从redis7.0开始，除了aof文件，还有rdb快照文件以及rdb的校验文件，触发重写机制时，会产生一个临时文件，旧的aof文件和旧的rdb文件会向临时文件中写数据，写完之后临时文件进行重写产生一个新的rdb快照文件替换旧的rdb文件，同时也会生成一个新的aof文件去存储重写期间内的用户请求。4、Redis主从复制
主从复制架构是用来解决数据备份的问题,从节点仅仅用来同步数据
5、Redis哨兵机制
哨兵机制是Redis的高可用性解决方案，由一个或多个Sentinel实例组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，当主服务器发生故障时，会将从服务器升级为新的主服务器。简单的说哨兵就是带有自动故障转移功能的主从架构。无法解决: 1.单节点并发压力问题 2.单节点内存和磁盘物理上限 通俗来说就是无法解决负载均衡问题。6、穿透、雪崩、击穿
缓存穿透
产生的原因：请求根本不存在的资源
举例：当大量的客户端发送大量的不可响应的请求 ，就可能导致出现缓存穿透的情况。因为数据库DB中本身就没有该请求的数据，所以Redis也没有对应的数据，那么这些请求在redis就得不到响应，就会直接打在DB(业务数据库)上，导致DB压力过大而卡死情景在线或宕机解决方法：
(1)对空值进行缓存类似于上面的例子，虽然数据库中没有该请求的数据，但是在redis中对他进行缓存（key=xxx，value=null），这样当请求到达redis的时候就会直接返回一个null的值给客户端，避免了大量无法访问的数据直接打在DB上。(2)实时监控对redis进行实时监控，当发现redis中的命中率下降的时候进行原因的排查，配合运维人员对访问对象和访问数据进行分析查询，从而进行黑名单的设置限制服务。(3)使用Boolean过滤器使用BitMap作为布隆过滤器，将目前所有可以访问到的资源通过简单的映射关系放入到布隆过滤器中（哈希计算），当一个请求来临的时候先进行布隆过滤器的判断，如果有那么才进行放行，否则就直接拦截。(4)接口校验类似于用户权限的拦截，对于无效访问就直接拦截，不允许这些请求到达Redis、DB上。缓存雪崩
产生的原因：redis中大量的key集体过期举例：当redis中的大量key集体过期，可以理解为redis中的大部分数据都被清空了（失效了），那么这时候如果有大量并发的请求来到，那么redis就无法进行有效的响应（命中率急剧下降），请求就都打到DB上了，到时DB直接崩溃。解决方法：
1. 使用互斥锁（Mutex Lock）或分布式锁，只允许一个请求去访问后端数据源，其他请求等待并共享结果。（推荐使用）
2. 将失效时间分散开, 通过使用自动生成随机数使得key的过期时间是随机的，防止集体过期
3. 使用多级架构,使用nginx缓存+redis缓存+其他缓存，不同层使用不同的缓存，可靠性更强
4. 设置缓存标记,记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际的key
5. 设置热点数据的永远不过期或过期时间较长，以减少热点数据失效的机会。缓存击穿
产生的原因：redis中的某个热点key过期，但是此时有大量的用户访问该过期key。举例：某个热搜很火，这时候大家都在访问该热点事件，但是可能由于某种原因，redis的这个热点key过期了，那么这时候大量高并发对于该key的请求就得不到redis的响应，那么就会将请求直接打在DB服务器上，导致整个DB瘫痪。解决方案：
1. 为缓存数据设置不同的过期时间，使其在不同时间点过期，避免集中失效。监控数据，适时调整，监控哪些数据是热门数据，实时的调整key的过期时长
2. 引入两级缓存架构，例如使用本地缓存（如Guava Cache）作为第一级缓存，并设置较短的过期时间，Redis作为第二级缓存，并设置较长的过期时间。
3. 针对热点数据，可以提前进行预加载，保证其缓存不会在同一时间全部失效。
)
