循序渐进-Redis（2）

1 数据类型及使用场景

1. String
   这个其实没啥好说的，最常规的set/get操作，value可以是String也可以是数字。一般做*一些复杂的计数功能的缓存。**

2. list
   使用List的数据结构，可以做简单的消息队列的功能**。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。

3. set
   因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系统一般都是集群部署，使用JVM自带的Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。
   另外，就是利用交集、并集、差集等操作

4. sorted set

   sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。

5. hash
   这里value存放的是结构化的对象，比较方便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。

2 Redis为什么快

• 完全基于内存，CPU不是瓶颈
• 是单线程的，省去了上下文切换线程的时间，不用考虑各种锁的问题
• IO多路复用：单线程来轮询描述符，减少了线程切换时上下文的切换和竞争
• 非阻塞IO：在进行网络读写操作时，不需要等待操作完成才返回结果，而是立即返回状态，可以进行其他操作

3 IO多路复用

我们的redis-client在操作的时候，会产生具有不同事件类型的socket。

在服务端，有一段I/0多路复用程序，将其置入队列之中。然后，IO事件分派器，依次去队列中取，转发到不同的事件处理器中。

我自己理解就是：

1. 不同用户操作的时候会建立不同的socket。

2. 在服务端，主线程会fork出多个子线程，这多个线程会不断的将用户的请求添加到队列中。所以是多路复用。

3. 主线程在从队列中顺序取出请求交给事件处理器进行处理。

4. 在这其中，真正对用户进行操作的是主线程，子线程只是负责运输用户请求而已，所以在redis处理层面，确实是主线程完成的数据处理。子线程不算在内，所以是redis操作是单线程操作。

4 Redis 数据淘汰策略

Redis 使用了惰性删除（lazy expiration）和定期删除（定时任务）两种过期策略来处理过期的键值对

1. 惰性删除

   当一个键被访问时，Redis 会先检查该键是否过期，如果过期则会删除，否则正常返回值。这种策略保证了数据在被访问时才会被删除，避免了无效数据的占

   用。但是，由于是在访问时才判断是否过期，可能会导致过期键在一段时间内仍然保存在内存中。

2. 定期删除

   Redis 会定期地随机抽样一部分键，并检查它们是否过期，如果过期则删除。定期删除使用的是被动的方式，可能会导致大量的过期键堆积在内存中，直到进

   行下一次定期删除才会清除。

3. 混合方式

   定期删除，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

该配置就是配内存淘汰策略的(什么，你没配过？好好反省一下自己)

1. noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。
2. allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用。
3. allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。应该也没人用吧，你不删最少使用Key,去随机删。
4. volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把redis既当缓存，又做持久化存储的时候才用。不推荐
5. volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。依然不推荐
6. volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。不推荐

ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

6 Redis持久化方式

Redis提供了两种持久化方案：RDB和AOF。

1. RDB持久化

   RDB持久化是将当前内存中的数据生成一个快照并存储到磁盘上，当Redis重启时可以通过加载这

   个快照来恢复数据。RDB持久化的优点是备份和恢复速度快，适合大规模数据存储的场景；

   缺点：可能会丢失最后一次快照之后的数据，如果发生故障可能会导致数据丢失。

2. AOF持久化

   AOF持久化是将每个写操作追加到一个日志文件中，当Redis重启时可以通过重新执行这些操作来

   恢复数据。AOF持久化的优点是可以避免数据丢失，因为它记录了所有的写操作；

   缺点：备份和恢复速度相对较慢**，适合**小规模数据存储的场景。

3. 混合持久化

   从Redis4.0开始引入了RDB-AOF混合持久化模式，这种模式还是基于AOF模式构建的，需要的两个条件是：

   • 开启了AOF持久化功能
   • 设置 aof-use-rdb-preamble yes

   

   优点：

   1. 结合了 RDB 和 AOF 持久化的优点，开头为 RDB 格式，使得 Redis 可以跟快启动，同时结合 AOF 优点，降低了大量丢失数据的风险。

   缺点：

   1. AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件可读性变的更差。
   2. 兼容性差。混合持久化 AOF 文件，就不能用在 Redis 4.0 之前的版本了。