redis学习笔记

1.缓存中间件 memcache和redis的区别
Memcache：代码层次类似hash
支持简单数据类型
不支持数据持久化存储
不支持主从
不支持分片
Redis：数据类型丰富
支持数据磁盘持久化存储
支持主从同步
支持分片
2.为什么redis能这么快（100000+QPS，即每秒内查询次数）
完全基于内存，绝大部分请求是存粹的内存操作，执行效率高
数据结构简单，对数据操作也简单
主线程是单线程，单线程也能处理高并发请求，包括IO事件处理，以及io对应的相关业务事件的处理，对于客户端的所有请求都在一个线程窜行处理，如果有多个请求对一个key更改写操作的话，就不会有并发问题，避免了上下文切换和锁竞争消耗。想多核也可以启动多个实例（在实际测试中发现，redis支持的QPS相当高，并且在QPS峰值时cpu也没有被跑满，只是由于网络等原因导致并发处理量不能进一步上升，因此cpu并不是制约redis性能的瓶颈。。。所说的单线程只是在处理网络请求的时候只有一个单线程来处理，一个正式的redisServer在运行的时候，肯定不止一个线程，例如redis进行持久化的时候会根据实际情况以子进程或者子线程的方式执行）
使用多路I/O复用模型，非阻塞IO（redis是跑在单线程中的，操作都是按照顺序线性执行的，但是由于读写操作，等待用户输入或者输出都是阻塞的，所以IO操作在一般情况下往往不能直接返回，就会导致某一文件的IO阻塞，进而导致整个进程无法对其他客户端提供服务，而IO多路复用就是为了解决这个问题的）
3.FD：file descriptor文件描述符
在操作系统中，一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件的元数据到文件本身的映射，用一个整数来表示，用于指代被打开的文件，所有执行I/O操作的系统文件都通过描述符来调用
4.多路I/O复用模型
在I/O多路复用最重要的函数就是select系统调用，select能够监控多个FD的可读可写情况，当某些FD可读或者可写时，select方法就会返回可读以及可写的FD个数，也就是select负责监听文件是否可读或者可写的，将监听的任务交给select，程序就可以去做其他的事情，不会阻塞了
多路复用函数还有epoll kqueue evport select
5.redis采用的io多路复用函数
因地制宜。因为Redis需要在多个平台上运行，同时为了最大化的执行效率和性能，会根据编译平台的不同选择不同的io多路复用函数作为子模块，提供给上层统一的接口
redis优先选择时间复杂度为O(1)的io多路复用函数作为底层实现。Epoll-linux kqueue-bsd evport selec
以时间复杂度的为O(n)的select作为保底，因为select在不同版本上的操作系统上都能实现
基于react设计模式监听io事件
6.redis数据结构
string：最基本的数据类型，二进制安全，可以存储访问次数、图片、序列化对象等。String保存字符串对象的结构：
struct sdshdr{
int len； //buf中已占用空间的长度
int free； //buff剩余可用空间的长度
char buf；//数据空间
}
Hash：字典，string元素组成的字典，适合用于存储对象
List：列表，按照string元素插入顺序排序。可以用于最新消息排行榜，越早插入的消息越靠后，类似于栈结构
set：集合，string元素组成的无序集合，通过哈希表实现，不允许重复
sorted set：通过分数来为集合中的成员进行从小到大的排序，分数越小越往前排。sorted set是set加了一个分数，实现集合有序排列
hyperLogLog：用于计数
geo：用于支持存储地理位置信息
7.从海量key里查询出某一固定前缀的key
keys pattern：查找所有符合给定模式pattern的key（对内存消耗和redis服务器都是一个隐患，key过多会使服务器卡顿）
scan：scan 0 match k1* count 10
开始迭代返回前缀为k1的key，并且希望一次返回10条，0-表示开始迭代
8.如何通过redis实现分布式锁
set key value 【EX seconds】【PX milliseconds】【NX｜XX】
Java实现：
RedisService redisService = SpringUtils.getBean(RedisService.class);
String result = redisService.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE, expireTime)
if(“ok”.equals(result)){
//执行独占资源逻辑
}
9.大量的key同时过期的注意事项
集中过期，由于清楚大量的key很耗时，会出现短暂的卡顿现象。解决方案：在设置key的过期时间的时候，给每个key加上随机值
10.redis如何做持久化
RDB（快照）：保存某个时间点的全量数据快照。RDB配置：
redis.conf文件 -->
save 900 1 //900秒之内如果有一条写入指令，就触发产生一次快照
save 300 10 //300秒之内如果有10条写入，就触发一次快照，如果到300秒还没有10条，就等到900秒再触发一次快照
save 60 10000 //同等上面的asve
stop-writes-on-bgsave-error yes //当备份进程出错的时候，主进程就停止接受新的写入操作，是为了保护持久化一致性的问题
rdbcompression yes //在备份的时候需要将rdb文件进行压缩后保存，建议设置为no
save “” //禁用rdb的设置
11.rdb的dump.rdb文件的创建与载入
bgsave：fork出一个子进程来创建rdb文件，不阻塞服务进程。可以定时执行bgsave进行备份
12.自动化触发RDB持久化的方式
根据redis.conf配置里的SAVE m n 定时触发（用的是bgsave）
主从复制时，主节点自动触发
执行debug reload
执行shutdown且没有开启AOF持久化
cow模式：https://blog.csdn.net/lh87270202/article/details/106430154
13.AOF持久化：保存写状态
记录下除了查询以外的所有变更数据库状态的指令
以append的形式追加保存到AOF文件中（增量）
AOF持久化默认是关闭的，设置：
redis.conf文件 -->
appendonly yes //设置为yes就会生效了
appendfilename “appendonly.aof” //生成的文件名
appendfsync everysec //aof写入方式，有always（当缓存发生变化就及时写入aof中）、everysec（将缓存中的内容每隔1秒去写入到aof文件里面，默认）、no（将写入aof的操作交由系统决定）
重新登陆redis，执行config set appendonly yes就生效了
14.RDB-AOF混合持久化方式
bgsave做镜像全量持久化，AOF做增量持久化