Redis6-过期淘汰、经典数据类型的实现
一、redis的缓存过期淘汰策略
redis配置文件中有一个maxmemory，配置内存大小。默认是64位无限制，32位最大3GB。官网推荐配置是物理内存的四分之三。
查看redis内存使用情况，info memory：
1、如果超过了最大内存怎么办
当超过最大内存之后，设置的时候，会提示OOM，所以会出现内存淘汰策略（LRU）
redis的key当过期了之后，不一定会立刻删除，需要根据不同清情况分析。
redis的内存删除方式：
- 立刻删除：能够保证数据新鲜、内存空间释放，但是性能消耗很大
- 惰性删除：过期后方位第一次删除，对内存不友好，但是性能消耗低
- 定期删除：折中上面两个方式，定期清理过去数据，但是删除哪个数据、周期是多少需要确定
过期淘汰算法：
- LRU（最近最少使用）：优先淘汰最近未被使用的数据
- LFU（使用频率最少）：优先淘汰最近使用最少的数据
redis6的过期淘汰策略（8种）：
| 名称 | 策略的解释 |
| noeviction | 默认策略，不淘汰数据 |
| allKeys-lru | 所有key中，使用LRU算法（推荐） |
| allKeys-lfu | 所有key中，使用LFU算法 |
| allKeys-random | 所有key中，使用随机淘汰 |
| volatile-ttl | 设置过期key中，挑选出最早过期的key删除 |
| volatile-lru | 设置过期key中，使用LRU算法 |
| volatile-lfu | 设置过期key中，使用LFU算法 |
| volatile-random | 设置过期key中，使用随机淘汰 |
二、redis经典五种属类型及底层实现
redis可以理解为都是所有的都是字典，key是String、value是redisObject。使用type命令可以看到bitmap类型是stirng、hyperloglog类型是string、GEO类型是zset。所以redis底层数据结构还是经典的五种类型。
RedisObject、五种数据类型、底层实现的关系：
在redis中，每个键值对都会对应一个dictEntry，存放了指向key、value、下一个dictEntry的指针，key是字符串但是使用redis自定义的SDS存放，而value存放在redisObject中。
redisObject的结构：
- type：当前对象的数据类型
- encoding：当前对象底层存储的编码类型
- lru：采用LRU算法，记录对象最后访问的时间
- refcount：对象引用次数
- *ptr：指向真正底层数据结构的指针
2.1、String数据结构介绍
1、3大编码格式（为了精确的利用内存）
- int：保存long型有符号整数，长度最多19位。
- embstr：redis封装的格式SDS(简单动态字符)，超过long型&&长度小于44字节的字符串
- raw：redis封装的格式SDS(简单动态字符)，保存长度大于44字符串
2、编码格式案例
3、SDS简单动态字符串简介
redis为什么不直接用c语言的字符串，而是自己建立了一套结构SDS，不满意效率。
- c字符串获取长度，需要遍历char[]，时间复杂度是o(N)，SDS是o(1)
- 内存重新分配问题，c字符串是char[]数组，扩容、缩容不方便
- c字符串遇到'\0'就是结束，容易出现读取问题，二进制安全
SDS结构如下：
- len：已用字节长度
- alloc：字符串最大字节长度
- flags：用来博鳌是SDS的类型，SDS8、SDS16、SDS32、SDS64
- buf[]：真正的字符串
4、源码分析
Redis在启动的时候，会建立1万个0～9999的redisObject变量作为共享对象，这就意味着set字符串键在0～10000的时候，不需要建立对象直接使用共享对象。
embstr和raw不同的地方在于，embstr是内存连续的，raw是重新申请了一块内存，所以embstr会减少内存碎片的产生。还有一点，对embstr进行append，则会转换成raw。
2.2、Hash数据结构介绍
- hash-max-ziplist-entries：使用压缩表保存时，hash集合中最大元素个数
-
hash-max-ziplist-value：使用缩缩表保存时，hash集合中单个元素最大长度
通过上图可知，hash默认数据类型是压缩表，当集合个数太大或者元素长度太大的时候，才会使用hashtable进行保存。可以升级，无法降级。
综上所述，hash数据结构存在2种：ziplist、hashtbale（几乎等价java种的hashtable）
压缩表（ziplist）：双向链表，但是不存储指针
是一种紧凑的编码格式，压缩了数据，减少内存空间，但是需要压缩、解压写入、读取。也就是读写率换取空间。内存利用率极高的原因是连续的内存。所以当数据比较小的时候，使用压缩表最合适。
- header：
- zlbytes：所占内存字节数，用于重新分配和计算zlend
- zltail：尾节点到起始地址有多少字节
- zllen ：节点数量
- entry：节点
- 前一个节点长度：用这个字段和总长度，就能计算出每个节点的位置
- encoding
- entry-data
- zlend：0xff，用于标记压缩表的末端
优点：
- 普通列表存在2个指针，有些数据可能还么有指针大，所以优化掉了指针内存，通过长度推算位置
- 列表内存一般不连续，遍历速度慢，ziplist把相关偏移量记录在节点中，可以跳到上一个或下一个节点
- 列表长度不在遍历，时间复杂度是O(1)
HashTbale：OBJ_ENCODING_HT是哈希表机构或者称为字典结构
2.3、List数据结构介绍
在低版本（3.2之前）的Redis中，list采用底层的数据结构是ziplist+linkedlist，而高版本的Redis中list的底层数据结构是quicklist，而quicklist也用到了ziplist。
quicklist是ziplist和linkedlist的混合体，他将linkedlist按段切分，每一段使用ziplist来紧凑存储，多个ziplist使用双向指针串起来。
- list-compress-depth：1表示quicklist两端各有一个节点不压缩，中间节点压缩
- list-max-ziplist-size：-1表示quicklist每个节点上的ziplist大小不能超过4K
2.4、Set数据结构介绍
redis中用intset和hashset存储set，如果元素都是整型，就使用intset。否则使用hashset（数组+链表），其中key是元素，value是null。
2.5、ZSet数据结构介绍
Redis中使用ziplist和skiplist（跳表）来实现ZSet，当元素不满速上面的情况，就使用ziplist否则使用skiplist。
跳跃表（skiplist）：
由于普通的链表无法进行二分查找，因此借鉴数据库的索引思想，提取出链表中关键节点（索引），现在关键节点上查找，在进入下层链表查找。提取多层关键节点，就形成了skiplist。所以跳表=链表+多级索引（索引的索引），也就是给链表怎加索引，用空间换时间。
优化为，两两取首：
主要就是用多级索引能够快速查找，但是为什么是两两取首？既然决定了用空间，那么就让器粒度最低。
针对读多写少的情景，优点是查询块，缺点是浪费空间。
2.6、小结
