Redis核心技术

最新推荐文章于 2024-07-25 12:57:13 发布
最新推荐文章于 2024-07-25 12:57:13 发布
阅读量533 收藏 1
点赞数 2
分类专栏： redis 文章标签： redis 哈希算法
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dinl_vin/article/details/123095452
版权

title: Redis核心技术
date: 2022-02-22 09:40:32
tags: Redis
categories: Redis

1. 数据结构

提及Redis,脑海中的第一反应就是"快",那么Redis有多快呢?

通常Redis接收到一个键值对的操作后,会以微秒级别 的速度找到数据,并快速完成操作.

Redis都支持哪些数据结构呢?

  • 简单动态字符串: String

  • 双向链表,整形数组: List

  • 压缩列表: List+Hash + SortedList

  • 哈希表: Hash + Set

  • 跳表: Sorted Set

  • 集合: Set

Redis如何保存数据呢?

Redis通过对key进行hash,保存了一个全局哈希表,你可以理解成Map<String,Entry>,String是key的hashcode,Entry是一个二元封装(*key,
*value),又被称为哈希桶,保存着key和value的指针.

哈希表按key找值的算法复杂度是O(1),只要对键进行Hash操作,可以立即取到对应的值,所以Redis取值操作很快.

为什么哈希表的操作会变慢

由于全局哈希表的大小是有限的,但是key是无限增长的,所以就会有哈希冲突的存在.哈希冲突时,不同的key的hashcode相同,全局哈希表一个key对应的多个entry以链表形式保存,此时哈希桶中的每个entry都是一个三元封装(*key, *value, *next),除了存放本身的键值指针以外,还存放着指向下一个entry的next指针.形成一个链表,又叫哈希冲突链.

这个时候按照key查找值的操作变成了(用java伪代码表达一下方便理解,redis本身是c语言写的)

 String keyHash = hash(key) // 计算key的hash值
 entry = globalHash.get(keyHash)  //按照key查找哈希桶
 while entry.key != key:
	entry = entry.next
 return entry.value

可以看到这里的取值复杂程度跟哈希冲突链的长度有关.哈希冲突越大,操作越慢.

这个时候Redis会怎么解决呢? Rehash.

顾名思义,Rehash就是对现有的全局哈希表扩容,假设原来的全局hash表容量是一万,hash算法为按key取模,将hash表的容量扩大到两万,就能将每个哈希桶里的哈希冲突链缩短到一半.说明Rehash是一个行之有效的操作:

如何落地Rehash呢?

redis采用了类似CopyOnWrite的设计,默认采用两个全局哈希表,hashTable1和hashTable2,一开始数据量较少的时候只用hashTable1,hashTable2没有被分配空间,随着数据逐渐增多,Redis开始进行Rehash操作,分为以下3步:

  1. 给hashTable2分配空间,假设是hashTable1的两倍
  2. 将HashTable1的数据重新映射(暂且称为reIndex),存入hashTable2;
  3. 释放hashTable1的空间

至此,就可以切换到另一个全局hash表,原来hashTable1的空间轮换休息,作下一次扩容备用.

但是上述做法有一个问题就是第2步涉及大量的reIndex和copy,假如这个rehash的时机选择跟ArrayList一样在到达某个阈值的瞬间进行扩容,这个操作的等待时间就会被加上rehash的时间,显然对于到达阈值这次的操作来说,用户体验太差.

为了避免这个问题,Redis的解决方案是渐进式rehash.

所谓渐进式rehash,就是一旦为hashTable2分配空间后,每次对hashTable1的取值,只对该值指向的Entry进行rehash.

这样就巧妙的避免了一次性大量拷贝的开销,将一次替换分摊到了每个请求上.除了在查询时根据key搬运,redis本身也有一个定时rehash.

各种操作的平均时间复杂度
名称查询下标查找
哈希表O(1)O(1)
跳表O(logN)-
双向链表O(N)O(N)
压缩列表O(N)O(1)
集合O(N)O(1)

2. IO模型

redis中存在大量全局变量,如全局哈希表等,多线程使用共享资源的并发控制难以实现,而且多线程操作对于共享变量很难设计一个粒度合适的锁,这种情况即使使用多线程,难免大部分情况下有很多线程处于等待状态,多线程并发的开发成本和维护成本也要明显高于单线程,为了避免这些情况.Redis直接采用了单线程.

当然这里所说的单线程,仅仅指的是与客户端交互的时候,网络IO和数据读写是由一个线程完成的,而数据清理,主从复制都用了其他线程.

Redis的IO模型借用了Unix内核的多路复用技术,多个套接字借用epoll机制,让CPU来监听,不同事件触发不同回调机制,这些回调机制就是把相应事件放到一个待处理的队列中,再由Redis单核不断处理队列中的任务.因为Redis一直在对队列事件进行处理,所以能及时响应客户端请求.

多路复用机制,即使在不同操作系统上也有不同的实现,在Linux中是select和epoll实现,基于FreeBSD的kqueue和Solaris的evport,还有类似libuv中windows系统使用IOCP.

3. 持久化:AOF和RDB

Redis大多数的使用场景在于内存缓存, 提高后端的相应速度.Redis是一款高性能内存数据库,但是如果Redis本身只用内存,便会存在一个不可忽视的问题,一旦服务宕机,内存中的数据将全部丢失.

为了避免从后端load到内存的网络压力和处理速度,Redis自身也实现了一套缓存逻辑.Redis 的持久化主要有两大机制，即 AOF（Append Only File）日志和 RDB 快照。

AOF(Append Only File)

不同于数据库的"写前"日志(Write Ahead Log,WAL),Redis的AOF是"写后"日志,Redis先执行命令把数据写到内存,然后才会记录日志.

为什么Redis要在写后才记录日志呢?

  • 避免记录错误命令
  • 不会阻塞当前操作

数据库的Redo log记录的是命令修改后的数据,而AOF记录的是Redis收到的每一条命令.

因为先写内存后记录日志的设计,Redis AOF的风险也就在于写完内存之后还没记录日志就宕机,会造成命令和数据丢失,

如果Redis是缓存的话还能从后端数据库重新load这期间的数据,但是如果是直接控制数据库,就无法恢复了,而且Redis虽然不会阻塞当前命令,但是会阻塞下一条命令(因为AOF也是由主线程完成的)

为了让AOF写入变得可控,Redis提供了三种AOF写回策略,即 appendfsync配置项的三个可选值.

  • Always: 同步写回,每条命令执行完,立马同步写回磁盘
  • EverySec: 每秒写回,每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘
  • No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

与全局哈希表类似,AOF日志也有两份,正在使用的AOF由主线程写入,另一份由bgrewriteaof子线程来完成.

为什么要有另一份重写日志呢?

  • 重写日志会做操作合并,解决日志太大的问题(同一个key多次set只保留最终的值)
  • 提高容错性.也可用作宕机恢复

RDB(Redis Database)

与AOF不同的是RDB记录的是某一时刻的数据,而不是操作.所以在做Redis宕机恢复的时候可以直接将RDB的数据读入内存,就能快速恢复

RDB的保存的命令分别喂save和bgsave, 二者的区别是save在主线程中执行,而bgsave为专门用于生成RDB的子线程执行,bgsave是Redis保存快照的默认配置.

快照保存的是瞬间数据,为了不影响主线程正常工作(快照时不暂停),且不被主线程的修改影响(快照生成期间的改动不录入),Redis会借助操作系统提供的写时复制(Copy-On-Write,COW)技术,子线程由主线程fork生成,bgsave运行后读取主线程内存数据,如果此时主线程修改内存数据,这块数据就会复制一份,主线程修改复制处的数据,等到读取结束后再同步回去.

RDB越多越好吗?

理论上来说,快照越频繁,越能减少数据丢失的概率,但是快照间隔时间过短,也会带来两方面的压力:

  • 磁盘被频繁写入
  • bgsave线程出自主线程,过多fork会阻塞主线程.

有没有办法只做增量快照呢?

增量快照需要有大量元数据记录两次快照期间有哪些key有变动,如果有1万个key被修改,就要有1w条记录,对于内存本就宝贵的redis来说有些得不偿失.

Redis 4.0提出了RDB + AOF混用的方式,也就是RDB周期执行,在周期期间的变动使用AOF记录,这种方案不仅避免了AOF过大,还允许RDB不用太频繁.

4. 数据同步

一个优秀的分布式组件的高可用性保障除了保证数据少丢失外(Redis使用AOF+RDB实现),还要有某种机制保证服务尽量少中断.

Redis保证服务的机制是:

Redis提供了主从库模式,为了保证主从库数据一致,采用的是读写分离的方式.

读: 主从库都可以读

写: 首先到主库执行,再由主库将操作同步给从库.

如何给某个redis加从库?

例如，现在有实例 1（ip：172.16.19.3）和实例 2（ip：172.16.19.5），我们在实例 2 上执行以下这个命令后，实例 2 就变成了实例 1 的从库，并从实例 1 上复制数据：

replicaof  172.16.19.3  6379

主从库的同步过程:

Redis主从同步分为以下几步,

  1. 从库给主库发送psync命令,请求与主库同步数据.请求参数{runID : ?,offset: -1}(由于第一次同步不知道主库runID,所以设为"?",offset表示复制进度,第一次置为-1)
  2. 主库回复FULLRESYNC命令,表示第一次采用全量复制,参数{runID:{主库runID},offset:当前复制进度}
  3. 主库将所有数据进行快照RDB,发送RDB文件至从库
  4. 从库接受到RDB文件,清空自身数据并加载RDB文件到内存
  5. 在RDB同步期间,主库不会中断服务,并且用replication buffer记录RDB文件至最新的所有写操作.
  6. 把步骤5中的replication buffer操作发给从库,从库执行这些操作.
如果有多个从库,主库压力太大怎么办?

上述同步过程可以看出来同步期间主库需要完成两个耗时的操作: 生成和传输RDB文件.如果从库数量过多,会让主库忙于fork子进程生成bgsave.这个时候就可以采用"主-从-从"的模式了:比如A是主库,B和C是A的从库,D和E是B的从库.

主从同步期间网络中断了怎么办?

Redis 2.8之前如果网络中断需要重新同步,Redis 2.8实现了增量同步, 只用同步网络断开期间主库的变更.

那么它是如何实现的呢?

主库在同步期间维护了一个replication buffer用于RDB生成期间的增量变化,照这个思路,主库同样维护了一个repl_backlog_buffer的环形缓冲区,在网络断开期间收到的命令会写入replication buffer,也会写入repl_backlog_buffer缓冲区.

repl_backlog_buffer这个缓冲区除了主库会记录当前写入的位置(master_repl_offset),从库也会写入自己读到的位置(slave_repl_offset),连接恢复后从库通过psync命令同步断开期间的命令直到这两个偏移量相等.

5. 哨兵机制

在这个设计中主库的角色至关重要,从库看起来只是为读操作提供了高可用的备选,那如果主库挂了呢?

答案是Redis的哨兵机制,哨兵的主要职责就是: 监控,选主和通知

监控:

哨兵通过周期性的PING主从库,检测他们是否正常运行,如果在规定的时间内没有响应,就会标记下线.哨兵集群针对主库的标记称为"主观下线(+sdown)“主观下线是哨兵对主库的主观判断,并不一定说明集群真的下线了,有可能网络波动或者繁忙.为了避免误判,多个哨兵的"主动下线"通过少数服从多数的票选,由哨兵Leader标记为"客观下线”(+odown).

选主

由哨兵leader标记主库客观下线之后,将开启哨兵的下一轮职责,选主.哨兵选主的过程为"筛选+打分"

筛选: 从从库中筛选出网络状态良好的从库(不仅当前网络状态良好,历史网络波动也在考量范围内)

打分: 打分分为从库优先级,从库复制进度,从库ID号三轮打分,上一轮未决出优胜者才会进行下一轮打分.

  • 从库优先级: slave-priority配置项,优先级高的从库胜出
  • 从库复制进度: 复制进度最接近旧主库的从库胜出
  • 从库ID: ID小的从库胜出
通知

哨兵的通知机制基于客户端的pub/sub机制,订阅了同一频道的应用可以通过发布的消息进行信息交换.哨兵之间通过__sentinel__:hello 频道互相发现,完成投票选举leader,投票判断主库是否挂掉等工作.客户端也通过订阅哨兵的消息频道接收哨兵的通知,当新的从库被选举成主库,哨兵会通知客户端进行主库切换.和从库重新配置.

6. 切片集群

同众多分布式组件一样,Redis也提供了切片集群的机制来保证数据规模的横向扩展.

但是横向扩展带来的问题就是:

  1. 数据分布: 数据切片之后如何在多个实例之间分布?
  2. 访问路由: 客户端访问的时候如何确定要访问的数据在哪个实例上?
数据分布

从Redis3.0开始,Redis Cluster实现了切片集群.具体来说就是提供了214 (16384)个哈希槽(Hash Slot)来处理数据和实例之间的关系.

数据和Hash Slot的映射是 将key通过CRC16算法计算16bit的hash值,然后对16384取模,这样可以让key分布到16384个哈希槽上

伪代码

slot = Crc16(key) % (1 <<14)

Hash Slot 和实例的对应映射,在使用cluster create命令创建集群的时候会自动平均到各个实例上同样是取模算法,每个实例对应的就是Hash Slot个数就是16384/N个.

在使用cluster meet手动建立实例连接形成集群并使用cluster addslots命令的时候可以手动指定每个实例上的slot,就像下边这样:

redis-cli -h 172.16.19.3 –p 6379 cluster addslots 0,1
redis-cli -h 172.16.19.4 –p 6379 cluster addslots 2,3
redis-cli -h 172.16.19.5 –p 6379 cluster addslots 4

使用手动指定slot的方式有两个注意点:

  • addslots 添加的slots number 应该介于 0~16383之间
  • 需要把这16384个槽都分配完集群才能正常工作
dinl_vin
关注
  • 2
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Redis 核心技术 + 实战
02-21
在"Redis 核心技术 + 实战"的学习中，我们将深入理解 Redis 的核心概念、特性和实际应用。 1. **Redis 基本概念** - Redis 服务器：负责存储和管理数据的进程。 - 客户端：与 Redis 服务器进行通信的程序，用于...
服务器安装Redis和配置后台远程连接
凡的博客
02-24 1129
服务器安装Redis和配置后台远程连接
Redis详解及在项目中应用
weixin_43816557的博客
08-16 6748
本人目前写的所有文章都是基于springboot项目中可能用到的框架技术，如有需要，可在专栏中寻找。本文从简单介绍redis的基本操刀到在项目中redis的应用，再到缓存预热的介绍，最后介绍了创建更新缓存计划内容，由浅入深逐步剖析。...
【Redis 初阶】初识 Redis
最新发布
Elena's Blog
07-25 1359
了解 Redis。
redis的核心技术点
chenjie的博客
02-26 983
总结归纳redis的核心技术点如下： 杂七杂八 1、redis是基于C语言开发、纯内存运行的一个key-value型数据库,redis是单线程实现的。 2、利用队列技术，将并发访问转换为了串行访问，减少了传统数据库串行控制的开销。 3、redis支持的语言由：C、C++、java、php、Node.js、GO等。 一、redis的五种常用数据类型 string list set sorted set hash 二、为什么redis是单线程的？为什么redis单线程还可以这么快？ redis是基于内存进行操作
Redis技术详解
软件Java开发工程师
01-06 647
redis技术详细讲解
Redis(一)——Redis核心数据结构和高性能原理
yemuxiaweiliang的博客
04-12 415
redis入门与核心原理
1.Redis核心技术与应用实践 谢国恩.pdf
07-21
"Redis核心技术与应用实践" Redis 是一个开源的高性能数据结构存储系统，可以实现高可用高性能数据结构丰富的分布式应用场景。Redis 提供了丰富的数据结构，如 string、hashmap、list、set、sorted-set、bitmaps、...
Redis技术文档
06-09
一、Redis核心概念 1. 键值存储：Redis基于键值对的数据结构，键（Key）是唯一的标识符，值（Value）可以是字符串、列表、集合、哈希表等多种类型。 2. 持久化：为了防止数据丢失，Redis提供了RDB（快照）和AOF...
WAL与AOF与RDB
u013887652的博客
03-21 208
备忘
Redis深入理解-内核请求处理流程、数据传输协议
qq_45260619的博客
11-23 1270
AOF 将内存数据同步到磁盘中，一般采用每秒同步一次，如果同步频率过高，就会导致 Redis 性能退化，当 Redis 突然宕机，可能会丢失 1s 内的内存数据，那么在 redis-server 进程重启时，就会把磁盘存储的 aof 文件的数据给读取到内存中，还原 Redis 上次运行时的内存情况。中，那么在上边的 argv 中拿到了命令的名称，就可以去命令查找表中去查找对应的 RedisCommand，在 Redis Client 的输入缓冲区中有一个变量。
Redis （六 深入了解redis内核）
伊始的博客
11-05 2736
### 内存淘汰 redis内存不足时，有两种处理方式： （1）启用虚拟内存：将vm-enabled设置为yes （2）启用内存淘汰：将maxmemory设置为一个大于0的整数 redis的使用内存大于最大分配可用内存时，开始进行淘汰，memcache只有LRU算法，redis有 1 随机淘汰：从数据库随机删除一个key 2 LRU算法：删除一个最近最少访问
redis详解(持续更新)
热门推荐
Ferao的博客
11-19 3万+
redis
Redis学习笔记（04 | AOF日志：宕机了，Redis如何避免数据丢失？）
qq_45651858的博客
10-13 215
04 | AOF日志：宕机了，Redis如何避免数据丢失？
浅谈 Redis 持久化的几种方式
小生的博客
07-14 320
因为 Redis 是基于内存的，如果发生宕机等异常情况，则会导致数据丢失，而这对很多业务来说是不可接受的，因此我们需要引入相应的持久化机制来保障数据的安全性。RDB是Redis默认的持久化方式，其会每隔指定时间将内存的数据以快照的形式保存到硬盘中，所以在做数据恢复时，我们可以直接把 RDB 文件读入内存，很快完成恢复。Redis 提供了两个命令来生成 RDB 文件，分别是 。以bgsave为例，为了保证在RDB持久化时不影响主线程的正常读写，其利用了COW(copy-on-write)机制。持久化，会将Re
redis核心技术梳理(持续更新)
泡^泡
04-18 2403
redis常用命令 get/set/exists/del/keys/rename/dbsize/type/mget/mset/expire/setnx/incr/decr/append/flushall redis的数据类型 String/Hash/List/Set/Zset/Hyperloglog/Geo/Stream/BitMaps redis事务 redis的单个命令是原子性的(比如get/set/mget/mset),要么成功要么失败,不存在并发干扰的问题。如果涉及到多个命令的.
Redis 核心知识总结
沉梦听雨的博客
12-27 1449
RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据，而 AOF 文件记录的是命令操作的日志，而不是实际的数据。因此在 Redis 恢复数据时， RDB 恢复数据的效率会比 AOF 高些，因为直接将 RDB 文件读入内存就可以，不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。哨兵（Sentinel）机制是 Redis 在 2.8 版本以后提供的。它的作用是实现主从节点故障转移。
Redis技术
qq_43703196的博客
06-30 1115
Redis面经
Redis核心技术与实战
该文档详细介绍了Redis的核心特性和数据结构，以下是一些关键知识点： 1. **简单介绍** Redis支持类似于memcached的文本协议，其键（KEY）由可打印字符组成，而值（VALUE）则支持多种数据类型，包括： - **...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值