redis面经总结

String 还是 Hash 存储对象数据更好呢： 如果对象经常修改，则用hash。

redis单线程：执行命令单线程，IO多路复用，对大键值对的删除命令采用异步处理。

为什么不用多线程：1.性能瓶颈不在CPU 2.单线程实现简单 3.单线程不存在死锁，上下文切换问题

redis6.0之后为什么引入多线程：提高网络io读写能力

Redis 是如何判断数据是否过期： 过期字典（hash表）

删除策略：惰性删除：取出key时检查   定期删除：每隔一段时间抽出一批检查

内存淘汰机制：1.从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使⽤的数据淘汰 2.当内存不⾜以容纳新写⼊数据时，在键空间中，移除最近最少使⽤的 key（这个是最常⽤的）

持久化：

　　RDB:快照，可以同步也可以异步

　　AOF:追加日志，三种持久化方式：1.每次有数据修改发⽣时都会写⼊AOF⽂件,这样会严重降低Redis的速度 2.每秒钟同步⼀次，显式地将多个写命令同步到硬盘 

　　AOF重写：在执⾏ BGREWRITEAOF 命令时，Redis 服务器会维护⼀个 AOF 重写缓冲区，该缓冲区会在⼦进程创建新 AOF ⽂件期间，记录服务器执⾏的所有写命令。当⼦进程完成创建新 AOF ⽂件的⼯作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF ⽂件的末尾，使得新的 AOF ⽂件保存的数据库状态与现有的数据库状态⼀致。最后，服务器⽤新的 AOF ⽂件替换旧的 AOF ⽂件，以此来完成 AOF ⽂件重写操作。

　　RDB 和 AOF 的混合持久化：AOF 重写的时候就直接把 RDB 的内容写到 AOF ⽂件开头，快速加载同时避免丢失过多的数据

 

缓存穿透：⼤量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上

　　解决办法：1.先做好参数校验 2.缓存无效ley 3.布隆过滤器

缓存雪崩：缓存在同⼀时间⼤⾯积的失效，后⾯的请求都直接落到了数据库上，造成数据库短时间内承受⼤量请求

　　解决办法：1.设置随机过期时间 2.缓存永不过期 3.限流 4.redis集群

 

数据结构：

　　String：动态字符串，每次扩容为当前长度两倍

　　list：初始为压缩列表，在内存中顺序相连，使用所占长度代替指针，省空间，但是增删改效率低，当存入长字符串或者列表长度到达阈值后，转为双向链表。

　　hash:压缩列表与字典。

　　zset:跳表，因为是有序链表，所以可以优化。