运维⾯试必问的中间件⾼频⾯试题（2021年最新版）
redis支持的数据结构
前⾔
本系列是我要进⼤⼚的第四篇⽂章
这些年互联⽹⽼⾟⼀直在⾯试⼀线，帮助⼩伙伴辅导⾯试准备及⾯试复盘，拿到过⼤⼤⼩⼩的offer，⽐如阿⾥，字节，美团，快⼿，百度等等
每次⾯试后我都会将⾯试的题⽬进⾏记录，并整理成⾃⼰的题库，最近我将这些题⽬整理出来，并按⼤⼚的标准给出⾃⼰的解析，希望在这⾦三银四的季节⾥，能助你⼀臂之⼒。
最近我花了⼏天时间整理了⼀些时下⾼频Linux运维⾯试题，并反复斟酌，给出了符合当前版本的解析，
这部分内容会收录在专栏《我要进⼤⼚》，适合所有有⼯作经验的⼩伙伴和应届毕业参加校招的⼩伙伴。
关于本篇
本篇是关于中间件相关的⾯试题，其实在⾯试的时候，你的简历⾥写的是中间件都会被问到，⽐如redis，memcache
有⼀些问题的答案因为在专栏《运维⾯试宝典》⾥有，为了避免重复，我会直接把链接粘贴上，⼤家可以跳转反复学习，有⼀些是《运维⾯试宝典》特有的，⽐如⾯试技巧，HR的问题以及业务和项⽬相关的。
正⽂
1. redis是单线程还是多线程？
这个问题已经被问过很多次了，从redis4.0开始引⼊多线程，redis 6.0 中，多线程主要⽤于⽹络 I/O 阶段，也就是接收命令和写回结果阶段，⽽在执⾏命令阶段，还是由单线程串⾏执⾏。由于执⾏时还是串⾏，因此⽆需考虑并发安全问题。
redis 中的多线程组不会同时存在“读”和“写”，这个多线程组只会同时“读”或者同时“写”
在 redis 6.0 之前，redis 的核⼼操作是单线程的。
因为 redis 是完全基于内存操作的，通常情况下CPU不会是redis的瓶颈，redis 的瓶颈最有可能是机器内存的⼤⼩或者⽹络带宽。
既然CPU不会成为瓶颈，那就顺理成章地采⽤单线程的⽅案了，因为如果使⽤多线程的话会更复杂，同时需要引⼊上下⽂切换、加锁等等，会带来额外的性能消耗。
⽽随着近些年互联⽹的不断发展，⼤家对于缓存的性能要求也越来越⾼了，因此 redis 也开始在逐渐往多线程⽅向发展。
2. redis常⽤的版本是？
redis5.0，redis6.0
3. redis 的使⽤场景？
缓存、分布式锁、排⾏榜（zset）、计数（incrby）、消息队列（stream）、地理位置（geo）、访客统计（hyperloglog）
4. redis常见的数据结构
常见的5种：
String：字符串，最基础的数据类型。
List：列表。
Hash：哈希对象。
Set：集合。
Sorted Set：有序集合，Set 的基础上加了个分值。
⾼级的2 种：
HyperLogLog：通常⽤于基数统计。使⽤少量固定⼤⼩的内存，来统计集合中唯⼀元素的数量。统计结果不是精确值，⽽是⼀个带有
0.81%标准差（standard error）的近似值。所以，HyperLogLog适⽤于⼀些对于统计结果精确度要求不是特别⾼的场景，例如⽹站
的UV统计。
Stream：主要⽤于消息队列，类似于 kafka，可以认为是 pub/sub 的改进版。提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每⼀个客户端的访问位置，还能保证消息不丢失。
5. redis持久化你们怎么做的？
redis持久化主要有两种 ROD和AOF，当先现在还有混合的，从reids4.0后引⼊的
RDB实现原理：
RDB类似于快照，在某个时间点，将 Redis 在内存中的数据库状态（数据库的键值对等信息）保存到磁盘⾥⾯。RDB 持久化功能⽣成的RDB ⽂件是经过压缩的⼆进制⽂件。
RDB的优点：
RDB⽂件是经过压缩的，占⽤空间很⼩，它保存了某个时间点的数据集，很适合做备份。 ⽐如你可以在24⼩时内，每个⼩时备份⼀次RDB⽂件，并且每个⽉的每⼀天备份⼀个RDB⽂件。
RDB⾮常适合⽤来做灾备恢复，可以加密后传送到数据中⼼
RDB可以最⼤化redis的性能
从恢复速度来看，RDB明显要⽐AOF要快
但是RDB也有⼀定的缺点：
RDB在服务器故障的时候，容易造成数据损失。 我们通常设置每5分钟保存⼀次快照，这样数据丢失也只有5分钟的数据。
RDB保存时使⽤fork⼦进程数据的持久化，如果数据量⼤的话，会⾮常耗时，造成redis停⽌处理服务N毫秒。
AOF：
保存 Redis 服务器所执⾏的所有写操作命令来记录数据库状态，并在服务器启动时，通过重新执⾏这些命令来还原数据集。
AOF默认是关闭的，可以通过appendonley yes 开启
AOF 持久化功能的实现可以分为三个步骤：命令追加、⽂件写⼊、⽂件同步。
AOF的优点：
1）AOF ⽐ RDB可靠。你可以设置不同的 fsync 策略：no、everysec 和 always。默认是 everysec，在这种配置下，redis 仍然可以保持良好的性能，并且就算发⽣故障停机，也最多只会丢失⼀秒钟的数据。
2）AOF⽂件是⼀个纯追加的⽇志⽂件。即使⽇志因为某些原因⽽包含了未写⼊完整的命令（⽐如写⼊时磁盘已满，写⼊中途停机等等），我们也可以使⽤ redis-check-aof ⼯具也可以轻易地修复这种问题。
3）当 AOF⽂件太⼤时，Redis 会⾃动在后台进⾏重写：重写后的新 AOF ⽂件包含了恢复当前数据集所需的最⼩命令集合。整个重写是绝对安全，因为重写是在⼀个新的⽂件上进⾏，同时 Redis 会继续往旧的⽂件追加数据。当新⽂件重写完毕，Redis 会把新旧⽂件进⾏切换，然后开始把数据写到新⽂件上。
4） AOF ⽂件有序地保存了对数据库执⾏的所有写⼊操作以 Redis 协议的格式保存， 因此 AOF ⽂件的内容⾮常容易被⼈读懂， 对⽂件进⾏分析（parse）也很轻松。如果你不⼩⼼执⾏了 FLUSHALL 命令把所有数据刷掉了，但只要 AOF ⽂件没有被重写，那么只要停⽌服务器， 移除 AOF ⽂件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执⾏之前的状态。
AOF缺点：
1） 对于相同的数据集，AOF的⽂件⼀般会⽐RDB⼤
2） AOF所使⽤的fsync策略，备份速度也会⽐RDB曼
如何使⽤：
如果想尽量保证数据安全性， 你应该同时使⽤ RDB 和 AOF 持久化功能，同时可以开启混合持久化。
如果想尽量保证数据安全性， 你应该同时使⽤ RDB 和 AOF 持久化功能，同时可以开启混合持久化。
如果你的数据是可以丢失的，则可以关闭持久化功能，在这种情况下，Redis 的性能是最⾼的。
6. 主从复制实现的原理
Redis虽然读取写⼊的速度都特别快，但是也会产⽣读压⼒特别⼤的情况，为分担读压⼒，Redis⽀持主从复制，Redis的主从结构可以采⽤⼀主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步
7. redis哨兵模式原理
哨兵是特殊的redis服务，不提供读写服务，主要⽤来监控redis实例节点。 哨兵架构下client端第⼀次从哨兵出redis的主节点，后续就直接访问redis的主节点，不会每次都通过 sentinel代理访问redis的主节点，当redis的主节点发⽣变化，哨兵会第⼀时间感知到，并且哨兵会早主从模式的从节点中重新选出来⼀个新的master，并且将新的master信息通知给client端。
这⾥⾯redis的client端⼀般都实现了订阅功能，订阅sentinel发布的节点变动消息。Redis服务是通过配置⽂件启动的，⽐如上⾯的从节点设置了只读模式，它被选举成了master之后就是可读写的了，感觉很奇怪，后来看了下重新选举之后的各redis服务的配置⽂件，发现⽂件⾥⾯的内容会被哨兵修改。要想真的⾼可⽤，我们的哨兵也要集模式。
8. memcache和redis的区别
1、 Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可⽤于缓存其他东西，例如图⽚、视频等等。
2、Redis不仅仅⽀持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。
3、虚拟内存–Redis当物理内存⽤完时，可以将⼀些很久没⽤到的value 交换到磁盘
4、过期策略–memcache在set时就指定，例如set key1 0 0 8，即永不过期。Redis可以通过例如expire 设定，例如expire name 10
5、分布式–设定memcache集，利⽤magent做⼀主多从;redis可以做⼀主多从。都可以⼀主⼀从
6、存储数据安全–memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）
7、灾难恢复–memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复
8、Redis⽀持数据的备份，即master-slave模式的数据备份。
redis和memecache的不同在于[2]：
1、存储⽅式：
memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存⼤⼩
redis有部份存在硬盘上，这样能保证数据的持久性，⽀持数据的持久化（笔者注：有快照和AOF⽇志两种持久化⽅式，在实际应⽤的时候，要特别注意配置⽂件快照参数，要不就很有可能服务器频繁满载做dump）。
2、数据⽀持类型：
redis在数据⽀持上要⽐memecache多的多。
3、使⽤底层模型不同：
新版本的redis直接⾃⼰构建了VM 机制 ，因为⼀般的系统调⽤系统函数的话，会浪费⼀定的时间去移动和请求。
4、运⾏环境不同：
redis⽬前官⽅只⽀持LINUX 上去⾏，从⽽省去了对于其它系统的⽀持，这样的话可以更好的把精⼒⽤于本系统 环境上的优化，虽然后来微软有⼀个⼩组为其写了补丁。但是没有放到主⼲上
个⼈总结⼀下，有持久化需求或者对数据结构和处理有⾼级要求的应⽤，选择redis，其他简单的key/value存储，选择memcache。
9. redis有哪些架构模式？
存在问题： 内容容量有限，处理能⼒有限，⽆法⾼可⽤
Redis 的复制（replication）功能允许⽤户根据⼀个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），⽽通过复制创建出来的服务器复制品则为从服务器（slave）。 只要主从服务器之间的⽹络连接正常，主从服务器两者会具有相同的数据，主服务器就会⼀直将发⽣在⾃⼰⾝上的数据更新同步 给从服务器，从⽽⼀直保证主从服务器的数据相同。
特点：
1、master/slave ⾓⾊
2、master/slave 数据相同
3、降低 master 读压⼒在转交从库
问题：
⽆法保证⾼可⽤
没有解决 master 写的压⼒
Redis sentinel 是⼀个分布式系统中监控 redis 主从服务器，并在主服务器下线时⾃动进⾏故障转移。其中三个特性：
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应⽤程序发送通知。⾃动故障迁移（Automatic failover）： 当⼀个主服务器不能正常⼯作时， Sentinel 会开始⼀次⾃动故障迁移操作。
特点：
1、保证⾼可⽤
2、监控各个节点
3、⾃动故障迁移
缺点：主从模式，切换需要时间丢数据
没有解决 master 写的压⼒

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。