一：Redis的常见数据类型有哪些
Redis 是典型的 “ 键值型 ” 数据库，不同数据类型其 key 结构一致， value 有所差异。
常见的类型有： string、hash、list、set、SortedSet 等。
而基于以上 5 种基本数据类型， Redis 又拓展了几种拓展类型，例如： BitMap、
HyperLogLog、Geo 等。
String 类型是 Redis 中最常见的数据类型， value 与 key 一样都是 Redis 自定义的
字符串结构，称为 SDS 。不过在保存数字、小字符串时因为采用 INT 和
EMBSTR 编码，内存结构紧凑，只需要申请一次内存分配，效率更高，更节省
内存。
而超过 44 字节的大字符串时则需要采用 RAW 编码，申请额外的 SDS 空间，需
要两次内存分配，效率较低，内存占用也较高，但最大不超过 512mb ，因此
建议单个 value 尽量不要超过 44 字节。
String 类型常用来做计数器、简单数据存储等。复杂数据建议采用其它数据结
构。
Hash 结构，其 value 与 Java 中的 HashMap 类似，有是一个 key-value 结构。如果
有一个对象需要被 Redis 缓存，而且将来可能有部分修改。建议用 hash 结构来
存储这个对象的每一个字段和字段值。而不是作为一个 JSON 字符串存储到
String 类型中。因为 Hash 结构的每一个字段都可以单独做修改，而 String 的
JSON 串必须整体覆盖。 与 Java 中的 hashMap 不同的是， Redis 中的 Hash 底层采用了渐进式 rehash 的算法，在做rehash 时会创建一个新的 hashtable ，每次操作元素时移动一部分数
据，只到所有数据迁移完成，再用新的 HashTable 来代替旧的，避免了因为
rehash 导致的阻塞，因此性能更高。
List 结构的 value 类型可以看做是一个双端链表，提供了一些命令便于我们从
首尾操作元素。为了节省内存空间，底层采用了 ZipList （压缩列表）来做基
础存储。当压缩列表数据达到阈值（ 512 ）则会创建新的压缩列表。每个压缩
列表作为一个双端链表的一个节点，最终形成一个 QuickList 结构。而且
QuickList 结构与一般的双端链表不同，他可以对中间不常用的 ZipList 节点做
压缩以节省内存。
List 结构常用来模拟队列，实现任务排队这样的功能。
Set 结构的 value 与 Java 的 Set 类似，元素不可重复。 Redis 提供了求交集、并集
等命令，可以帮助我们实现例如：好友列表、共同好友等功能。
当存储元素是整数时，其底层默认采用 IntSet 结构，可以看做是一个有序的数
组，结构紧凑，效率较高。而元素如果不是整数，或者元素量超过 512 这个阈
值时则会转为 hash 表结构，内存占用会有大的增加。因此我们在使用 Set 结构
时尽量采用数组存储，例如数值类型的 id 。而且元素数量尽量不要超过 512 ，
避免出现 BigKey 。
SortedSet ，也叫 ZSet 。其 value 就是一个有序的 Set 集合，元素唯一，并且会按
照一个指定的 score 值排序。因此常用来做排行榜功能。
SortedSet 底层的利用 Hash 表保证元素的唯一性。利用跳表（ SkipList ）来保证
元素的有序性，因此数据会有重复存储，内存占用较高，是一种典型的以空
间换时间的设计。不建议在 SortedSet 中放入过多数据。
二：跳表是什么
跳表 (SkipList) 首先是链表，但与传统的链表相比有几点差异：
1.跳表结合了链表和二分查找的思想
2.元素按照升序排列存储
3.节点可能包含多个指针，指针跨度不同 查找时从顶层向下，不断缩小搜索范围
整个查询的复杂度为 O ( log n )
Redis数据类型Sorted Set使用了跳表作为其中一种数据结构
三：Redis的持久化策略有哪些
在 Redis 中提供了两种数据持久化的方式： 1 、 RDB 2 、 AOF
RDB ：
定期更新，定期将 Redis 中的数据生成的快照同步到磁盘等介质上，磁盘上保存的就是Redis 的内存快照
优点：数据文件的大小相比于 aop 较小，使用 rdb 进行数据恢复速度较快
缺点：比较耗时，存在丢失数据的风险
AOF ：
将 Redis 所执行过的所有指令都记录下来，在下次 Redis 重启时，只需要执行指令就可以了
优点：数据丢失的风险大大降低了
缺点：数据文件的大小相比于 rdb 较大，使用 aop 文件进行数据恢复的时候速度较慢
四：Redis的集群方案有哪些
在 Redis 中提供的集群方案总共有三种：
1.主从复制
1.保证高可用性
2.实现故障转移需要手动实现
3.无法实现海量数据存储
2、哨兵模式
1.保证高可用性
2.可以实现自动化的故障转移
3.无法实现海量数据存储
3.分片集群
1.保证高可用性
2.可以实现自动化的故障转移
3.可以实现海量数据存储
五：什么是缓存穿透，怎么解决
指查询一个一定 不存在 的数据，如果从存储层查不到数据则不写入缓存，
这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。
解决方案
1 、查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短
2 、布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一 定不存在的数据会被这个 bitmap 拦截掉，从而避免了对 DB 的查询
六：什么是缓存击穿，怎么解决
对于设置了过期时间的 key ，缓存在某个时间点过期的时候，恰好这时间点对这个Key 有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。
解决方案
1 、使用互斥锁：当缓存失效时，不立即去 load db ，先使用如 Redis 的 setnx 去设置一个互斥锁，当操作成功返回时再进行 load db 的操作并回设缓存，否则重试get 缓存的方法
2 、可以设置当前 key 逻辑过期，大概是思路如下：
① ：在设置 key 的时候，设置一个过期时间字段一块存入缓存中，不给当前 key设置过期时间
② ：当查询的时候，从 redis 取出数据后判断时间是否过期
③ ：如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据，这
个数据不是最新
两种方案的对比
七：什么是缓存雪崩，怎么解决
设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB ， DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多 key， 击穿是某一个key 缓存
解决方案
将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
八：Redis分布式锁如何实现
Redis 实现分布式锁主要利用 Redis 的 setnx 命令。 setnx 是 SET if not exists( 如果不
存在，则 SET)的简写。
加锁 ：使用 setnx key value 命令，如果 key 不存在，设置 value( 加锁成功 ) 。如果已经存在lock( 也就是有客户端持有锁了 ) ，则设置失败 ( 加锁失败 ) 。
解锁 ：使用 del 命令，通过删除键值释放锁。释放锁之后，其他客户端可以通过 setnx 命令进行加锁。
九：Redis的数据过期策略有哪些
数据删除策略： Redis 中可以对数据设置数据的有效时间，数据的有效时间到了以后，就需要将数据从内存中删除掉。而删除的时候就需要按照指定的规则进行删除，这种删除规则就被称之为数据的删除策略
1.惰性删除
概述：设置该 key 过期时间后，我们不去管它，当需要该 key 时，我们在检查其是
否过期，如果过期，我们就删掉它，反之返回该 key 。
优点：对 CPU 友好，我们只会在使用该键时才会进行过期检查，对于很多用不到的key 不用浪费时间进行过期检查。
缺点：对内存不友好，如果一个键已经过期，但是一直没有使用，那么该键就会一直存在内存中，如果数据库中有很多这种使用不到的过期键，这些键便永远不会被删除，内存永远不会释放。
2.定期删除
概述：每隔一段时间，我们就对一些 key 进行检查，删除里面过期的 key( 从一定数量的数据库中取出一定数量的随机键进行检查，并删除其中的过期键) 。
优点：可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。
缺点：难以确定删除操作执行的时长和频率。 如果执行的太频繁，定期删除策略变得和定时删除策略一样，对 CPU 不友好。
如果执行的太少，那又和惰性删除一样了，过期键占用的内存不会及时得到释放。
另外最重要的是，在获取某个键时，如果某个键的过期时间已经到了，但是还没执行定期删除，那么就会返回这个键的值，这是业务不能忍受的错误。
定期清理的两种模式：
SLOW 模式是定时任务，执行频率默认为 10hz ，每次不超过 25ms ，以通过修
改配置文件 redis.conf 的 hz 选项来调整这个次数
FAST 模式执行频率不固定，每次事件循环会尝试执行，但两次间隔不低于
2ms ，每次耗时不超过 1ms
十：Redis是单线程的，为什么还是那么快
Redis 总体快的原因：
1 、完全基于内存的， C 语言编写
2 、采用单线程，避免不必要的上下文切换可竞争条件
3 、数据简单，数据操作也相对简单 4 、使用多路 I/O 复用模型，非阻塞 IO bgsave 在 后台 执行 rdb 的保存，不影响主线程的正常使用，不会产生阻塞 bgrewriteaof 在 后台 执行 aof 文件的保存，不影响主线程的正常使用，不会产 生阻塞
