Redis缓存

最新推荐文章于 2024-09-14 14:26:32 发布

理所当然的石家庄人

最新推荐文章于 2024-09-14 14:26:32 发布

阅读量759

点赞数 16

分类专栏：数据库文章标签：缓存 redis 数据库笔记

本文链接：https://blog.csdn.net/weixin_52407519/article/details/140037548

版权

数据库专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Redis是单线程还是多线程

Reds6.0版本之前的单线程指的是其网络I/O和键值对读写是由一个线程完成的

Rds6.0引入的多线程指的是 网络请求过程采用了多线程，而 键值对读写命令仍然是单线程处埋的，所以Redis依然是并发安全的也就是只有网络请求模块和数据操作模块是单线程的，而其它的持久化、集群数据同出等，其实是由额外的线程执行的

Redis单线程为什么会这么快

1、命令护行基于内存操作，一条命令在内存里操作的时间是几十纳秒

2、命令执行是 单线程操作，没有线程切换开销

3、起于 IO 多路复用机制提升Redis的I/O利用率

4、高效的数据存储结构：全同hash表以及多种高效数据结构，比如：跳表，压缩列表，链表等等

全局hash表

底层数据存储结构

String类型

bitmap（位图）专题

什么是bitmap

bitmap是以bit为单位的图，也可以说是数组，每一个元素存储的值只能是1|0 ，但实际也会String类型，还不过可以用对bit为单位操作元素

根据 key - offset - value的形式建立存储

key:整个bitmap的键值

offset：偏移量也是索引

应用场景

海量用户系统的日活/周活统计

统计某用户某时间段内的签到情况

连续登录用户统计

海量用户会员判断
判断是否状态的记录，如签到

为什么用bitmap实现签到业务？

因为bitmap实际就是bit数组，通过redis的上层String数据类型对每个bit进行操作，其中int的存储是4个字节（32bit），而bitmap的位数存储范围是2^32。
如果使用mysql存储，那就是一个用户在某一天的签到记录对应这表中的一条记录，当数据量不断扩充时，这个消耗量是不可预估的，再加上高并发场景会打垮mysql。
使用bitmap，刚好1int（4byte）= 32bit，一个月最多有31天，只需1int就可储存该用户一个月的签到数据。加上缓存的高存取效率，bitmap是最适合的数据结构。

Hash类型

hash类型与map的相似性

map：Map<String,Map<Object,Object>> 所谓的大map

应用场景

用于缓存常更新数据，尤其是需要修改里面的属性，存储java对象

Set类型

先更新数据库，再删缓存

如果想实现基础的缓存数据库双写一致的逻辑，那么在大多数情况下，在不想做过多设计，增加太大工作量的情况下，请 先更新数据库，再删缓存!

更新策略

三大更新策略

更新策略应用场景

删除策略

立即删除：对CPU不友好，用处理器性能换取存储空间（拿时间换空间）
惰性删除：对memory不友好，用存储空间换取处理器性能（拿空间换时间）
定期删除：定期抽样key，判断是否过期

使用这些策略的原因：为使redis在内存和cpu之间平衡，使得redis的性能最大化

定时删除：使用定时器一直对TTL进行检测，一旦定时器的时间数值与存储的时间时间数值相同，直接删除。
- 由于惰性刚除策略无法保证冷数据被及时删掉，所以Redis会定期（默认每100ms主动淘汰一批已过明的key，这里的一批只是部分过期key，所以可能会出凯部分key已经过期但还没有被清理掉的情况，导致内存并没有被释放
- 缺点：对CPU消耗大优点：节约内存，以时间换空间
惰性删除：空间换时间方案
- 当读写一个已经过期的key时，会触发惰性删除策略，判断key是否过期，如果过期了直接刚除掉这个key
定期删除：周期性轮询redis库的时效性数据，采取随机抽取策略（推荐使用）
- 优点:
  - 能根据CPU的性能设置有峰值，检测频度可自定义
  - 对内存压力不大，长期占用内存的冷数据会被持续清理

缓存淘汰策略

其中，volatile前缀代表从设置了过期时间的键中淘汰数据，allkeys前缀代表从所有的键中淘汰数据.关于后缀，tl代表选择过期时间最小的键，random代表随机选择键，需要我们额外关注的是Iru和lfu后缀，它们分别代表采用Iru算法和lfu算法来淘汰数据。

LRU(Least Recently Used) 是按照最近最少使用原则来筛选数据，即最不常用的数据会被筛选出来!

标准LRU:把所有的数据组成一个链表，表头和表尾分别表示MRU和LRU端，即最常使用端和最少使用端。刚被访问的数据会被移动到MRU端，而新增的数据也是刚被访问的数据，也会被移动到MRU端。当链表的空间被占满时，它会删除LRU端的数据。
近似LRU: Redis会记录每个数据的最近一次访问的时间戳(LRU)。Redis执行写入操作时，若发现内存超出maxmemory，就会执行一次近似LRU淘汰算法。近似LRU会随机采样N个key，然后淘汰掉最旧的key，若淘汰后内存依然超出限制，则继续采样淘汰。可以通过maxmemory_samples配置项，设置近似LRU每次采样的数据个数，该配置项的默认值为5

LRU算法的不足之处在于，若一个key很少被访问，只是刚刚偶尔被访问了一次，则它就被认为是热点数据，短时间内不会被淘汰。

LFU算法正式用于解决上述问题，LFU (Least Frequently Used) 是Redis4新增的淘汰策略，它根据key的最近访问频率进行淘汰。LFU在LRU的基础上，为每个数据增加了一个计数器，来统计这个数据的访问次数。当使用LFU策略淘汰数据时，首先会根据数据的访问次数进行筛选，把访问次数最低的数据淘汰出内存。如果两个数据的访问次数相同，LFU再比较这两个数据的访问时间，把访问时间更早的数据淘汰出内存