Redis相关知识

redis相关知识总结

1、什么是redis?

Redis是一个高性能的key-value型数据库，开源免费，是为了解决高并发、高扩展，大数据存储等一系列的问题而产生的数据库解决方案，是一个非关系型的数据库。

Redis 是一种基于内存的数据库，对数据的读写操作都是在内存中完成，因此读写速度非常快，常用于缓存，消息队列、分布式锁等场景。

Redis 提供了多种数据类型来支持不同的业务场景，比如:

• 字符串（String）：最基本的数据结构，可以存储字符串、整数或浮点数。

• 列表（List）：有序的字符串列表，可以在列表的头部或尾部插入、删除元素，还可以根据索引获取元素。

• 哈希（Hash）：键值对的无序散列表，适用于存储对象。

• 集合（Set）：无序的字符串集合，可以添加、删除和判断元素是否存在。

• 有序集合（Sorted Set）：有序的字符串集合，每个元素都关联着一个分数，可以根据分数进行排序。

• 位图（Bitmap）：可以进行位级别的操作，适用于存储和处理二进制数据。

• HyperLogLog：用于基数统计的数据结构，可以估计集合中的唯一元素数量。

• 地理空间索引（Geospatial Index）：用于存储和查询地理位置信息的数据结构。

这些数据结构可以通过Redis提供的命令进行操作和管理，每种数据结构都有对应的命令集合。选择合适的数据结构可以更高效地存储和处理数据，适应不同的应用场景。

除此之外，Redis 还支持事务 、持久化、Lua 脚本、多种集群方案（主从复制模式、哨兵模式、切片机群模式）、发布/订阅模式，内存淘汰机制、过期删除机制等等。

2. redis为什么快？

官方使用基准测试的结果是，单线程的 Redis 吞吐量可以达到 10W/每秒

之所以 Redis 采用单线程（网络 I/O 和执行命令）那么快，有如下几个原因：

• Redis 的大部分操作都在内存中完成，并且采用了高效的数据结构，因此 Redis 瓶颈可能是机器的内存或者网络带宽，而并非 CPU，既然 CPU 不是瓶颈，那么自然就采用单线程的解决方案了；
• Redis 采用单线程模型可以避免了多线程之间的竞争，省去了多线程切换带来的时间和性能上的开销，而且也不会导致死锁问题。
• Redis 采用了 I/O 多路复用机制处理大量的客户端 Socket 请求，IO 多路复用机制是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听 Socket 和已连接 Socket。内核会一直监听这些 Socket 上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。

3. redis的缺点

Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

4. redis适用于的场景?

Redis最适合所有数据in-momory的场景，如：

• 4.1 会话缓存（Session Cache）

最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。

• 4.2 全页缓存（FPC）

除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。

• 4.3 队列

Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。

如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。

• 4.4 排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：

当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。

• 4.5 发布/订阅

最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。

5. Redis如何做持久化的？

Redis 的读写操作都是在内存中，当 Redis 重启后，内存中的数据就会丢失，为了保证内存中的数据不会丢失，Redis 实现了数据持久化的机制，将数据存储到磁盘，Redis 重启能够从磁盘中恢复原有的数据。

• Redis 共有两种数据持久化的方式：

AOF 日志：每执行一条写操作命令，就把该命令以追加的方式写入到一个文件里；
RDB 快照：将某一时刻的内存数据，以二进制的方式写入磁盘；

RDB快照做镜像全量持久化，aof做增量持久化。因为RDB快照会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要aof来配合使用。在redis实例重启时，会使用RDB快照持久化文件重新构建内存，再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。

• 如果突然机器掉电会怎样?

取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

• bgsave的原理是什么？

fork和cow。fork是指redis通过创建子进程来进行bgsave操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

6. redis缓存穿透、缓存击穿、缓存雪崩是什么？怎么解决？

缓存雪崩

当大量缓存数据在同一时间过期或者 Redis 故障宕机时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力增加，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃。

解决方法

• 大量数据同时过期

1. 均匀设置过期时间：避免将大量的数据设置成同一个过期时间。
   互斥锁：当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存。未能获取互斥锁的请求等待锁释放后重新读取缓存，或者返回空值或者默认值。
2. 双key策略：使用两个key，一个是主key，设置过期时间，一个是备key，不会设置过期，key不一样，但是value值是一样。当业务线程访问不到主key的缓存数据时，就直接返回备key的缓存数据，然后在更新缓存的时候，同时更新主key和备key的数据。
3. 后台更新缓存：业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新。
   Redis故障宕机
4. 服务熔断或请求限流机制：启动服务熔断机制，暂停业务应用对缓存服务的访问，直接返回错误，所以不用再继续访问数据库，保证数据库系统的正常运行，等到 Redis 恢复正常后，再允许业务应用访问缓存服务。服务熔断机制是保护数据库的正常允许，但是暂停了业务应用访问缓存服系统，全部业务都无法正常工作。也可以启用请求限流机制，只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务。
   构建高可靠集群：通过主从节点的方式构建 Redis 缓存高可靠集群。如果 Redis 缓存的主节点故障宕机，从节点可以切换成为主节点，继续提供缓存服务，避免了由于 Redis 故障宕机而导致的缓存雪崩问题。

缓存击穿

如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮。

解决方案：

• 互斥锁方案：保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。
  不给热点数据设置过期时间：由后台异步更新缓存，或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间。

缓存穿透

当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。

解决方案

• 非法请求的限制：当有大量恶意请求访问不存在的数据的时候会发生缓存穿透，可以在 API 入口处判断求请求参数是否合理，请求参数是否含有非法值、请求字段是否存在，如果判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。
• 缓存空值或者默认值：当线上业务发现缓存穿透的现象时，可以针对查询的数据，在缓存中设置一个空值或者默认值，这样后续请求就可以从缓存中读取到空值或者默认值，返回给应用，而不会继续查询数据库。
• 使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在：可以在写入数据库数据时，使用布隆过滤器做个标记，然后在用户请求到来时，业务线程确认缓存失效后，可以通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在。

7. Redis的同步机制？

Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

8. Redis主从同步常见性能问题和解决方案

8.1 Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照

8.2 Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久

化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。

8.3 Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。

8.4 Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。

9. redis的缓存失效策略和主键失效机制

作为缓存系统都要定期清理无效数据，就需要一个主键失效和淘汰策略.

在Redis当中，有生存期的key被称为volatile。在创建缓存时，要为给定的key设置生存期，当key过期的时候（生存期为0），它可能会被删除。

1、影响生存时间的一些操作

生存时间可以通过使用 DEL 命令来删除整个 key 来移除，或者被 SET 和 GETSET 命令覆盖原来的数据，也就是说，修改key对应的value和使用另外相同的key和value来覆盖以后，当前数据的生存时间不同。

比如说，对一个 key 执行INCR命令，对一个列表进行LPUSH命令，或者对一个哈希表执行HSET命令，这类操作都不会修改 key 本身的生存时间。另一方面，如果使用RENAME对一个 key 进行改名，那么改名后的 key的生存时间和改名前一样。

RENAME命令的另一种可能是，尝试将一个带生存时间的 key 改名成另一个带生存时间的 another_key ，这时旧的 another_key (以及它的生存时间)会被删除，然后旧的 key 会改名为 another_key ，因此，新的 another_key 的生存时间也和原本的 key 一样。使用PERSIST命令可以在不删除 key 的情况下，移除 key 的生存时间，让 key 重新成为一个persistent key 。

2、如何更新生存时间

可以对一个已经带有生存时间的 key 执行EXPIRE命令，新指定的生存时间会取代旧的生存时间。过期时间的精度已经被控制在1ms之内，主键失效的时间复杂度是O（1），
EXPIRE和TTL命令搭配使用，TTL可以查看key的当前生存时间。设置成功返回 1；当 key 不存在或者不能为 key 设置生存时间时，返回 0 。

最大缓存配置 在 redis 中，允许用户设置最大使用内存大小 server.maxmemory 默认为0，没有指定最大缓存，如果有新的数据添加，超过最大内存，则会使redis崩溃，所以一定要设置。redis 内存数据集大小上升到一定大小的时候，就会实行数据淘汰策略。redis 提供 6种数据淘汰策略：

• volatile-lru： 从已设置过期时间的数据集（ server.db[i].expires）中挑选最近最少使用的数据淘汰

• volatile-ttl： 从已设置过期时间的数据集（ server.db[i].expires）中挑选将要过期的数据淘汰

• volatile-random： 从已设置过期时间的数据集（ server.db[i].expires）中任意选择数据淘汰

• allkeys-lru： 从数据集（ server.db[i].dict）中挑选最近最少使用的数据淘汰

• allkeys-random： 从数据集（ server.db[i].dict）中任意选择数据淘汰

• no-enviction（驱逐）： 禁止驱逐数据

注意这里的6种机制，volatile和allkeys规定了是对已设置过期时间的数据集淘汰数据还是从全部数据集淘汰数据，后面的lru、ttl以及random是三种不同的淘汰策略，再加上一种no-enviction永不回收的策略。

使用策略规则：

• 如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用allkeys-lru
• 如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用allkeys-random

三种数据淘汰策略：

ttl和random比较容易理解，实现也会比较简单。主要是Lru最近最少使用淘汰策略，设计上会对key 按失效时间排序，然后取最先失效的key进行淘汰

10. 怎么用redis分布式锁？

基于 Redis 节点实现分布式锁时，对于加锁操作，我们需要满足三个条件。

加锁包括了读取锁变量、检查锁变量值和设置锁变量值三个操作，但需要以原子操作的方式完成，所以，我们使用 SET 命令带上 NX 选项来实现加锁；
锁变量需要设置过期时间，以免客户端拿到锁后发生异常，导致锁一直无法释放，所以，我们在 SET 命令执行时加上 EX/PX 选项，设置其过期时间；
锁变量的值需要能区分来自不同客户端的加锁操作，以免在释放锁时，出现误释放操作，所以，我们使用 SET 命令设置锁变量值时，每个客户端设置的值是一个唯一值，用于标识客户端；

满足这三个条件的分布式命令如下：

SET lock_key unique_value NX PX 10000

• lock_key 就是 key 键；
• unique_value 是客户端生成的唯一的标识，区分来自不同客户端的锁操作；
• NX 代表只在 lock_key 不存在时，才对 lock_key 进行设置操作；
• PX 10000 表示设置 lock_key 的过期时间为 10s，这是为了避免客户端发生异常而无法释放锁。

而解锁的过程就是将 lock_key 键删除（del lock_key），但不能乱删，要保证执行操作的客户端就是加锁的客户端。所以，解锁的时候，我们要先判断锁的 unique_value 是否为加锁客户端，是的话，才将 lock_key 键删除。

可以看到，解锁是有两个操作，这时就需要 Lua 脚本来保证解锁的原子性，因为 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，保证了锁释放操作的原子性。

// 释放锁时，先比较 unique_value 是否相等，避免锁的误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

这样一来，就通过使用 SET 命令和 Lua 脚本在 Redis 单节点上完成了分布式锁的加锁和解锁。

11. Redis分布式锁操作

先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。

如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？

set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的。

12. Redis怎么节省内存?

• 1、清除过期key

一般来说，Redis中的key都有一个过期时间（TTL），当一个key到达了过期时间后，Redis会自动把它删除掉。如果切实情况下发现过期key很少被清理，可以通过手动扫描和清理的方式解决该问题。可以通过手动执行DEL 命令或者设置自动定时清理已标记为过期的键值对。

• 2、开启压缩机制

开启Redis的压缩机制是减少内存占用的一种有效方式。 开启后，数据将被压缩后存储，Redis就可以使用更小的空间来存储相同数量的数据。但是，在压缩数据时使用CPU势必会带来一定的系统负荷。因此，在开启前应该进行全面评估。

• 3、启用LRU算法

大规模使用设置 Redis 的 maxmemory 属性最好开启 LRU 超出时删除策略，以确保 Redis 服务器不会无限添加项目并从而导致内存耗尽。Redis可以根据“最近最少的访问时间”（Least Recently Used）算法，删除过时的、很久没有使用过的键值对。同时，redis还提供上下文相关的LRU算法（Comte-Tournier），不同于简单的链表实现。

• 4、对键值进行优化

Redis目前支持五种数据类型：字符串，列表，哈希表，集合和有序集合。在使用这些类型时，我们可以采取以下措施来优化内存：

字符串(String)类型：使用整数或布尔值代替字符串，可以显著降低内存占用。

列表(List)类型：对于含有大量重复元素的列表，可以使用Redis List压缩来降低其内存消耗。

哈希表(Hash)类型：如果key-value 对数量很少，这种类型的空间效率非常低。尽量避免在哈希表里使用一些”tiny keys”。

集合(Set)类型：使用基数估计法(BloomFilter)等技术来节约空间。

有序集合(Sorted Set)类型: 针对只存储分数（score）但是成员(member)本身很小的功能需求，可以通过配置Redis启用ziplist和small ziplist。

• 5、分割数据库

将数据拆分多个数据库，各自独立运行，从而有效地分散每个数据库的负载，减少数据库内存压力。在使用多个数据库时，必须小心控制它们的大小并注意细节处理，以免耗尽可用资源。

• 6、使用Redis集群

当单台 Redis 服务器无法满足业务需求或者需要提高死活性和升级能力时，可以考虑将其扩展到Redis集群中。通过搭建分布式集群，即使其中一台主机发生崩溃或停机，整个系统也可以保证数据的完整性和可用性。此外，集群模式下每个节点暴露出的单独的内存限制，还可以更好地控制内存占用情况。

• 7、随时了解Redis内存使用情况

Redis提供命令、日志等多种方法来随时查看内存使用情况，并进行相关调整。理解Redis内存特性是优化Redis内存使用的前提条件，同时还应该综合考虑当前硬件配置、业务需求及实际情况等因素。

总之，由于Redis完全基于内存操作，因此它的内存越大，对服务器的要求就越高。为了避免性能问题和故障，我们必须采取一系列措施来降低Redis的内存使用率。在实际运行过程中，根据业务特点、数据类型和目标等因素，可以采取上述措施或他们的组合来进一步优化Redis的内存使用效率。