Redis 常见面试知识点小结，2024年最新字节跳动架构师面试题

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

3. 支持复制、Lua脚本、LRU淘汰、事务

4. 基于Sentinel实现高可用

5. Cluster模式支持自动分区

Redis使用场景

Redis使用场景主要有缓存、排行榜、计数器、分布式会话、分布式锁、社交网络、最新列表、消息系统等。

▐  缓存

对于有状态的服务而言，数据库往往会成为系统的瓶颈所在。在用户活跃的高峰期，或者由于PUSH、活动等引发的请求突增，都会给后端的数据库造成巨大的压力。

由存储系统的特性我们知道，从内存读一个数据，比从一般的磁盘读要快10000倍左右，基于这样的原因，数据库本身也会有一定的内存cache。但是当热数据集比较大的时候，本地cache会频繁淘汰，此时会触发大量磁盘IO，性能急剧下降，往往也会伴随有大量的慢日志。另外，有些数据是需要通过复杂的查询或计算后得到且又不会频繁变化的。

虽说数据库可以通过读写分离来扩展读的能力，但存在增加slave实例的成本、主从延迟导致数据不一致等问题。于是我们考虑在系统中再增加一个cache层，此时Redis就能够帮我们解决这样的缓存需求。

▐  排行榜

很多网站都有排行榜应用，如淘宝的月度销量榜单、商品按时间的上新排行等。Redis提供的有序集合数据类构能实现各种复杂的排行榜应用。

▐  计数器

什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得+1，并发量高时如果每次都请求数据库操作无疑会对数据库提出挑战。Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景。

▐  分布式会话

集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。

▐  分布式锁

在很多互联网公司中都使用了分布式技术，分布式技术带来的技术挑战是对同一个资源的并发访问，如全局ID、减库存、秒杀等场景，并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现，但在并发量高的场合中，利用数据库锁来控制资源的并发访问是不太理想的，大大影响了数据库的性能。可以利用Redis的setnx功能来编写分布式的锁，如果设置返回1说明获取锁成功，否则获取锁失败，实际应用中要考虑的细节要更多。

▐  社交网络

点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据，Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。

▐  最新列表

Redis列表结构，LPUSH可以在列表头部插入一个内容ID作为关键字，LTRIM可用来限制列表的数量，这样列表永远为N个ID，无需查询最新的列表，直接根据ID去到对应的内容页即可。

▐  消息系统

消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

Redis 性能

Redis虽然是单进程单线程模型，但是读写性能非常优异，单机可支持10wQPS，原因主要有以下几点：

1. 纯内存操作，避免了与磁盘的交互

2. 用hash table作为键空间，查找任意的key只需O(1)

3. 单线程，天生的队列模式，避免了因多线程竞争而导致的上下文切换和抢锁的开销

4. 事件机制，Redis服务器将所有处理的任务分为两类事件，一类是采用I/O多路复用处理客户端请求的网络事件；一类是处理定时任务的时间事件，包括更新统计信息、清理过期键、持久化、主从同步等；

当然这种单线程事件机制也是有缺陷的，由于所有的事件都是串行执行，一旦某个事件比较重就会阻塞其它事件，从而导致整个系统的吞吐率下降。比如某个客户端执行了一个比较重的lua函数、或者使用了诸如keys*、zrange(0,-1)、hgetall等全集合扫描的操作，又或者删除的过期键是个big key，又或者使用了较多内存的redis实例进行bgsave时，都会导致服务器一定程度的阻塞，一般伴随会有相应的慢日志。所以我们在实际使用redis的过程中，必须要给每一次的操作分配合理的时间片。

Redis持久化

对于内存型数据库，比如redis和memcache，如果数据状态不落盘，一旦服务器进程退出，那么这些数据状态也就会全部消失不见。数据状态的重建需要从后端数据库回源，这会给后端数据库造成非常大的压力，最坏的情况可能会把数据库压垮，导致服务不可用。

为了解决这个问题，Redis提供了RDB和AOF两种持久化方式。前者会生成一份内存快照–RDB文件，该文件是经过压缩的二进制格式，记录的是键值对数据；后者则是以Redis的命令请求协议格式来保存，记录的是命令操作；

1. RDB的特点，文件体积小，加载速度快；但因为是对整个实例的内存生成快照，所以操作比较重，一般持久化的间隔不宜太快，所以保存的数据相对比较旧一些；

2. AOF的特点，文件体积较大（可以用AOF重写进行覆盖）；所有的写操作会追加到AOF缓冲区，持久化的行为可配置，分为三种，always（每次刷盘）、everysec（异步线程每隔1秒刷一次）和no（只写到page cache，交给操作系统来刷盘）；相对来说，AOF文件数据保存的比较新一些，所以如果开启了AOF，那么Redis服务器恢复的时候会优先加载AOF文件。

由于RDB SAVE和AOF重写会阻塞主线程，所以都支持BG模式执行，至于持久化的具体实现这里就不展开讨论了。

Redis丰富的数据类型

比较巧妙的是，Redis并没有使用固定的数据结构来存储各种类型的数据，而是创建了一套对象系统，对于同一个对象，可以对应一个或多个不同的底层数据结构（或者叫做编码方式），某些特定的编码方式在时空间的效率上有所优化，通过执行"Object Encoding"可以查询当前编码方式。

1. String 字符串对象，最大可支持512MB，memcache最大只支持1MB。编码可以是int，raw或者embstr，int对应整型数据，可方便计数，embstr用来保存长度小于等于39字节的字符串值，采用连续的空间进行存储，更好利用缓存优势；字符串对象常用来进行计数，或者缓存序列化的对象；

2. List 列表对象，编码可以是ziplist或linkedlist，ziplist是为了节约内存而开发的，是一个经过特殊编码的连续内存块组成的顺序结构，当列表对象元素的个数较少以及元素的长度较短时会采用这种方式；列表对象一般可用来实现消息队列；

3. Hash 哈希对象，编码可以是ziplist或hashtable，在Redis的实现里，采用的链式冲突来解决冲突问题，并且为了维护hash表的负载因子在一个合理的范围，会执行渐进式rehash；哈希对象一般用于存储某个对象的属性数据，便于选择性查询，这个效率要比粗暴的序列化和反序列化要高很多，比如用户的个人资料；另一个用法，则是利用ziplist编码方式实现压缩存储，节省内存；

4. Set 集合对象，编码可以是intset或hashtable，当集合的元素不多且都是整数时，Redis就会使用整数集intset，底层是一个以有序、无重复的方式进行排列的数组，能有效的节约内存；这个对象一般用于去重，比如派奖；

5. Sorted Set 有序集合对象，编码可以是ziplist或者skiplist，跳跃表skiplist是一种查找效率可媲美平衡树的数据结构，平均O(logN)，最坏O(N)，而且实现更加简单；其实，Redis用了skiplist和hashtable两种数据结构来实现zset，一方面hashtable能实现O(1)的查找，另一方面skiplist实现了有序，可支持范围查找；有集合序对象用的就比较广泛了，比如排行榜（只要是排序相关的列表都可以）、延迟任务队列等。

Redis的高可用

Redis的高可用，主要通过主从复制机制以及Sentinel集群来实现。

1. 主从复制 分为两个阶段，首先，当从服务器发起SYNC命令后，主服务器会生成最新的RDB文件发送给从服务器，并使用一个缓冲区来记录从此刻开始主服务器执行的所有写命令；待RDB文件传输完之后，再将该缓冲区的数据再发送给从服务器，这样就完成了复制。旧的Redis版本有个缺陷是，如果在第二个阶段发生失败，需要从第一个阶段重新开始同步，而这个阶段的操作会消耗大量的CPU、内存和磁盘I/O以及网络带宽资源，太过耗费资源。所以从2.8版本开始，实现了部分重同步，通过主从服务器各维护一个复制偏移量来实现。

2. Sentinel 由一个或多个Sentinel实例组成的哨兵系统，可以监视任意多个主从服务器，并完成Failover的操作。Sentinal其实是一个运行在特殊模式下的Redis服务器，运行期间，会与各服务器建立网络连接，以检测服务器的状态；同时会与其它Sentinel服务器创建连接，完成信息交换，比如发现某个主服务器心跳异常时，会互相询问心跳结果，当超过一定数量时即可判定为客观下线；一旦主服务器被判定为客观下线状态，那么Sentinel集群会通过raft协议选举，选出一个Leader来执行Failover。

3. Failover 一般来说，会先选出优先级最高的从服务器，然后再从中选出复制偏移量最大的实例，作为新的主服务器；最后将其它从和旧的主都切换为新主的从。

当从服务器有2个或者多个时，Redis的主从架构可以有两种形式。一种是，所有的从服务器直接挂在主服务器上，这种模式的优点是，所有从服务器复制的延迟相对较低，而缺点在于加大了主服务器的复制压力；另一种形式，是采用级联的方式，S1从M复制，S2从S1复制，以此类推，这种模式的优点是，将主服务器的复制压力分摊到多个服务器上，而缺点在于越处于级联下游的从实例，复制延迟就越大。

从主从复制模式可以看出，Redis的数据只能保证最终一致，不能保证强一致性。

Redis的扩展性

读扩展，基于主从架构，可以很好的平行扩展读的能力。写扩展，主要受限于主服务器的硬件资源的限制，一是单个实例内存容量受限，二是一个实例只使用到CPU一个核。下面讨论基于多套主从架构Redis实例的集群实现，目前主要有以下几种方案：

1. 客户端分片 实现方案，业务进程通过对key进行hash来分片，用Sentinel做failover。优点：运维简单，每个实例独立部署；可使用lua脚本，业务进程执行的key均hash到同一个分片即可；缺点：一旦重新分片，由于数据无法自动迁移，部分数据需要回源；

2. Redis集群 是官方提供的分布式数据库方案，通过分片实现数据共享，并提供复制和failover。按照16384个槽位进行分片，且实例之间共享分片视图。优点：当发生重新分片时，数据可以自动迁移；缺点：客户端需要升级到支持集群协议的版本；客户端需要感知分片实例，最坏的情况，每个key需要一次重定向；不支持lua脚本；不支持pipeline；

3. Codis 是由豌豆荚团队开源的一款分布式组件，它将分布式的逻辑从Redis集群剥离出来，交由几个组件来完成，与数据的读写解耦。Codis proxy负责分片和聚合，dashboard作为管理后台，zookeeper做配置管理，Sentinel做failover。优点：底层透明，客户端兼容性好；重新分片时，数据可自动迁移；支持pipeline；支持lua脚本，业务进程保证执行的key均hash到同一个分片即可；缺点：运维较为复杂；引入了中间层；

Redis使用误区

本次面试答案，以及收集到的大厂必问面试题分享：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
425346107)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-SaamiYO1-1713425346107)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！