JavaEdge全是干货的技术号

AOF优势在于，可以快速恢复数据库，也就是只需要把RDB文件直接读入内存，这就避免了AOF需要顺序、逐一重新执行操作命令带来的低效性能问题。不过，内存快照也有它的局限性。它拍的是一张内存的“大合影”，不可避免地会耗时耗力。虽然，Redis设计了bgsave和写时复制方式，尽可能减少了内存快照对正常读写的影响，但是，频繁快照仍然是不太能接受的。而混合使用RDB和AOF，正好可以取两者之长，避两者之短，以较小的性能开销保证数据可靠性和性能。数据不能丢失时，内存快照和AOF混用。

【Redis锁异常场景解析】本文剖析Redis分布式锁4类易被忽视的问题：1）时钟漂移导致锁过期计算错误，引发多客户端同时持有；2）看门狗线程挂起致使锁超时未续期；3）主从切换时锁丢失造成重复加锁；4）Lua脚本超时引发原子操作失败。针对性地提出了NTP同步、限制业务执行时间、RedLock策略及拆分复杂脚本等解决方案。这些边缘场景处理不当会导致系统陷入类死锁阻塞状态，需在分布式锁实践中重点防范。（149字）

RedLock是一种基于Redis的分布式锁算法，相比单节点实现更安全可靠。它具有互斥访问、避免死锁和容错性三大特性，要求过半节点存活即可运行。单节点实现通过SET NX PX和Lua脚本确保原子性操作。完整的RedLock算法需要5个独立master节点，客户端获取锁时需在多数节点成功且总耗时不超过TTL。失败需快速释放已获锁并延时重试。系统需考虑持久化策略，宕机节点需延迟重启超过最大TTL才能保证安全性，但这可能影响系统可用性。该算法在安全性和性能之间取得平衡，适合分布式环境下的锁管理需求。

Redis热点Key解决方案摘要 热点Key问题通常由秒杀活动、热评等读多写少场景或请求分片过于集中导致，会造成流量过载、缓存击穿和DB穿透等危害。解决方案包括： 服务端缓存：本地LRU缓存应对突发流量，但存在脏读风险 独立缓存层：使用Memcache/Redis就近访问，但浪费内存资源 随机后缀法：将热点Key分散到多个Redis节点，采用"空间换时间"策略保留两份缓存（带TTL和不带TTL），有效避免缓存击穿 核心是通过多级缓存和请求分散保证高并发场景下的系统稳定性。 （字数：149

本文总结了分布式锁的演进过程，从本地锁的局限性引出分布式锁的需求。通过"厕所占坑论"形象说明分布式锁原理，并分五个阶段详细分析了分布式锁实现方案的优化路径： 基础setnx实现存在死锁风险 增加过期时间但非原子操作 使用setNxEx保证原子性加锁 引入UUID防误删但仍非原子操作 采用Lua脚本保证删除操作的原子性 文章指出完整解决方案还需处理锁自动续期等问题，推荐直接使用Redisson框架，同时强调理解底层原理对问题排查的重要性。全文以代码示例和流程图结合，清晰地展现了分布式锁的技

Redis 的 quicklist 和 listpack 通过不同的设计策略，分别在内存利用和性能优化上提供了独特的解决方案。对于 Java 技术专家来说，理解这些底层数据结构的设计不仅有助于更好地使用 Redis，也为开发高性能应用提供了宝贵的借鉴。通过学习这些优化思路，我们可以在自己的系统设计中更好地权衡内存与性能，选择合适的数据结构来满足不同场景的需求。关注我，紧跟本系列专栏文章，咱们下篇再续！

Redis Server一旦和某客户端建立连接，就会在事件驱动框架中注册可读事件，对应客户端的命令请求。

2020年5月份正式推出了6.0版本，这个版本中有很多的新特性。面向网络处理的多IO线程可以提高网络请求处理的速度，而客户端缓存可以让应用直接在客户端本地读取数据，这两个特性可以提升Redis的性能。除此之外，细粒度权限控制让Redis可以按照命令粒度控制不同用户的访问权限，加强了Redis的安全保护。RESP 3协议则增强客户端的功能，可以让应用更加方便地使用Redis的不同数据类型。只有详细掌握了这些特性的原理，你才能更好地判断是否使用6.0版本。如果你已经在使用6.0了，也可以看看怎么才能用得更好

Redis 是一个非常流行的 NoSQL 数据库，它支持多种数据结构和高效的内存读写操作，因此被广泛应用于各种场景中。而 Redis Desktop Manager (RDM) 则是一个基于 Redis 的 GUI 客户端软件，它提供了直观的图形界面，方便用户管理和操作 Redis 数据库。然而，除了 RDM 之外，还有一个非常优秀的 Redis 客户端软件——AnotherRedisDesktopManager (以下简称 ARDM)。

服务A发送的三个有序请求请求1、2、3，依次发到MQ，然后服务B的多个实例从MQ消费。建议从业务设计时，不需要这种顺序性的保证，一旦引入顺序性保障，会导致系统复杂度上升，而且会带来效率低下，热点数据压力过大等问题。俩请求过去了，落在不同机器节点，可能插入请求因某些原因执行慢些，导致删除请求先执行了，此时因DB没数据，所以啥影响也没；将比如某个订单id对应的请求都给分发到某机器，在那个机器上因为可能还是多线程并发执行，你得立即将某个订单id对应的请求扔一个内存队列，强制排队，确保顺序性。

William Pugh发明，他在论文《Skip lists: a probabilistic alternative to balanced trees》中详细介绍了跳表的数据结构和插入删除等操作，论文是这么介绍跳表的：即跳表可用来替代红黑树，使用概率均衡技术，使得插入、删除操作更简单、更快。a：已排好序的链表，查找一个结点最多需比较N个结点b：每隔2个结点增加一个指针，指向该结点间距为2的后续结点，查找一个结点最多比较ceil(N/2)+1个结点。

秒杀系统是个系统性工程，Redis实现对库存查验、扣减环节的支撑。

脑裂，主从集群中，同时有两个主能接收写请求。Redis主从切换过程中，若发生脑裂，客户端数据就会写入原主，若原主被降为从库，这些新写入数据就丢了。和主库部署在同一台服务器上的其他程序临时占用了大量资源（例如CPU资源），导致主库资源使用受限，短时间内无法响应心跳。其它程序不再使用资源时，主库又恢复正常主库自身遇到阻塞，如处理bigkey或是发生内存swap（你可以复习下第19讲中总结的导致实例阻塞的原因），短时间内无法响应心跳，等主库阻塞解除后，又恢复正常的请求处理了。

缓冲区，用一块内存空间暂时存放命令数据，以免因数据和命令的处理速度＜发送速度而导致数据丢失和性能问题。往里写数据速度＞从里读数据速度会导致缓冲区需越来越多内存暂存数据。当缓冲区占用内存＞设定上限阈值，就会出现缓冲区溢出。发生溢出，就会丢数据。不给缓冲区设上限，不就没这问题了？No！随累积数据增多，缓冲区所占内存空间越大，耗尽Redis机器可用内存时，Redis实例就会崩溃！所以缓冲区是用来避免请求或数据丢失，使用姿势须正确，才能发挥作用。Redis所有操作命令都需通过C发给S。

使用Redis作为MySQL的前置缓存，可以非常有效地提升系统的并发上限，降低请求响应时延。绝大多数情况下，使用Cache Aside模式来更新缓存都是最佳的选择，相比Read/Write Through模式更简单，还能大幅降低脏数据的可能性。使用Redis的时候，还需要特别注意大量缓存穿透引起雪崩的问题，在系统初始化阶段，需要使用灰度发布或者其他方式来对缓存进行预热。

命令操作系统配置关键机制硬件配置要尽可能避免性能异常场景，还要做好异常应对方案。Redis内部的阻塞式操作CPU核和NUMA架构的影响Redis关键系统配置Redis内存碎片Redis缓冲区本文研究Redis内部的阻塞式操作及应对方案。Redis的网络I/O和KV对读写都由主线程完成。若在主线程执行操作耗时太长，就会引起主线程阻塞。但Redis既有服务客户端请求的键值对增删改查操作，也有保证可靠性的持久化操作，还有主从复制时的数据同步操作。哪些会引起阻塞？

1 为什么使用分布式锁？当有多个客户端并发访问某个共享资源时，比如要修改DB某条记录，为避免记录修改冲突，可将所有客户端从Redis获取分布式锁，拿到锁的客户端才能操作共享资源。分布式锁实现的关键就是保证加锁、解锁都是原子操作，才能保证多个客户端访问时锁的正确性。而Redis能通过事件驱动框架同时捕获多个客户端的可读事件（命令请求）。在Redis 6.x，还会有多个I/O线程并发读取或写回数据。那事到如今，分布式锁的原子性，还能被保证吗？那就得研究一条命令在Redis Server的执行过程，同时看

Redis到底快在哪？它接收到一个键值对操作后，能以微秒级速度找到数据，并快速完成操作。为啥就Redis这么突出？它是内存数据库，所有操作都在内存上完成，内存的访问速度本身就很快数据结构键值对是按一定的数据结构来组织的，操作键值对最终就是对数据结构进行增删改查操作，所以高效的数据结构是Redis快速处理数据的基础String（字符串）、List（列表）、Hash（哈希）、Set（集合）和Sorted Set（有序集合）只是Redis键值对中值的数据类型，即数据的保存形式。本文的数据结构，是

目标抓住学习和调优Redis的关键。简介Redis本身很复杂，上来就研究具体技术点，比如“单线程”、“缓存”，虽然可以直接学到具体内容，甚至立马解决一些问题，但这样容易溺死在细节汪洋。更好的学习方式就是先建立起“系统观”。想精通Redis，须能综览其总体架构、关键模块，然后再深入具体技术点。构造KV DB，首要考虑：数据模型可以存什么数据操作接口对数据可以做什么样的操作理解数据模型，就会明白为何有些场景下，原先使用关系型DB保存的数据，也能用KV DB保存。如用户信息（用户ID

为什么需要集群并发量redis 本身 10w/s，如果业务需要100 w/s 呢？数据量一个 redis 及其内存 16~256G，如果业务需要 500G 呢？不止于加机器。RedisCluster在 3.0 发布。5 一致性哈希6 虚拟槽哈希分区(Redis Cluster所采用)7 Redis Cluster基本架构8 Redis Cluster 安装配置Redis 3.0之后，节点之间通过去中心化的方式，提供了完整

本文介绍了Redis的核心数据结构与内部实现机制。首先概述了Redis的无传统关系型数据库Table模型，采用key作为顶层命名空间，支持string、list、set等数据类型。重点分析了redisObject通用结构和SDS动态字符串实现，包括内存分配、扩容策略等优化细节。文章详细讲解了String类型的操作命令及其复杂度，如set/get、incr/decr、批量操作等，并给出实际应用场景如分布式ID生成器。最后总结了单线程设计的高效原理，包括纯内存操作、非阻塞I/O等特性，解释了Redis高性能的关

缓存读写操作，很多人不假思索：先读Cache，Cache不命中就查DB，查到再回种Cache先删Cache，再更新DB，而后续操作会把数据再装载到缓存这是错误的！看最简单的两个并发操作：更新&查询。更新操作删除Cache后，查询操作没有命中Cache，先把老数据读出来后放到Cache，然后更新操作更新了DB。于是，Cache还是老数据，导致缓存数据是脏的，而且将一直脏下去。因此，针对不同业务场景，缓存读写策略也不同。本文默认更新数据库、缓存的操作都能成功执行完成。

消息大小考虑crc16()一共可以有：2^16 -1=65535不同的余数，代表bitmap 有 65535 bit。所以bitmap的大小可以计算为65535 / 8 (8bit/byte)/1024(1k)=7.99 Kbytes尽管crc16能得到65535个值，但redis选择16384个slot，是因为16384的消息只占用了2k，而65535则需要8k。正常的心跳包携带节点的完整配置，可以以幂等方式替换旧配置以更新旧配置。这意味着它们包含原始形式的节点的插槽配置，该节点使用2K

分片就是将数据拆分到多个 Redis 实例，这样每个实例将只是所有键的一个子集。1 分片有什么作用？分片可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分片使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。2 分片方案假想我们有 4 个 Redis 实例 R0，R1，R2，R3；很多表示用户的键，像 user:1，user:2等。有如下方案可映射键到指定 Redi

1 Redis Sentinel的意义master宕机了咋整？等运维手工从主切换，再通知所有程序把地址统统改一遍重新上线？那么服务就会停滞很久，显然对于大型系统这是灾难性的！所以必须有高可用方案，当故障发生时可自动从主切换，程序也不用重启，不必手动运维。Redis 官方就提供了这样一种方案 —— Redis Sentinel(哨兵)。sentinal，哨兵，redis集群架构中非常重要的一个组件，主要功能如下集群监控监控Redis master和slave进程的正常工作消息通知如果某个R

背景在 Redis 中，热 key 指的是那些在一段时间内访问频次比较高的键值，具体到业务上，商品的限时抢购、瞬时的新闻热点或某个全局性的资源，都极有可能产生热点 key。热点 key 的出现可能会对系统的稳定性和可用性造成影响，比如对应节点的网卡带宽被打满，出现丢包重传，请求波动耗时大幅上升，甚至影响到业务的正常使用，引发用户的不满。因此，在日常的工作中，我们需要着重避免这种情况的出现，比如在设计和编码阶段避免引入全局性热 key，或者在设计时考虑热 key 出现时的应对方案。可能的方案热点 ke

2 大Key如果一个Key的Value特别大，那么可能会对Redis产生巨大的性能影响，因为Redis是单线程模型，对大Key进行查询或删除等操作，可能会引起Redis阻塞甚至是高可用切换。应该如何查询Redis中的大Key，以及如何在设计上实现大Key的拆分呢？2.1 单个K存储的V很大key分类如下：该key需要每次都整存整取尝试将对象分拆成几个K.V， 使用multiGet获取值。拆分旨在降低单次操作的压力，将操作压力平摊到多个Redis实例，降低对单个redis的I/O影响。该对象每

缓存不仅加快了IO，还可减少原始数据的计算工作。缓存系统一般设计简单，功能单一，所以Redis吞吐量能是MySQL几倍~几十倍，对于互联网读多写少的高并发场景已不可或缺。虽然简单好用，但是如果姿势不对，就会造成不必要的损失。不要把Redis当数据库很多人不仅把 redis 当缓存，更是把Redis当做数据库使用。很多因为Redis中数据消失导致业务逻辑错误，并且因为没有保留原始数据，业务都无法恢复。虽然Redis有持久化功能，但这并不能以为它可作为高性能的KV数据库。Redis处理请求很快，但那

Redis将serverCron作为时间事件来运行，确保它每隔一段时间自动运行一次。serverCron需在Redis服务器运行期间一直定期运行，所以它是一个循环时间事件： serverCron 会一直定期执行，直到服务器关闭。Redis 2.6 规定 serverCron 10次/s， 即每 100ms/次。Redis 2.8 开始，用户可以通过修改 hz 选项来调整 serverCron的每秒执行次数。执行期间需要做11件事：更新服务器时间缓存redis中有许多功能要获取系统当前时间，则需

1 面试题生产环境中的redis是怎么部署的？2 考点分析看看你了解不了解你们公司的redis生产集群的部署架构，如果你不了解，那么确实你就很失职了，你的redis是主从架构？集群架构？用了哪种集群方案？有没有做高可用保证？有没有开启持久化机制确保可以进行数据恢复？线上redis给几个G的内存？设置了哪些参数？压测后你们redis集群承载多少QPS？兄弟，这些你必须是门儿清的，否则你确实是...

优化内存优化https://redis.io/topics/memory-optimization不同大小，底层数据结构不同：hash-max-ziplist-value 64zset-max-ziplist-value 64CPU优化不要阻塞，特别是 lua 脚本，不要有长时间睡眠操作，不然其它操作全部阻塞！谨慎使用范围操作SLOWLOG get 10 默认10毫秒，默认只保留最后的128条分区多个业务系统，共用一个redis, 还是应该分开。规划好key，特别是前缀，a.b.c.d

请求/响应协议和RTTRedis是一种基于客户端-服务端模型及请求/响应协议的TCP服务。这意味着一个请求会遵循以下步骤：客户端向服务端发送一个查询请求，并监听Socket返回，通常以阻塞模式，等待服务端响应服务端处理命令，并将结果返回给客户端。因此，例如下面是4个命令序列执行情况：Client: INCR XServer: 1Client: INCR XServer: 2Client: INCR XServer: 3Client: INCR XServer: 4客户端和服

Redis协议在以下几点之间做出了折衷：简单的实现快速地被计算机解析简单得可以能被人工解析网络层Redis在TCP端口6379上监听到来的连接，客户端连接到来时，Redis服务器为此创建一个TCP连接。在客户端与服务器端之间传输的每个Redis命令或者数据都以\r\n结尾。请求Redis接收由不同参数组成的命令。一旦收到命令，将会立刻被处理，并回复给客户端。新的统一请求协议新的统一协议已在Redis 1.2中引入，但是在Redis 2.0中，这就成为了与Redis服务器通讯的标准方式。

面试题Redis的持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？考点分析Redis如果仅仅只是将数据缓存在内存里面，假若宕机了，再重启，内存里的数据就全部丢失了！你必须得用Redis的持久化机制，将数据写入内存的同时，异步的慢慢的将数据写入磁盘若Redis宕机了，重启启动，自动从磁盘上加载之前持久化的一些数据即可，也许会丢失少许数据，但至少不会将所有...

1 面试题了解什么是Redis的雪崩和穿透吗？Redis崩溃之后会怎么样？系统该如何应对这种情况？如何处理Redis的穿透？2 考点分析缓存必问题，因为缓存雪崩和穿透，是缓存最大的两个问题，要么不出现，一旦出现就是致命的！3 缓存雪崩3.1 发生的现象3.2 缓存雪崩的解决方案事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃事中：本地ehcache缓...

3.2.2 Redis缓存（最佳）Redis是一个远程内存数据库（非关系型数据库），性能强劲，具有复制特性以及解决问题而生的独一无二的数据模型Redis内部使用一个redisObject对象来标识所有的key和value数据，redisObject最主要的信息:type代表一个value对象具体是何种数据类型encoding是不同数据类型在Redis内部的存储方式比如——type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或是int，如果是int则

各种社交软件里面都有附件的人的需求，在该应用中，我们查询附近 1 公里的食客，同时只需查询出 20 个即可。解决基于地理位置的搜索，很多数据库品牌都支持：MySQL、MongoDB、Redis 等都能支持地理位置的存储。当用户登录应用时，或者保持用户登录后用户在使用应用时，客户端是可以时刻获取用户位置信息的（前提是用户要开启位置获取的权限），客户端获取到最新的地理位置后，上传到后端服务器进行更新。当用户点击 Near Me 功能时，那么通过后台就可以以当前用户的位置为圆点，距离为半径查询相关的用户展

1 需求添加积分在用户签到的基础上添加用户积分，签到 1 天送 10 积分，连续签到 2 天送 20 积分，3 天送 30 积分，4 天以上均送 50 积分。积分排行榜2 表设计利用MySQL保存积分数据这类似于一张日志表，因此数据量很大，想要统计用户积分做排行榜时，表数据可能如下：3 实现TopN积分排行榜MySQL 方案统计 SQL 获取排行榜前二十，如果重复排名，则后一位就靠后业务逻辑缺点看上去实现简单，数据量小时运行也没大问题，但当数据量超过一定量后，就会

很多应用比如签到送积分、签到领取奖励：签到 1 天送 10 积分，连续签到 2 天送 20 积分，3 天送 30 积分，4 天以上均送 50 积分等如果连续签到中断，则重置计数，每月初重置计数显示用户某个月的签到次数在日历控件上展示用户每月签到情况，可以切换年月显示最简单的设计思路就是利用MySQL保存签到数据（t_user_sign），如下：字段名描述id数据表主键（AUTO_INCREMENT）fk_diner_id用户 IDsign_date签到日

1 简介朋友圈，微博，都是 Feed 流产品，还有图片分享网站 Pinterest，花瓣网等又是另一种形式的 Feed 流产品。很多 App 也都会有一个模块，叫动态或消息广场，这些也是 Feed 流产品。核心概念FeedFeed 流中的每一条状态或者消息。比如朋友圈中的一个状态就是一个 Feed，微博中的一条微博就是一个 Feed。Feed 流持续更新并呈现给用户内容的信息流。每个人的朋友圈，微博关注页等等都是一个 Feed 流。TimelineFeed 流的一种，微博，朋友圈都是 Ti