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做增量持久化
