循序渐进-Redis-汇总

循序渐进-Redis

1 定位Redis

Redis（Remote Dictionary Server）是一个开源的内存数据库（C语言编写的），非关系型数据库（key-value存储系统），属于键值对存储系统。它提供了高性能、持久化、分布式、多种数据结构的支持。默认端口号(6379)

1 特点

• 内存数据库：Redis将所有数据存储在内存中，因此能够实现非常高的读写速度。
• 持久化：Redis支持两种持久化方式，分别是RDB快照和AOF日志，可以保证数据在服务重启后不会丢失。
• 多种数据结构：除了基本的字符串，Redis支持诸如列表、集合、哈希表等多种数据结构，使得其可以应用于广泛的场景。
• 原子性操作：Redis中的所有操作都是原子性的，保证了多个客户端同时对Redis进行操作时的数据一致性。
• 分布式：Redis支持主从复制、分片等分布式特性，可以通过搭建集群来处理大规模数据。
• 高性能：由于数据存储在内存中，Redis能够实现非常高的读写速度，特别适用于缓存场景。

2 实际应用

• 缓存：Redis最常见的应用就是作为缓存系统，可以将频繁访问的数据存储在Redis中，从而减轻数据库的压力，提升网站性能。
• 会话存储：可以将用户的会话信息存储在Redis中，保证了用户登录状态的持久性和高效性。
• 计数器：可以用Redis的INCR和DECR操作来实现计数器功能，例如网站的访问量统计。
• 消息队列：Redis的列表数据结构可以用来实现简单的消息队列，用于解耦生产者和消费者。
• 实时分析：可以利用Redis的数据结构和高性能进行实时统计和分析，例如排行榜、统计信息等。

3 Redis的现世缘

Web1.0的时代，数据访问量很有限，用一夫当关的高性能的单点服务器可以解决大部分问题。

随着Web2.0的时代的到来，用户访问量大幅度提升，同时产生了大量的用户数据。加上后来的智能移动设备的普及，所有的互联网平台都面临了巨大的性能挑战。

1 解决cpu及内存压力

2 解决IO压力

NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，泛指非关系型的数据库。

NoSQL 不依赖业务逻辑方式存储，而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。

1. 不遵循SQL标准。
2. 不支持ACID。
3. 远超于SQL的性能。
4. 对数据高并发的读写
5. 海量数据的读写
6. 对数据高可扩展性的。

所以出现了内存数据库，如redis，memcache、mongoDB等。

4 扩展🌟内存-CPU-IO

1. 内存（RAM）：
   • 数据存储和访问：内存是应用程序存储数据的主要场所，它允许快速读写操作。在开发中，合理使用内存可以加快数据的访问速度，从而提高应用程序的性能。
   • 内存管理：开发者需要谨慎管理内存，避免内存泄漏和浪费。内存泄漏可能导致应用程序的内存消耗不断增加，最终导致性能下降。
   • 缓存：内存中的数据缓存对于性能至关重要。开发者可以使用缓存来存储频繁访问的数据，减少对磁盘或网络的访问，提高响应速度。
2. CPU（中央处理器）：
   • 代码优化：编写高效的代码对于CPU性能至关重要。开发者应该选择合适的算法和数据结构，并避免不必要的计算来减少CPU负载。
   • 并行计算：多核心处理器已经成为标配，开发者可以通过并行计算来充分利用多核心，加速应用程序。这需要使用多线程或并发编程技术。
   • CPU缓存：了解CPU缓存的工作原理，可以帮助开发者编写更高效的代码，减少缓存未命中，提高性能。
3. I/O（输入/输出）：
   • 异步和非阻塞操作：在I/O操作中，阻塞操作会降低应用程序的性能。开发者可以使用异步和非阻塞技术，使应用程序能够继续执行其他任务而不必等待I/O操作完成。
   • 批处理：减少I/O操作的次数，将多个小的I/O请求合并成一个较大的请求，可以减少I/O的开销，提高性能。
   • 缓存和预读：使用适当的缓存策略以及预读技术可以减少对磁盘或网络的频繁访问，从而提高I/O性能。

2 数据类型及使用场景

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的效果。

3 Redis为什么快

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

4 IO多路复用

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

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

我自己理解就是：

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

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

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

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

5 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的内存会越来越高。那么就应该采用内存淘汰机制⬇⬇⬇。

6 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(不删除) 基本上一致。

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

8 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"

9 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的数据一致性和并发安全性。

10 Redis的hahs槽

Redis哈希槽是Redis集群的核心概念之一。在Redis集群中，数据会被分布在不同的节点上，而哈希槽则是用来划分数据所在节点的逻辑单位。哈希槽的数量是固定的，Redis默认将其划分为16384个槽位。

当一个新的节点加入Redis集群时，集群会将部分哈希槽从已有节点上迁移至新节点上，直到集群中所有节点的哈希槽数量都比较平均。当有数据需要存储时，Redis会根据数据的键值对应的哈希值，将其映射到一个哈希槽中，并根据哈希槽的分布情况，将数据存储到相应的节点上。哈希槽的使用使得Redis集群可以更加高效地进行数据存储和访问，同时还能够实现数据的分布式存储和负载均衡。

11 Redis是否支持事务? redis操作是否是原子操作？

🌟Redis 支持事务。Redis 的事务是通过 MULTI/EXEC 命令来实现的。

可以使用 MULTI 命令来开始一个事务，然后在事务中执行多个命令，最后通过 EXEC 命令来执行这些命令并将结果返回。

事务可以保证在执行期间不会被其他客户端的命令所打断

🌟Redis 的操作是原子的，Redis 中的每个命令都是原子执行的，要么全部执行成功，要么全部失败，中间不会被其他命令所影响。

但是要注意的是**，在使用 Redis 事务时，事务中的多个命令并不保证原子性，只有在执行 EXEC 命令后才会被作为一个原子操作来执行**。

12 Redis开发中使用流程

1 基本流程

2 Redis分布式缓存、分布式锁、布隆过滤器基本流程

✨✨Redis做分布式缓存存在的问题、缓存击穿、缓存穿透、缓存雪崩、数据一致性问题见之前的文章：一窥：分布式、分布式缓存、分布式锁及其延申_NIIMP的博客-CSDN博客

13 Redis主从复制

单节点Redis的并发能力是有限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。在Redis中，集群中的Redis实例多是以主从关系存在。通常只有一个主机，多个从机。那么Redis为什么要做成这种主从的集群？而不是负载均衡的集群呢？这是因为Redis中一般都是读操作多于写操作。主机（master）负责写操作，从机（slave）负责读操作，这样大大的提高的Redis的读写性能。

14 开发中Redis加了分布式锁为啥还需要使用lua保持原子性?

🌟防止多个线程获取到同一个分布式锁而导致数据不一致

在使用 Redis 的分布式锁时，通常会将锁的获取和释放操作分别作为两个 Redis 命令执行。

但是，这种方式可能存在并发问题，因为在执行获取锁和释放锁的两个命令之间，其他线程或进程可能会获取到同一个锁而导致竞争条件。

为了解决这个问题，可以使用 Redis 的 Lua 脚本来确保获取和释放锁的操作是原子性的。Lua 脚本是 Redis 内置的脚本语言，并且在执行期间会被 Redis 以单线

程的方式执行，因此可以保证在脚本执行期间不会被其他操作打断。

假设有两个线程A和B同时执行一段代码，并且这段代码需要获取一个名为"counter"的锁来对一个计数器进行操作。代码如下所示：

lock.acquire()  # 获取锁
# 临界区
counter += 1
lock.release()  # 释放锁

线程A执行到lock.acquire()时获取到了锁，并且进入了临界区，执行counter += 1。但是在执行lock.release()之前，线程调度器可能会切换到线程B上，

此时线程B也执行到了lock.acquire()。

如果不处理竞争条件，线程B也能够获取到同一个锁，并且进入临界区修改计数器。然后线程A继续执行lock.release()来释放锁，接着线程B也执行

lock.release()来释放锁。

这样一来，计数器只增加了1，而不是2。因为在两个线程之间没有保证同步，它们对于共享资源的修改发生了竞争。

为了解决这个问题，可以使用锁机制来确保在同一时间只有一个线程可以访问临界区。当一个线程获取到锁后，其他线程将被阻塞，直到该线程释放锁。这样可以

保证每个线程在执行临界区代码时是互斥的，避免了竞争条件的出现。