运维面试必问的中间件高频面试题（2021年最新版）

桃扇骨 2022-11-18 01:44 387阅读 0赞

## 前言 ##

本系列是我要进大厂的第四篇文章  
这些年互联网老辛一直在面试一线，帮助小伙伴辅导面试准备及面试复盘，拿到过大大小小的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服务的配置文件，发现文件里面的内容会被哨兵修改。要想真的高可用，我们的哨兵也要集群模式。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70]

### 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有哪些架构模式？ ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 1]  
存在问题： 内容容量有限，处理能力有限，无法高可用

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 2]  
Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品则为从服务器（slave）。 只要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步 给从服务器，从而一直保证主从服务器的数据相同。

特点：

1、master/slave 角色

2、master/slave 数据相同

3、降低 master 读压力在转交从库

问题：

无法保证高可用

没有解决 master 写的压力

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 3]

Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。

特点：

1、保证高可用

2、监控各个节点

3、自动故障迁移

缺点：主从模式，切换需要时间丢数据

没有解决 master 写的压力

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 4]  
Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器； Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII 协议和 redis 协议。

特点：1、多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins

2、支持失败节点自动删除

3、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致

缺点：增加了新的 proxy，需要维护其高可用。

failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手动干预

### 10. 缓存雪崩？ ###

在前面学习我们都知道Redis不可能把所有的数据都缓存起来(内存昂贵且有限)，所以Redis需要对数据设置过期时间，并采用的是惰性删除+定期删除两种策略对过期键删除。Redis对过期键的策略+持久化

如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中

什么是缓存雪崩？  
Redis挂掉了，请求全部走数据库。

对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。

缓存雪崩如果发生了，很可能就把我们的数据库搞垮，导致整个服务瘫痪！

解决方法：

解决方法：在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。

对于“Redis挂掉了，请求全部走数据库”这种情况，我们可以有以下的思路：

事发前：实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster)，尽量避免Redis挂掉这种情况发生。

事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)

事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。

### 11. 缓存穿透 ###

**什么是缓存穿透**  
缓存穿透是指查询一个一定不存在的数据。由于缓存不命中，并且出于容错考虑，如果从数据库查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，失去了缓存的意义  
请求的数据在缓存大量不命中，导致请求走数据库。  
缓存穿透如果发生了，也可能把我们的数据库搞垮，导致整个服务瘫痪！

**如何解决缓存穿透**  
由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截，不合法就不让这个请求到数据库层！

当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。

这种情况我们一般会将空对象设置一个较短的过期时间。

### 12. 缓存击穿 ###

某一个热点key，在不停地扛着高并发，当这个热点key在失效的一瞬间，持续的高并发访问就击破缓存直接访问数据库，导致数据库宕机。

设置热点数据"永不过期" 加上互斥锁：上面的现象是多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它 其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后将数据放到redis缓存起来。  
后面的线程进来发现已经有缓存了，就直接走缓存

总结：  
雪崩是大面积的key缓存失效；穿透是redis里不存在这个缓存key；击穿是redis某一个热点key突然失效，最终的受害者都是数据库。

### 13. redis为什么这么快 ###

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路 I/O 复用模型，非阻塞 IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求

### 14. memcache有哪些应用场景 ###

作为数据库的前端缓存应用： 完整缓存，静态缓存。  
比如 商品分类，商品信息

### 15. memcache 服务特点及工作原理 ###

a. 完全基于内存缓存的  
b、节点之间相互独立  
c、C/S模式架构，C语言编写，总共2000行代码。  
d、异步Ｉ/O 模型，使用libevent作为事件通知机制。  
e、被缓存的数据以key/value键值对形式存在的。  
f、全部数据存放于内存中，无持久性存储的设计，重启服务器，内存里的数据会丢失。  
g、当内存中缓存的数据容量达到启动时设定的内存值时，就自动使用LRU算法删除过期的缓存数据。  
h、可以对存储的数据设置过期时间，这样过期后的数据自动被清除，服务本身不会监控过期，而是在访问的时候查看key的时间戳,判断是否过期。  
j、memcache会对设定的内存进行分块，再把块分组，然后再提供服务

### 16. memcached是如何做身份验证的？ ###

没有身份认证机制，如果你想限制访问，可以使用防火墙

### 17. mongoDB是什么？ ###

MongoDB是一个文档数据库，提供好的性能，领先的非关系型数据库。采用BSON存储文档数据。  
BSON（）是一种类json的一种二进制形式的存储格式，简称Binary JSON.  
相对于json多了date类型和二进制数组。

### 18. mongodb的优势 ###

面向文档的存储：以 JSON 格式的文档保存数据。  
任何属性都可以建立索引。  
复制以及高可扩展性。  
自动分片。  
丰富的查询功能。  
快速的即时更新。

### 19. mongodb使用场景 ###

大数据  
内容管理系统  
移动端Apps  
数据管理

### 20. kafka 中的ISR，AR代表什么，ISR伸缩又代表什么 ###

ISR:In-Sync Replicas 副本同步队列  
AR:Assigned Replicas 所有副本  
ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

### 21.kafka中的broker 是干什么的 ###

broker 是消息的代理，Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。

### 22. kafka中的 zookeeper 起到什么作用，可以不用zookeeper么 ###

zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖，

但是broker依然依赖于ZK，zookeeper 在kafka中还用来选举controller 和 检测broker是否存活等等

### 23. kafka follower如何与leader同步数据 ###

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。

而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

### 24. kafka 为什么那么快 ###

*  Cache Filesystem Cache PageCache缓存
 *  顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。
 *  Zero-copy 零拷技术减少拷贝次数
 *  Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。
 *  Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。

### 25. Kafka中的消息是否会丢失和重复消费？ ###

要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。

1、消息发送

Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.required.acks属性来确认消息的生产：

0—表示不进行消息接收是否成功的确认；  
1—表示当Leader接收成功时确认；  
\-1—表示Leader和Follower都接收成功时确认；  
综上所述，有6种消息生产的情况，下面分情况来分析消息丢失的场景：

（1）acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；

（2）acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

2、消息消费

Kafka消息消费有两个consumer接口，Low-level API和High-level API：

Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；

High-level API：封装了对parition和offset的管理，使用简单；

如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“诡异”的消失了；

解决办法：

针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；
    
        针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。

### 26. 为什么Kafka不支持读写分离？ ###

在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型  
Kafka 并不支持主写从读，因为主写从读有 2 个很明 显的缺点:

(1)数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间 窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。

(2)延时问题。类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经 历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。

### 27. 什么是消费者组? ###

消费者组是 Kafka 独有的概念，如果面试官问这 个，就说明他对此是有一定了解的。我先给出标准答案：  
1、定义：即消费者组是 Kafka 提供的可扩展且具有容错性的消费者机制。  
2、原理：在 Kafka 中，消费者组是一个由多个消费者实例 构成的组。多个实例共同订阅若干个主题，实现共同消费。同一个组下的每个实例都配置有 相同的组 ID，被分配不同的订阅分区。当某个实例挂掉的时候，其他实例会自动地承担起 它负责消费的分区。

此时，又有一个小技巧给到你:消费者组的题目，能够帮你在某种程度上掌控下面的面试方  
向。

如果你擅长位移值原理，就不妨再提一下消费者组的位移提交机制;  
如果你擅长 Kafka Broker，可以提一下消费者组与 Broker 之间的交互;  
如果你擅长与消费者组完全不相关的 Producer，那么就可以这么说:“消费者组要消 费的数据完全来自于 Producer 端生产的消息，我对 Producer 还是比较熟悉的。”

### 28. Kafka 中的术语 ###

*  代理（borker）: 一个kafka进程（kafka进程又被称为实例），被称为一个代理broker节点。
 *  生产者（producer）

Producer将消息记录发送到Kafka集群指定的主题（Topic）中进行存储，同时生产者（Producer）也能通过自定义算法决定将消息记录发送到哪个分区（Partition）。  
例如，通过获取消息记录主键（Key）的哈希值，然后使用该值对分区数取模运算，得到分区索引。

*  消费者Consumer  
    消费者（Consumer）从Kafka集群指定的主题（Topic）中读取消息记录。在读取主题数据时，需要设置消费组名（GroupId）。如果不设置，则Kafka消费者会默认生成一个消费组名称。
 *  消费者组： Consumer Group  
    消费者程序在读取Kafka系统主题（Topic）中的数据时，通常会使用多个线程来执行。一个消费者组可以包含一个或多个消费者程序，使用多分区和多线程模式可以极大提高读取数据的效率。

一般而言，一个消费者对应一个线程

*  主题Topic  
    Kafka系统通过主题来区分不同业务类型的消息记录。例如，用户登录数据存储在主题A中，用户充值记录存储在主题B中，则如果应用程序只订阅了主题A，而没有订阅主题B，那该应用程序只能读取主题A中的数据
 *  分区（Partition）  
    每一个主题（Topic）中可以有一个或者多个分区（Partition）。在Kafka系统的设计思想中，分区是基于物理层面上的，不同的分区对应着不同的数据文件。Kafka通过分区（Partition）来支持物理层面上的并发读写，以提高Kafka集群的吞吐量。

一个分区只对应一个代理节点（Broker），一个代理节点可以管理多个分区。

*  副本（replication）  
    在Kafka系统中，每个主题（Topic）在创建时会要求指定它的副本数，默认是1。通过副本（Replication）机制来保证Kafka分布式集群数据的高可用性  
    在创建主题时，主题的副本系数值应如下设置：（1）若集群数量大于等于3，则主题的副本系数值可以设置为3；（2）若集群数量小于3，则主题的副本系数值可以设置为小于等于集群数量值。例如，集群数为2，则副本系数可以设置为1或者2；集群数为1，则副本系数只能设置为1。
 *  记录（Record）  
    被实际写入到Kafka集群并且可以被消费者应用程序读取的数据，被称为记录（Record）。每条记录包含一个键（Key）、值（Value）和时间戳（Timestamp）。
 *  replica：  
    partition 的副本，保障 partition 的高可用。
 *  leader：  
    replica 中的一个角色， producer 和 consumer 只跟 leader 交互。
 *  follower：  
    replica 中的一个角色，从 leader 中复制数据。
 *  controller：  
    kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover。
 *  zookeeper：  
    kafka 通过 zookeeper 来存储集群的 meta 信息。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 5]  
    生产者（Producer）负责写入消息数据。将审计日志、服务日志、数据库、移动App日志，以及其他类型的日志主动推送到Kafka集群进行存储。·

消费者（Consumer）负责读取消息数据。例如，通过Hadoop的应用接口、Spark的应用接口、Storm的应用接口、ElasticSearch的应用接口，以及其他自定义服务的应用接口，主动拉取Kafka集群中的消息数据。

### 29. kafka适用于哪些场景 ###

1.  日志收集
2.  消息系统
3.  用户轨迹（记录浏览器用户或者app用户产生的各种记录，点击和搜索浏览等）
4.  记录运营监控数据
5.  实现流处理

### 30. Kafka写入流程： ###

1.producer 先从 zookeeper 的 “/brokers/…/state” 节点找到该 partition 的 leader

1.  producer 将消息发送给该 leader
2.  leader 将消息写入本地 log
3.  followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK
4.  leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK

### 总结 ###

后面还会继续补充，这些建议大家以redis为主。关于中间件的面试，主要看你的简历里有没有写，你写了kafka，那肯定是要问的。  
欢迎各位大佬，点赞收藏，一起加油进步

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70]: /images/20221022/16f9a572a87a41a48124043c7ae8ca17.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 1]: /images/20221022/fb4da9813ef0493a949323a923cc3eeb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 2]: /images/20221022/bbbbef5feaf042ca85307623867b778e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 3]: /images/20221022/7e73524ba7014e08a93aceebbd53690a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 4]: /images/20221022/268e0f71da3547329060d310451ff0ab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbnNodXpoYW4_size_16_color_FFFFFF_t_70 5]: /images/20221022/cd24cd2547aa43d0b2fc27cf5ed2df5a.png