JavaEdge全是干货的技术号

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实例需保证AOF日志中的操作记录已落盘，这个操作虽需实例等待，但并不会返回具体数据结果给实例。因为若Redis内存超过maxmemory，再写入数据时，Redis返回的结果是OOM error，这种情况下，客户端需要感知有错误发生才行。若客户端不关心返回值，只关心数据是否写成功，则SET/HSET/SADD都不算关键路径，多次执行这些命令都是幂等的，这时可放到异步线程。Redis读肯定都是关键路径操作，因为客户端发起读请求后，就会等待返回读取数据，再处理后续。

为避免阻塞式操作，Redis提供异步线程机制：Redis会启动一些子线程，把一些任务移交子线程，让它们在后台处理。但若使用Redis Cluster，且同时正好迁移大key，就会阻塞主线程，因Redis Cluster使用的同步迁移。一个同步写盘操作耗时大约1～2ms，若大量写操作需记录在AOF日志，并同步写回，就会阻塞主线程。但对从库，它在接收了RDB文件后，需使用FLUSHDB命令清空当前数据库，恰好撞车三大阻塞点。从库在清空当前数据库后，还要把RDB文件载入内存，RDB文件越大，加载越慢。

要尽可能避免性能异常场景，还要做好异常应对方案。本文研究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之后，节点之间通过去中心化的方式，提供了完整

1 概述数据结构和内部编码Redis 没有传统关系型数据库的Table 模型schema 所对应的db仅以编号区分。同一个db 内，key 作为顶层模型，它的值是扁平化的。也就是说db 就是key的命名空间key的定义通常以“:” 分隔，如：Article:Count:1我们常用的Redis数据类型有：string、list、set、map、sorted-setredisObject通用结构Redis中的所有value 都是以object 的形式存在的，其通用结构如下typedef st

缓存读写操作，很多人不假思索：先读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

好友相关的功能至少包含关注 / 取关我（他）的关注我（他）的粉丝共同关注我关注的人也关注他这样的功能如果采用数据库，只是单纯得到用户的一些粉丝或者关注列表，也很简单、易实现，但若我想查出两个甚至多个用户共同关注人或想查询两个或者多个用户的共同粉丝，就会很麻烦，效率也不会很高。但如果用 redis 去做的话就会相当的简单且高效。因为 redis 自己本身带有专门针对于这种集合的交集、并集、差集的一些操作。总体思路我们采用 MySQL + Redis 的方式结合完成。MySQL 保存落地

接着第⼀个线程进⼊ inc() ⽅法，由于同⼀进程，所以不会进⼊ while ⽽挂起，接着增量 lockedCount，当第⼆个线程尝试 lock，由于 isLocked=true, 所以他不会获取该锁，直到第⼀个线程调⽤两次 unlock() 将 lockCount 递减为 0，才将标记为 isLocked 设置为 false。重⼊锁，是以线程为单位，当⼀个线程获取对象锁后，该线程还可再次获取该对象上的锁，⽽其它线程不可以。线程请求⼀个未被占有的锁时，JVM将记录锁的占有者，并将请求计数器置1。

商品和订单服务间使用MQ商品服务的库存变化时，通过 MQ 通知订单服务库存变化。原始的同步流程查询商品信息 (调用商品服务)计算总价(生成订单详情)商品服务扣库存(调用商品服务)订单入库( 生成订单)在订单生成时直接扣库存，这是最原始的扣库存方案，比较简单，但存在一系列问题：可能导致很多订单把产品库存扣除而未支付，这就需要有一个后台脚本，将一段时间内没有支付的订单的库存释放，把订单取消即时扣库存，并发差1、3步商品服务，操作商品服务的 db，2、4步订单服务，操作订单服务的 db