一文带你穿针引线Redis（2）

一文带你穿针引线Redis

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 之前的版本了。

7 Redis 事务

redis的事务是一个单独隔离的操作，它会将一系列指令按需排队并顺序执行，期间不会被其他客户端的指令插队。

1 三大指令：

1. mutil：开启事务
2. exec：执行事务
3. discard：取消事务

127.0.0.1:6379> set name1 zhangsan
QUEUED
127.0.0.1:6379> set name2 lisi
QUEUED
127.0.0.1:6379> exec
\1) OK
\2) OK
127.0.0.1:6379> get name1
"zhangsan"
127.0.0.1:6379> get name2
"lisi"

2 事务的错误与回滚

​ 事物的错误与回滚分别有组队时错误和执行命令时错误两种情况

1 组队时错误

​ 我们在组队时输入错误的指令，redis会之间将所有指令都会失效。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name1 zhangsan
QUEUED
127.0.0.1:6379> set name2 lisi
QUEUED
127.0.0.1:6379> set name3
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> set name4 wangwu
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get name1
(nil)
127.0.0.1:6379> get name2
(nil)
127.0.0.1:6379> get name3
(nil)
127.0.0.1:6379> get name4
(nil)

2 执行时错误

​ 他在按序处理所有指令，遇到错误就按正常流程处理继续执行下去。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name1 zhangsan
QUEUED
127.0.0.1:6379> incr name1
QUEUED
127.0.0.1:6379> set name2 lisi
QUEUED
127.0.0.1:6379> exec
\1) OK
\2) (error) ERR value is not an integer or out of range
\3) OK
127.0.0.1:6379> get name1
"zhangsan"
127.0.0.1:6379> get name2
"lisi"

8 Redis的乐观锁

Redis就是通过CAS(check and set)/Compare and Swap实现乐观锁的，通过watch指令监听一个或者多个key值，当用户提交修改key值的事务时，会检查监听的key是否发生变化。若没有发生变化，则提交成功。

CAS（Compare and Swap）是一种乐观锁机制，经常在并发控制中使用，以确保数据的一致性。下面是一种使用Redis实现CAS操作的例子，以一个简单的计数器为例：

目标：多个并发客户端尝试增加名为counter的整数计数器。

步骤：

1. WATCH命令
   客户端使用WATCH命令监视counter键，以便在事务执行前检查它是否被其他客户端修改。

   WATCH counter
   

   这将使得客户端在事务执行前监视counter键，如果该键被其他客户端修改，事务将被取消。

2. MULTI命令
   使用MULTI命令开启一个Redis事务。

   MULTI
   

   这个命令表示开始一个事务，之后的所有命令将被添加到事务队列中，不会立即执行，直到EXEC命令被调用。

3. 读取旧值
   在事务中，客户端读取counter的当前值，作为旧值。

   GET counter
   

   如果此时counter的值是5，那么客户端获取到的旧值就是5。

4. 计算新值
   客户端在本地计算出新的计数器值，例如将旧值加1。

   old_value = 5
   new_value = old_value + 1  # 新值为6
   

5. 尝试更新
   客户端将计算得到的新值放入SET命令中，准备执行CAS操作。

   SET counter new_value
   

   这个命令将在事务中设置counter的新值为6。

6. EXEC命令
   使用EXEC命令提交事务。如果在WATCH和EXEC之间被监视的counter键没有被其他客户端修改，事务将成功执行，新值将被写入counter。

   EXEC
   

• WATCH counter监视counter，确保在事务期间没有其他客户端修改它。
• MULTI开始事务。
• GET counter再次检查counter的当前值，确保在事务开始前没有其他客户端修改。
• SET counter new_value尝试更新counter的值。
• EXEC提交事务。如果counter在WATCH与EXEC之间未被修改，更新将成功，否则事务将失败。

结果：

• 成功：如果counter在CAS操作期间未被其他客户端修改，该操作会成功，counter将更新为新值（例如6）。
• 失败：如果counter在CAS操作期间被其他客户端修改，该操作会失败。此时，客户端可以选择重试整个流程或采取其他措施。

通过这种方式，即使多个客户端并发尝试修改counter，每次只有一个客户端可以成功。这确保了counter的数据一致性和并发安全性。