1 数据类型及使用场景
-
String
这个其实没啥好说的,最常规的set/get操作,value可以是String也可以是数字。一般做*一些复杂的计数功能的缓存。** -
list
使用List的数据结构,可以做简单的消息队列的功能**。另外还有一个就是,可以利用lrange命令,做基于redis的分页功能,性能极佳,用户体验好。 -
set
因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重?因为我们的系统一般都是集群部署,使用JVM自带的Set,比较麻烦,难道为了一个做一个全局去重,再起一个公共服务,太麻烦了。
另外,就是利用交集、并集、差集等操作 -
sorted set
sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用,取TOP N操作。
-
hash
这里value存放的是结构化的对象,比较方便的就是操作其中的某个字段。博主在做单点登录的时候,就是用这种数据结构存储用户信息,以cookieId作为key,设置30分钟为缓存过期时间,能很好的模拟出类似session的效果。
2 Redis为什么快
- 完全基于内存,CPU不是瓶颈
- 是单线程的,省去了上下文切换线程的时间,不用考虑各种锁的问题
- IO多路复用:单线程来轮询描述符,减少了线程切换时上下文的切换和竞争
- 非阻塞IO:在进行网络读写操作时,不需要等待操作完成才返回结果,而是立即返回状态,可以进行其他操作
3 IO多路复用
我们的redis-client在操作的时候,会产生具有不同事件类型的socket。
在服务端,有一段I/0多路复用程序,将其置入队列之中。然后,IO事件分派器,依次去队列中取,转发到不同的事件处理器中。
我自己理解就是:
-
不同用户操作的时候会建立不同的socket。
-
在服务端,主线程会fork出多个子线程,这多个线程会不断的将用户的请求添加到队列中。所以是多路复用。
-
主线程在从队列中顺序取出请求交给事件处理器进行处理。
-
在这其中,真正对用户进行操作的是主线程,子线程只是负责运输用户请求而已,所以在redis处理层面,确实是主线程完成的数据处理。子线程不算在内,所以是redis操作是单线程操作。
4 Redis 数据淘汰策略
Redis 使用了惰性删除(lazy expiration)和定期删除(定时任务)两种过期策略来处理过期的键值对
-
惰性删除
当一个键被访问时,Redis 会先检查该键是否过期,如果过期则会删除,否则正常返回值。这种策略保证了数据在被访问时才会被删除,避免了无效数据的占
用。但是,由于是在访问时才判断是否过期,可能会导致过期键在一段时间内仍然保存在内存中。
-
定期删除
Redis 会定期地随机抽样一部分键,并检查它们是否过期,如果过期则删除。定期删除使用的是被动的方式,可能会导致大量的过期键堆积在内存中,直到进
行下一次定期删除才会清除。
-
混合方式
定期删除,redis默认每个100ms检查,是否有过期的key,有过期key则删除。需要说明的是,redis不是每个100ms将所有的key检查一次,而是随机抽取进行检查(如果每隔100ms,全部key进行检查,redis岂不是卡死)。因此,如果只采用定期删除策略,会导致很多key到时间没有删除。
于是,惰性删除派上用场。也就是说在你获取某个key的时候,redis会检查一下,这个key如果设置了过期时间那么是否过期了?如果过期了此时就会删除。
如果定期删除没删除key。然后你也没及时去请求key,也就是说惰性删除也没生效。这样,redis的内存会越来越高。那么就应该采用内存淘汰机制⬇⬇⬇。
5 Redis 内存淘汰机制
在redis.conf中有一行配置
# maxmemory-policy allkeys-lru
该配置就是配内存淘汰策略的(什么,你没配过?好好反省一下自己)
- noeviction:当内存不足以容纳新写入数据时,新写入操作会报错。应该没人用吧。
- allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的key。推荐使用。
- allkeys-random:当内存不足以容纳新写入数据时,在键空间中,随机移除某个key。应该也没人用吧,你不删最少使用Key,去随机删。
- volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用的key。这种情况一般是把redis既当缓存,又做持久化存储的时候才用。不推荐
- volatile-random:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个key。依然不推荐
- volatile-ttl:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,有更早过期时间的key优先移除。不推荐
ps:如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。
6 Redis持久化方式
Redis提供了两种持久化方案:RDB和AOF。
-
RDB持久化
RDB持久化是将当前内存中的数据生成一个快照并存储到磁盘上,当Redis重启时可以通过加载这
个快照来恢复数据。RDB持久化的优点是备份和恢复速度快,适合大规模数据存储的场景;
缺点:可能会丢失最后一次快照之后的数据,如果发生故障可能会导致数据丢失。
-
AOF持久化
AOF持久化是将每个写操作追加到一个日志文件中,当Redis重启时可以通过重新执行这些操作来
恢复数据。AOF持久化的优点是可以避免数据丢失,因为它记录了所有的写操作;
缺点:备份和恢复速度相对较慢**,适合**小规模数据存储的场景。
-
混合持久化
从Redis4.0开始引入了RDB-AOF混合持久化模式,这种模式还是基于AOF模式构建的,需要的两个条件是:
- 开启了AOF持久化功能
- 设置 aof-use-rdb-preamble yes
优点:
- 结合了 RDB 和 AOF 持久化的优点,开头为 RDB 格式,使得 Redis 可以跟快启动,同时结合 AOF 优点,降低了大量丢失数据的风险。
缺点:
- AOF 文件中添加了 RDB 格式的内容,使得 AOF 文件可读性变的更差。
- 兼容性差。混合持久化 AOF 文件,就不能用在 Redis 4.0 之前的版本了。