Hello,大家好,我是小黑哥~ 上次我们分享 Redis 字符串的底层原理,今天我们再来看下 Redis List 列表的底层原理。 Redis List 命令 Redis List 列表支持的相关指令比较多,比如单个元素增加、删除操作,也支持多个元素范围操作。 Redis List 列表支持列表表头元素插入/弹出**(LPUSH/LPOP**),也支持表尾元素插入/弹出(RPUSH/RPOP)。 另外 Redis List 列表还支持根据下标(LINDEX )获取元素,也支持根据根据下标覆盖相应的元素(LSET )。 除此之外,Redis List 列表还支持的范围操作,比如获取指定范围内全部元素(LRANGE ),移除指定范围内的全部元素(LTRIM )。 了解完的 Redis 相关指令,我们来看下 Redis List 列表底层实现方式,使用两种数据结构: 压缩列表(ziplist) 双向列表(linkedlist) ps:本篇文章基于 Redis 3.2 开始进行讲解 双向列表(linkedlist) 上面我们知道了List 列表支持表头/表尾元素的插入/弹出,这类.... 文带你了解 Redis 列表底层的实现方式 Redis
今天小黑哥来跟大家介绍一下 Redis 发布/订阅功能。 也许有的小伙伴对这个功能比较陌生,不太清楚这个功能是干什么的,没关系小黑哥先来举个例子。 假设我们有这么一个业务场景,在网站下单支付以后,需要通知库存服务进行发货处理。 上面业务实现不难,我们只要让库存服务提供给相关的给口,下单支付之后只要调用库存服务即可。 后面如果又有新的业务,比如说积分服务,他需要获取下单支付的结果,然后增加用户的积分。 这个实现也不难,让积分服务同样提供一个接口,下单支付之后只要调用库存服务即可。 如果就两个业务需要获取下单支付的结果,那也还好,程序改造也快。可是随着业务不断的发展,越来越多的新业务说是要下单支付的结果。 这时我们会发现上面这样的系统架构存在很多问题: 第一,下单支付业务与其他业务重度耦合,每当有个新业务需要支付结果,就需要改动下单支付的业务。 第二,如果调用业务过多,会导致下单支付接口响应时间变长。另外,如果有任一下游接口响应变慢,就会同步导致下单支付接口响应也变长。 第三,如果任一下游接口失败,可能导致数据不一致的情况。比如说下图,先调用 A,成功之后再调用 B,最后再调用 C。.... Redis 发布订阅,小功能大用处,真没那么废材! Redis
哎,最近小黑哥又双叒叕犯事了。 事情是这样的,前一段时间小黑哥公司生产交易偶发报错,一番排查下来最终原因是因为 Redis 命令执行超时。 可是令人不解的是,生产交易仅仅使用 Redis set 这个简单命令,这个命令讲道理是不可能会执行这么慢。 那到底是什么导致这个问题那? 为了找出这个问题,我们查看分析了一下 Redis 最近的慢日志,最终发现耗时比较多命令为 keys XX* 看到这个命令操作的键的前缀,小黑哥才发现这是自己负责的应用。可是小黑哥排查一下,虽然自己的代码并没有主动去使用 keys命令,但是底层使用框架却在间接使用,于是就有了今天这个问题。 问题原因 小黑哥负责的应用是一个管理后台应用,权限管理使用 Shiro 框架,由于存在多个节点,需要使用分布式 Session,于是这里使用 Redis 存储 Session 信息。 画外音:不知道分布式 Session ,可以看看小黑哥之前写的 一口气说出 4 种分布式一致性 Session 实现方式,面试杠杠的~ 由于 Shiro 并没有直接提供 Redis 存储 Session 组件,小黑哥不得不使用 Github 一.... 血的教训!千万别在生产使用这些 redis 指令 Redis
最近在学习 Redis 相关内容,为此买了两本关于 Redis 的书籍,一本为 「Redis 设计与实现」,另一本为 「Redis 开发与运维」。 目前大概看了一半,个人聊聊两本书籍的的区别。 第一本 「Redis 设计与实现」,这本书主要偏重与底层原理,本书大部分内容都是从底层 C 语言代码介绍,再结合大量插图的讲清楚其中技术点。 这样的优点在于从源码出发,可以很深刻的理解其中设计实现点,另外还可以偷学一波大佬们的代码。 第二点,对于有些原理,直接从代码理解,可能很不好弄懂,不过通过插图方式,一下子就能看懂。 再来说说这样的缺点,对于没学过 C 语言的,或者说只接触过 Java 的同学来讲,这样直接从 C 语言看起真的很难。 还记得个人两年前就同事那里看过这本书,刚看第一张,就被劝退了。 密密麻麻的 C 语言,看的真的头疼! 不过随着自己编程经验越来越丰富,现在再来看这些 C 语言代码,已经没有那么费劲。 不知道大家有没有发现,以前有些看不懂的原理知识,有些觉得很难的原理,随着编程经验越来丰富,渐渐都明了了,都能看懂了。 所以有些东西如果在你这阶段真的看不懂,那就不要纠结,适当放弃.... 这两本 Redis 书籍,真经典!! Redis
最近,小黑哥的一个朋友出去面试,回来跟小黑哥抱怨,面试官不按套路出牌,直接打乱了他的节奏。 事情是这样的,前面面试问了几个 Java 的相关问题,我朋友回答还不错,接下来面试官就问了一句:看来 Java 基础还不错,Java HashMap 你熟悉吧? 我朋友回答。工作经常用,有看过源码。 我朋友本来想着,你随便来吧,这个问题之前已经准备好了,随便问吧。 谁知道,面试官下面一句: 那好的,我们来聊聊 Redis 字典吧。 直接将他整蒙逼。 小黑哥的朋友由于没怎么研究过 Redis 字典,所以这题就直接回答不知道了。 当然,如果面试中真不知道,那就回答不了解,直接下一题,不要乱答。 不过这一题,小黑哥觉得还是很可惜,其实 Redis 字典基本原理与 HashMap 差不多,那我们其实可以套用这其中的原理,不求回答满分,但是怎么也可以得个及格分吧~ 面试过程真要碰到这个问题,我们可以从下面三个方面回答。 数据结构 元素增加过程 扩容 字典数据结构 说起字典,也许大家比较陌生,但是我们都知道 Redis 本身提供 KV 查询的方式,这个 KV 就是其实通过底层就是通过字典保存。 另外,.... 阿里面试官:HashMap 熟悉吧?好的,那就来聊聊 Redis 字典吧! Redis