Redis

what_2018

已于 2023-07-27 15:39:04 修改

阅读量252

点赞数

分类专栏：缓存组件（redis、elasticsearch）文章标签： redis 数据库缓存

于 2023-07-26 10:04:58 首次发布

本文链接：https://blog.csdn.net/qq_24426227/article/details/131932134

版权

缓存组件（redis、elasticsearch）专栏收录该内容

1 篇文章 0 订阅

订阅专栏

介绍

Redis 服务器默认端口 6379，可以支持6W+ 小数据可以达到10W的并发。tps可以达到10w+

Rdeis 锁的续期 ,业务执行时间过长 watch dog。

redis是内存数据结构存储，可用作数据库、缓存、消息代理和流引擎。

提供的数据结构有：String、hash、lists、sets、sorted sets、bitmaps、hyperloglogs、streams

字符串、哈希、列表、集、带有范围查询的排序集、位图、超日志日志、地理空间索引和流。

Redis 具有内置复制、Lua 脚本、LRU 逐出、事务和不同级别的磁盘持久性，并通过 Redis Sentinel 和 Redis 集群的自动分区提供高可用性。

具体使用参考： Introduction to Redis | Redis

总结

类型	简介	特性	场景
String(字符串)	二进制安全动态字符串SDS O(1)	可以包含任何数据,比如jpg图片或者序列化的对象,一个键最大能存储512M	Token；「计数器、验证码、用户信息json、分布式锁 setnx」
Hash(字典)	键值对集合,即编程语言中的Map类型	适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值(Memcached中需要取出整个字符串反序列化成对象修改完再序列化存回去)	存储、读取、修改用户属性
List(列表)	链表(双向链表)	增删快,提供了操作某一段元素的API	1,最新消息排行等功能(比如朋友圈的时间线) 2,消息队列历史作业查询最近记录实现「阻塞队列」 lpush + lpop = stack 先进后出的栈 lpush + rpop = queue 先进先出的队列
Set(集合)	哈希表实现,元素不重复	1、添加、删除,查找的复杂度都是O(1) 2、为集合提供了求交集、并集、差集等操作	1、共同好友 2、利用唯一性,统计访问网站的所有独立ip 3、好友推荐时,根据tag求交集,大于某个阈值就可以推荐去重、抽奖
Sorted Set(有序集合)	将Set中的元素增加一个权重参数score,元素按score有序排列	数据插入集合时,已经进行天然排序数据少使用ziplist; 数据多时使用字典+跳表(主要zskiplist(链表）和zskiplistNode (节点)组成)	排行榜带权重的消息队列打印量排行榜，首页推荐10个最热门的帖子 1.延时队列 2.限流(滑动窗口) Zrevrangebyscore通过分数score排名，从高到低。 zrangebyscore 通过分数score排名，从低到高
bitmap		存储的是连续的二进制数(0 和 1)；保存状态信息：是否签到、是否登录、活跃用户情况; 只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身。我们知道 8 个 bit 可以组成一个 byte，所以 bitmap 本身会极大的节省储存空间。
HyperLogLog [ˈhaɪpə(r)]		概率数据结构，用于对独特事物进行计数。可以非常省内存的去统计各种计数，比如注册的 ip 数，每日访问 ip 数，在线用户数等
GEO 是地理空间		地理空间位置（比如经度、维度、名称等）添加到指定的 key中，这些数据将会存储到 zsets 里面。时间复杂度：每一个元素添加是O(log(N)) ，N是sorted set的元素数量

Redis 为什么可以抗高并发？

首先，Redis使用内存存储数据，避免了磁盘I/O的开销，提高了数据访问的速度。其次，Redis拥有丰富的对象类型，包含八种类型，满足不同的需求。此外，Redis采用了高效的数据结构，减少了内存占用和计算复杂度。Redis还使用单线程模型，避免了多线程之间的上下文切换和竞争条件，提升了CPU利用率。最后，Redis使用非阻塞I/O多路复用机制(多路复用IO模型实际也是传统阻塞型IO模型演化而来的)，充分利用CPU和网络资源，提高了并发处理能力。

首先Redis为什么选择单线程的实现方式：

从Redis自身特性来说，Redis是基于内存的数据库，所以数据处理速度非常快。另外它的底层使用了很多效率很高的数据结构，如哈希表和跳表等。另外Redis从狭义上面来说他是单线程的，网络请求解析与数据读写都是由主线程完成。因此它内部就省去了很多多线程访问共享数据资源的繁琐设计，同时也避免了频繁的线程上下文切换因此减少了多线程的系统开销。

Redis 为什么可以抗高并发。

其次从IO模型角度来说，Redis使用的是IO多路复用模型，使得它可以在网络IO操作并发处理数十万的客户端网络连接，实现非常高的网络吞吐率。这也是Redis可以实现高并发访问的最主要的原因。

还有一点就是常识问题：我们都知道磁盘的寻址是ms级别的，带宽是G/M(也就是千兆位每秒或兆位每秒)。而内存寻址是ns级别的，并且带宽远比磁盘快得多。从这个角度来看Redis基于内存的数据库快是毋庸置疑的。

其实也就是Redis 线程模型，能详细说下Redis的IO多路复用的原理吗？

候选者：好的。首先我们要明确知道Redis 服务器是一个事件驱动程序，服务器处理的事件分为文件事件和时间事件两类。

文件事件：Redis 主进程中，主要处理客户端的连接请求与响应。
时间事件：fork 出的子进程中，处理如 AOF 持久化任务等。

候选者：之所以 Redis 的文件事件是单进程，单线程模型，但是确保持着优秀的吞吐量，IO 多路复用起到了主要作用。

文件事件是对套接字操作的抽象，每当一个套接字准备好执行连接应答、写入、读取、关闭等操作时，就会产生一个文件事件。因为一个服务器通常会连接多个套接字，所以多个文件事件有可能会并发地出现。
IO 多路复用程序负责监听多个套接字并向文件事件分派器传送那些产生了事件的套接字。文件事件分派器接收 IO 多路复用程序传来的套接字，并根据套接字产生的事件的类型，调用相应的事件处理器。示例如图所示：

Redis 不同于 Memcached 的很重要一点就是，Redis 支持持久化，而且支持 3 种持久化方式:

快照（snapshotting，RDB）
只追加文件（append-only file, AOF）
RDB 和 AOF 的混合持久化(Redis 4.0 新增)

RBD 快照

什么是 RDB 持久化？

Redis 可以通过创建快照来获得存储在内存里面的数据在 某个时间点 上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用。

快照持久化是 Redis 默认采用的持久化方式，在 redis.conf 配置文件中默认有此下配置：

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发bgsave命令创建快照。

RDB 创建快照时会阻塞主线程吗？

Redis 提供了两个命令来生成 RDB 快照文件：

save : 同步保存操作，会阻塞 Redis 主线程；
bgsave : fork 出一个子进程，子进程执行，不会阻塞 Redis 主线程，默认选项。

这里说 Redis 主线程而不是主进程的主要是因为 Redis 启动之后主要是通过单线程的方式完成主要的工作。如果你想将其描述为 Redis 主进程，也没毛病。

AOF 持久化

什么是 AOF 持久化？

与快照持久化相比，AOF 持久化的实时性更好。默认情况下 Redis 没有开启 AOF（append only file）方式的持久化（Redis 6.0 之后已经默认是开启了），可以通过 appendonly 参数开启：

appendonly yes

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入到 AOF 缓冲区 server.aof_buf 中，然后再写入到 AOF 文件中（此时还在系统内核缓存区未同步到磁盘），最后再根据持久化方式（ fsync策略）的配置来决定何时将系统内核缓存区的数据同步到硬盘中的。

只有同步到磁盘中才算持久化保存了，否则依然存在数据丢失的风险，比如说：系统内核缓存区的数据还未同步，磁盘机器就宕机了，那这部分数据就算丢失了。

AOF 文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的，默认的文件名是 appendonly.aof。

AOF 工作基本流程是怎样的？

AOF 持久化功能的实现可以简单分为 5 步：

命令追加（append）：所有的写命令会追加到 AOF 缓冲区中。
文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数（系统调用），write将数据写入到了系统内核缓冲区之后直接返回了（延迟写）。注意！！！此时并没有同步到磁盘。
文件同步（fsync）：AOF 缓冲区根据对应的持久化方式（ fsync 策略）向硬盘做同步操作。这一步需要调用 fsync 函数（系统调用）， fsync 针对单个文件操作，对其进行强制硬盘同步，fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。

Linux 系统直接提供了一些函数用于对文件和设备进行访问和控制，这些函数被称为 系统调用（syscall）。

这里对上面提到的一些 Linux 系统调用再做一遍解释：

write：写入系统内核缓冲区之后直接返回（仅仅是写到缓冲区），不会立即同步到硬盘。虽然提高了效率，但也带来了数据丢失的风险。同步硬盘操作通常依赖于系统调度机制，Linux 内核通常为 30s 同步一次，具体值取决于写出的数据量和 I/O 缓冲区的状态。
fsync：fsync用于强制刷新系统内核缓冲区（同步到到磁盘），确保写磁盘操作结束才会返回。

AOF 工作流程图如下：