Redis知识梳理

Showne92

已于 2024-03-10 13:07:17 修改

阅读量1.2k

点赞数 30

文章标签： redis 数据库缓存

于 2024-02-17 20:27:45 首次发布

本文链接：https://blog.csdn.net/Showne92/article/details/136123112

版权

本文详细介绍了Redis的特性，如高性能数据类型、内存优化、线程模型、持久化策略、高可用性方案（主从复制、哨兵、cluster）以及淘汰策略。还探讨了Redis的优缺点和注意事项，包括Redis在不同场景下的应用实例和使用技巧。

摘要由CSDN通过智能技术生成

一、Redis简介

Redis是开源的、高性能的key-value数据库。

Redis数据类型包括：String、Hash、List、Set、Zset、Bitmap、Geospatial、HyperLogLog、Stream。

Bitmaps是Redis2.2.0版本新增的，即位图，是一串连续的二进制数组（0和1），可以通过偏移量（offset）定位元素。表示某个元素的值或者状态，时间复杂度为O(1)。由于bit是计算机中最小的单位，使用它进行存储将非常节省空间，特别适合一些数据量大且使用二值统计的场景。它的底层是基于String类型实现的。应用场景例如签到打卡，每一个用户一天的签到用一个bit位就能表示，一个月的签到情况用31个bit位，一年用366个bit位，不用复杂的集合类型就可以。

HyperLogLog是Redis在2.8.9版本添加的，用来做基数统计算法的数据结构。如统计网站的UV（Unique Vister-独立访客）。HLL是从Loglog算法派生的概率算法，用于确定非常大的集合的基数，而不需要存储其所有值。当然有小于0.81%的误差，但是对于UV统计来说可以忽略。简单来说，HyperLogLog提供不精确的去重计数。

GEO是Redis在3.2版本新增的，地理位置定位（底层使用zset实现），用于存储地理位置信息（经度、维度、名称），并对存储的信息进行操作。

Stream是5.0版本新增的数据类型，Redis专门为消息队列设计的数据类型。支持消息持久化、支持自动生成全局唯一ID、支持ack确认消息模式、支持消费组模式等，让消息队列更加稳定和可靠。

二、Redis快的原因

1、基于内存的实现。

Redis 是基于内存的一个数据库，内存读写速度非常快，数据存放在内存中，响应时间大约是100纳秒，这是Redis 每秒万亿级别访问的重要基础。

2、合理的线程模型。

2.1、Redis 是单线程。

避免CPU不必要的上下文切换和竞争锁的消耗。当然缺点就是如果某个命令执行时间过长（例如hgetall），会造成阻塞。Redis 是面向快速执行场景的数据库，所以要慎用smembers和lrange、hgetall等命令。

Redis 6.0引入多线程提速，不过它的执行命令操作内存仍然是个单线程。

2.2、I/O多路复用。

Redis使用epoll机制。

3、合理的数据编程。Redis支持多种数据类型。

String：若存储数字，使用int类型编码；若存储非数字，小于等于39字节的字符串使用embstr；大于39字节的用raw编码。

List：若列表的元素个数小于512个，列表每个元素的值都小于64字节（默认），使用ziplist编码，否则使用linkedlist编码。

Hash：哈希类型元素个数小于512个，所有值小于64字节的话，使用ziplist编码，否则使用hashtable编码。

Set：如集合中的元素都是整数且元素个数小于512个，使用intset编码，否则使用hashtable编码。

Zset：当有序集合的元素个数小于128个，每个元素的值小于64字节时，使用ziplist编码，否则使用skiplist（跳跃表）编码。

4、高效的数据结构。

SDS简单动态字符串、哈希、跳跃表skiplist、压缩列表ziplist。

5、虚拟内存机制。

Redis直接自己构建VM机制。暂时把不经常放的数据（冷数据）从内存交换到磁盘中，从而腾出宝贵的内存空间用于其他需要访问的数据（热数据）。通过VM功能可以实现冷热数据分离，使热数据仍在内存中，冷数据保存到磁盘中。

三、Redis优缺点

3.1、优点：

1、性能高。读速度是110000次/s，写速度是81000次/s。

2、原子性。所有操作都是原子性，且支持对多个操作合并后的原子执行。

3、丰富的数据类型。

4、丰富的特性。支持publish/subscribe、通知、key过期等等特性。

3.2、缺点：

1、受物理内存限制。可以通过集群模式弥补。

2、存在数据一致性问题。存在主从一致问题、缓存数据库一致性问题。解决主从一致性问题，可以使用分布式锁，Redisson提供multiLock方案解决主从一致性问题。解决缓存数据库一致性问题，可以在每次写操作时，更新缓存中数据。

3、在线扩容困难。Redis在集群容量达到上线时，在线扩容变得非常复杂，这限制了其他大规模数据处理场景的应用。

4、存在缓存穿透、击穿和雪崩问题。解决方案包括，使用布隆过滤器来预防缓存穿透、使用分布式锁来处理缓存击穿、错开缓存失效时间以避免缓存雪崩。

5、缺乏自动容错和恢复功能。增加哨兵自动恢复故障。

6、数据类型限制。Redis数据类型相对有限，不支持所有的数据类型，可能限制某些场景下的应用。

四、应用实例

我在网上找了一篇个人觉得很不错的博文，访问地址如下：【Redis从头学-13】Redis哨兵模式解析以及搭建指南_redis搭建哨兵模式-CSDN博客

五、pipeline和lua脚本

1、pipeline（管道）。

批量处理数据。一次性返回所有结果集，对这个结果集进行批量处理，考验处理结果集的能力。一个pipeline的命令集被redis服务器执行的时候，有可能redis服务器会执行其他客户端传来的redis命令。一些异常情况尽可能发生，所以说使用pipeline一般会做一些异常捕获和处理。因此事实上管道不具有原子性。管道更适用于管道中的命令之间没有关系，不需要事务的原子性，但需要提高程序响应速度的场景。

pipeline通过减少客户端与redis的通信次数来实现降低往返延时时间，而且pipeline实现的原理是队列，队列原理是先进先出，这样可以保证数据的顺序性。

通俗来讲，pipeline就是把一组命令打包，然后一次性通过网络发送到redis，同时将执行的结果批量返回。

2、lua脚本。

lua脚本会将多个命令和操作当成一个命令在redis中执行，即执行该脚本期间，不会被其他命令或者脚本打断。因此lua脚本具有原子性，可以替代multi和exec的事务功能。当然，也正因如此，不宜在lua脚本中进行过大开销操作，避免影响后续其他请求的正常执行。因此lua脚本适合于相对简单的事务场景。

lua脚本的好处如下：1) lua脚本作为一个整体执行，中间不会被打断，具有原子性。2）可以把多条命令一次性打包，可以减少网络开销。3）lua脚本可以常驻redis内存，使用时可以直接拿来复用，减少代码量。

六、Redis持久化方案及优缺点。

1、aof。

对每条写入命令进行日志记录。

优点：数据可靠，丢失较少；持久化过程代价较低。

缺点：aof文件过大，数据恢复慢。

2、rdb。

将某一时刻的内存快照，以二进制的方式写入磁盘。

优点：rdb文件小，数据恢复快。

缺点：数据丢失较多，持久化过程代价较高。

3、混合持久化。

rdb文件小加载快但丢失多，aof文件大加载慢但丢失少。混合持久化是吸收rdb和aof两者优点的一种持久化方案。aof-rewrite的时候实际持久化的内容是rdb，等持久化后，持久化期间修改的数据以aof的形式附加到文件的尾部。混合持久化实际上是在aof-rewrite基础上进行优化，所以需要先开启aof-rewrite。

七、高可用性方案

1、主从复制。可实现高并发（读），典型部署方案为一主二从。

2、哨兵模式。可实现高可用，典型部署方案为一主二从三哨兵。

3、cluster集群。可同时支持高可用（读和写）、高并发，典型部署方案为三主三从。

**redis高可用方案对比**
	redis主从复制	redis哨兵	redis集群
主要目的	数据备份与读写分离	高可用性和故障自动切换	高并发和数据分散处理
架构	一个主节点和多个从节点	监控主从结构并自动切换	多个主节点，数据分片
数据复制	主节点到从节点	监控并管理主从复制	每个主节点管理自己的数据集
故障转移机制	手动或哨兵自动切换	自动故障转移	自动处理节点故障
可伸缩性	有限，依赖主节点	为主从结构增加高可用性	高，因为数据分布式处理
使用场景	数据备份和读扩展	关键应用的高可用性	大规模应用的高性能需求
设置复杂度	相对简单	中等，需要配置哨兵	复杂，需要规划数据分区