最受欢迎的内存数据库!

共 5610字,需浏览 12分钟

 ·

2024-08-16 14:17

作为当今广受欢迎的内存数据库,Redis以其卓越的性能和广泛的应用场景著称。

掌握Redis技术几乎成为每位开发人员、测试人员和运维人员的看家本领!

微信公众号「码哥跳动」(原「码哥字节」,后改名为「码哥跳动」)主理人码哥持续输出的Redis技术相关文章受到广大读者的喜爱,不少小伙伴都从中受益!

在大家的持续催更下,码哥的这本《Redis高手心法》终于和大家见面了!

作者将复杂的概念与实际案例相结合,以简洁、诙谐、幽默的方式揭示了Redis的精髓。

本书不仅是学习 Redis 的必备指南,更是驾驭 Redis 强大功能的秘籍。

无论你是初学者还是经验丰富的开发者,都会在阅读本书的过程中得到启发与收获。

如果你希望站在Redis的顶峰,那么《Redis高手心法》绝对是你不可或缺的利器!

千古无同局,叶底能否藏花,我们未来印证,愿此心法能让你学有所成!

下面就让码哥带我们一探本书的究竟,提前领略一下其中精彩纷呈的内容吧~~



文/码哥

1打磨只为呈现完美的作品

Chaya:码哥,Redis 这么快,你咋就这么慢呢?从恋爱到生娃都没你这么久。

写书的难度可比写公众号文章大多了。公众号的文章,可能有一些错别字,也有可能存在语病。

编写书的话,要求严格多了,语言要精准正确,不能存在错别字和语病,内容需要循序渐进有层次感,还要经过出版社老师的多次审核、校正,每一段话和文字都是我们精心「雕刻」的成果。

此外,我经过多年对 Redis 的深耕,花了很多时间重新梳理了 Redis 技术架构,加入了 Redis 6.0 ~ 7.0 版本的各种全新特性,从更深层次的角度挖掘底层实现原理,并尽量用风趣幽默的语言和 158 张图片解释难懂的技术点

作为后端开发者的我深刻知道,学习是一件比较难的事情,所以我就想着站在开发者的角度,用拟人化、场景化诙谐幽默的言语,再加撩人心弦又准确图片让读者轻松愉快地学习 Redis 实现原理和开发实战技巧。

总之一句话,每一个章节都经过反复推敲,只为呈现出最精彩的内容给你们。在我花费了大量精力更系统更全面地规划,以及出版社老师不断编排打磨,《Redis 高手心法》纸质书成为了去繁存简,精益求精的作品,就好像从钢铁侠战甲马克1 号,进化到成功拿下灭霸一血的马克 85 战甲。

Chaya:网络资料很多,但碎片化严重,如何才能成为 Redis 高手,建立完整的知识框架?

本书基于 Redis 7.0 版本的源码来讲解,并建立了一个完整的 Redis 知识框架,从全局视角整理 Redis 知识体系,结合难点给出158 张图片,希望能让你们更容易理解。

对于一门技术,如果只接触了零散的技术点,没有在脑海里建立⼀个完整的知识框架和架构体系,没有系统观,就会很吃力,而且会出现一看好像会,过后就忘记,⼀脸懵逼的情况。

我会引导大家从全局出发,带着问题去寻找答案,尝试输出对一个技术点的思考和理解。

⼀起搭建⼀套完整的知识框架, 学会从全局视角整理整个知识体系

2欲练此功不必自宫只需放松

本书的特点是 Redis 化身成人,将复杂的概念与实际案例相结合,以简洁诙谐幽默的方式,为你揭示 Redis 的精髓

从 Redis 作为第一人称视角出发,以拟人故事化的方式和诙谐幽默的语言与各路“神仙”对话,配合 158 张图片,由浅入深循序渐进地讲解 Redis的数据结构实现原理。

现在新书上市,优惠力度特别大,原价 100,现在 5 折优惠,只需要 50 灵石,推荐大家趁着这个机会,赶紧冲一波,拍下《Redis 高手心法》 秘籍,早日修炼天阶斗技。


由于篇幅有限,接下来我从书中摘取少量内容,给大家感受下文字和图片的温度......


2.1底层数据结构实现原理

天下武功,无坚不摧,唯快不破!我的名字叫 Redis,全称是 Remote Dictionary Server。

Chaya:我知道你支持很多种数据类型,对于不同的数据类型,底层应该用了多种数据结构来实现存储吧?

Chaya 小姐姐很聪明,我给开发者提供了 String(字符串)、Hashes(散列表)、Lists(列表)、Sets(无序集合)、SortedSets(可根据范围查询的排序集合)、Bitmap(位图)、HyperLogLog、Geospatial(地理空间)和 Stream(流)等数据类型。

为了在速度和内存占用之间找到最优解,我设计了多种数据结构。总之为了实现多快好省(支持数据类型多、速度快、好用、节省内存)。

MySQL:“就拿 Sting 类型来举例吧,C 语言本就有字符串,为嘛还自己搞了一套字符串类型,吓唬谁呢?!”

格局能不能打开一点儿,我并没有直接使用 C 语言的字符串,而是自己搞了一个 SDS 的结构体来表示字符串。

为了支持丰富和高性能的字符串操作函数、保存二进制格式数据、节省内存,以及实现“既 要又要还要”的目标。

SDS 中的 len 字段保存了字符串的长度,实现了 O(1) 时间复杂度获取字符串长度。

SDS 结构有一个 flags 字段,表示的是 SDS 类型。实际上 SDS 一共设计了 5 种类型,分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64,区别在于数组的len 长度和分配空间长度 alloc 不同。

struct __attribute__ ((__packed__)) sdshdr8 {
   uint8_t len;
   uint8_t alloc;
   unsigned char flags;
   char buf[];
};

节省内存

之所以这么设计,是因为使用不同的 SDS 类型保存不同大小的字符串可以节省内存。

二进制格式数据安全

SDS 不仅可以存储字符串类型数据,还能存储二进制格式数据。SDS 并不是通过“\0” 来判断字符串结束的,而是采用 len 标志结束,所以可以直接存储二进制格式数据。

编码格式

我还对字符串类型的数据采用了三种编码格式来存储,分别是 int、embstr 和 raw,你可使 用 OBJECT encoding key来查找对象所使用的编码类型。

空间预分配

当对 SDS 进行缩短操作时,程序并不会回收多余的内存空间,如果后面需要 append 追 加操作,则直接使用 buf 数组 alloc -len 中未使用的空间。

通过惰性空间释放策略,避免了减小字符串所需的内存重新分配操作。

篇幅有限,更多的底层数据结构实现原理详见《Redis 高手心法》,不再一一列举......


2.2RDB 与 AOF

Chaya:Redis 数据保存在内存,如果没有持久化,一旦断电或者宕机,保存在内存中的数据将全部丢失,咋办呢?

我有两大撒手锏,可以实现数据持久化,做到宕机快速恢复,“不丢数据稳如山”,无须从数据库中慢慢恢复数据。它们就是 RDB 快照和 AOF(Append Only File)。

MySQL:“在实际生产环境中,程序员通常会给你配置 6GB 的内存,将这么大的内存数据生成 RDB 快照文件落到磁盘的过程会持续比较长的时间。你如何做到在继续处理写命令请求的同时保证 RDB 与内存中的数据一致呢?”

作为唯快不破的 NoSQL 数据库扛把子,我在对内存数据做快照时,并不会暂停写操作(读操作不会造成数据的不一致)。

我使用了操作系统的多进程写时复制技术(Copy On Write ,COW)来实现快照持久化。

Chaya:“随着写入操作持续执行,AOF 日志过大怎么办?文件越大,数据恢复就越慢。”

为了解决 AOF 文件体积膨胀的问题,创造我的 Antirez 老哥设计了 AOF 重写机制(AOF Rewrite),对文件进行瘦身。

每次 AOF 重写时,Redis 都会先执行内存复制操作,让 bgrewriteaof 子进程拥有此时的 Redis 内存快照,子进程遍历Redis 内存快照中的全部 field-value pairs,生成重写记录。

MySQL:在 AOF Rewrite 过程中,主进程除了把写命令写入 AOF 缓冲区,还要把写命令写入 AOF 重写缓冲区。一份数据要写入两个缓冲区,还要写入两个 AOF 文件,产生两次磁盘 I/O,太浪费了。

上述的 AOF Rewrite 操作是 Redis 7.0 之前的逻辑,俗话说得好,“只要思想不滑坡,办法总比困难多”。为了解决性能问题,7.0 版本开始引入 Multi-Part AOF 机制。

篇幅有限,Multi-Part AOF 具体实现原理详见《Redis 高手心法》,这里不在一一列举。

2.3主从复制架构

Chaya:“有了 RDB 快照和 AOF 再也不怕宕机丢失数据了,但是 Redis 实例宕机了怎么办?如何实现高可用呢?”

Chaya 愣了一会儿,又赶紧补充道:“依然记得那晚我和我的恋人鸳语轻传,香风急促,走在成都的街头约会。可是这时候 Redis 忽然宕机了,无法对外提供服务,电话连环 call,岂不是折煞人也“。

莫怕,为了你们的幸福。我提供了主从模式,通过主从复制,将一份冗余数据复制到其他 Redis 服务器,实现高可用。你们放心地说温存,说风月。

Chaya:“master 和 slave 的同步是如何完成的呢?master 的数据是一次性传给 slave,还是分批同步?主从正常运行期间又怎么同步呢?要是 master 和 slave 间的网络断连了,重新连接后数据还能保持一致吗?”

你问题怎么这么多?不要急。我知道你想安心地与恋人相会,不受 Redis 宕机导致的服务报警的干扰。主从数据同步分为 4 种情况。

◎ master 和 slave 第一次全量同步。

◎ master 和 slave 正常运行期间的数据同步。

◎ master 和 slave 网络断开重连同步。

主从库第一次复制过程大体可以分为 3 个阶段:建立连接阶段(准备阶段)、同步数据阶段、发送同步期间接收的新写命令到 slave 阶段。


更多细节,详见《Redis 高手心法》......


2.4哨兵集群

主从复制架构面临一个严峻问题:master 宕机,无法执行写操作,无法自动选择一个 slave 切换为 master,也就是无法实现故障自动切换。

Chaya 的恋人:“眼前是橡树的绿叶,白色的竹篱笆。好想告诉我的她,这里像幅画。一起手牵手么么哒(此处省略 10000 字)Redis 忽然宕机,我总不能把 Chaya 推开,停止甜蜜,然后打开电脑手工进行主从切换,再通知其他程序员把地址改成新master 的信息上线?”。

如此一折腾恐,想必你心里的雨倾盆地下,万万使不得。所以必须有一个高可用的方案,为此,我提供一个高可用方案——哨兵(sentinel)。

哨兵是 Redis 的一种运行模式,它专注于对 Redis 实例(master、slave)运行状态的监控,并能够在 master 发生故障时通过一系列的机制实现选主及主从切换,实现自动故障切换,确保整个Redis 系统的可用性。

你就可以安心地与你的恋人 Chaya 在欢乐港湾约会,尽情享受甜蜜,哪怕是吵架都那么醉人,不再需要担心 Redis 忽然宕机带来的烦恼。

我们先从全局看哨兵,简要地了解它的整个运作流程,接着针对每个任务详细分析,Redis 哨兵的主要职责如下。

Chaya:“来说下实现原理吧。”

篇幅有限,我就不继续细说实现原理的细节了,现在新书上市,优惠力度很大,原价 100,现在 5 折优惠,各位道友只需拿出 50 灵石,购买查看完整版的《Redis 高手心法》进行修炼。


3IT 大佬们对本书的赞誉

以下来自一些 IT 技术大佬对本书的推荐语。


限时五折优惠,快快抢购吧!

浏览 179
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报