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
小黑十一点半