史上最全的微服务专业术语面试50问，聪明人已经收藏了！

￡神魔★判官ぃ 2021-07-20 18:00 268阅读 0赞

### 前言 ###

String 类型是我们使用最频繁的数据类型，没有之一。那么提高 String 的运行效率，无疑是提升程序性能的最佳手段。

我们本文将从 String 的源码入手，一步步带你实现字符串优化的小目标。**不但教你如何有效的使用字符串，还为你揭晓这背后的深层次原因**。

本文涉及的知识点，如下图所示：

![ee8c6e2ff5960839fe89c947871795de.png][]

在看如何优化 String 之前，我们先来了解一下 String 的特性，毕竟知己知彼，才能百战不殆。

### Kafka的多副本冗余设计 ###

不管是传统的基于关系型数据库设计的系统，还是分布式的如`zookeeper`、`redis`、`Kafka`、`HDFS`等等，实现高可用的办法通常是采用冗余设计，通过冗余来解决节点宕机不可用问题。

首先简单了解Kafka的几个概念：

*  **物理模型**

![4925ff0b41f34791ae582771af408623.png][]

*  **逻辑模型**

![729a4ea37cce847c039dec4140c7a5ad.png][]

*  **Broker**（节点）：Kafka服务节点，简单来说一个`Broker`就是一台Kafka服务器，一个物理节点。
 *  **Topic**（主题）：在Kafka中消息以主题为单位进行归类，每个主题都有一个`Topic Name`，生产者根据Topic Name将消息发送到特定的Topic，消费者则同样根据Topic Name从对应的Topic进行消费。
 *  **Partition**（分区）：`Topic`（主题）是消息归类的一个单位，但每一个主题还能再细分为一个或多个`Partition`（分区），一个分区只能属于一个主题。主题和分区都是逻辑上的概念，举个例子，消息1和消息2都发送到主题1，它们可能进入同一个分区也可能进入不同的分区（所以同一个主题下的不同分区包含的消息是不同的），之后便会发送到分区对应的Broker节点上。
 *  **Offset**（偏移量）：分区可以看作是一个只进不出的队列（Kafka只保证一个分区内的消息是有序的），消息会往这个队列的尾部追加，每个消息进入分区后都会有一个偏移量，标识该消息在该分区中的位置，消费者要消费该消息就是通过偏移量来识别。

其实，根据上述的几个概念，是不是也多少猜到了Kafka的多副本冗余设计实现了？别急，咱继续往下看。

在Kafka 0.8版本以前，是没有多副本冗余机制的，一旦一个节点挂掉，那么这个节点上的所有`Partition`的数据就无法再被消费。这就等于发送到Topic的有一部分数据丢失了。

在0.8版本后引入副本记者则很好地解决宕机后数据丢失的问题。副本是以`Topic`中每个`Partition`的数据为单位，每个Partition的数据会同步到其他物理节点上，形成多个副本。

每个`Partition`的副本都包括一个`Leader`副本和多个`Follower`副本，Leader由所有的副本共同选举得出，其他副本则都为Follower副本。在生产者写或者消费者读的时候，都只会与Leader打交道，在写入数据后Follower就会来拉取数据进行数据同步。

![995bc99834e0e33141d69cd3e0620333.png][]

就这么简单？是的，基于上面这张多副本架构图就实现了Kafka的高可用。当某个`Broker`挂掉了，甭担心，这个`Broker`上的`Partition`在其他`Broker`节点上还有副本。你说如果挂掉的是`Leader`怎么办？那就在`Follower`中在选举出一个`Leader`即可，生产者和消费者又可以和新的`Leader`愉快地玩耍了，这就是高可用。

你可能还有疑问，那要多少个副本才算够用？Follower和Leader之间没有完全同步怎么办？一个节点宕机后Leader的选举规则是什么？

直接抛结论:

**多少个副本才算够用？** 副本肯定越多越能保证Kafka的高可用，但越多的副本意味着网络、磁盘资源的消耗更多，性能会有所下降，通常来说副本数为3即可保证高可用，极端情况下将`replication-factor`参数调大即可。

**Follower和Lead之间没有完全同步怎么办？** Follower和Leader之间并不是完全同步，但也不是完全异步，而是采用一种`ISR`机制（`In-Sync Replica`）。每个Leader会动态维护一个ISR列表，该列表里存储的是和Leader基本同步的Follower。如果有Follower由于网络、GC等原因而没有向Leader发起拉取数据请求，此时Follower相对于Leader是不同步的，则会被踢出ISR列表。所以说，ISR列表中的Follower都是跟得上Leader的副本。

**一个节点宕机后Leader的选举规则是什么？** 分布式相关的选举规则有很多，像Zookeeper的`Zab`、`Raft`、`Viewstamped Replication`、微软的`PacificA`等。而Kafka的Leader选举思路很简单，基于我们上述提到的`ISR`列表，当宕机后会从所有副本中顺序查找，如果查找到的副本在ISR列表中，则当选为Leader。另外还要保证前任Leader已经是退位状态了，否则会出现脑裂情况（有两个Leader）。怎么保证？Kafka通过设置了一个controller来保证只有一个Leader。

### Ack参数决定了可靠程度 ###

另外，这里补充一个面试考Kafka高可用必备知识点：`request.required.asks`参数。

Asks这个参数是生产者客户端的重要配置，发送消息的时候就可设置这个参数。该参数有三个值可配置：**0、1、All**。

**第一种是设为0**，意思是生产者把消息发送出去之后，之后这消息是死是活咱就不管了，有那么点发后即忘的意思，说出去的话就不负责了。不负责自然这消息就有可能丢失，那就把可用性也丢失了。

**第二种是设为1**，意思是生产者把消息发送出去之后，这消息只要顺利传达给了Leader，其他Follower有没有同步就无所谓了。存在一种情况，Leader刚收到了消息，Follower还没来得及同步Broker就宕机了，但生产者已经认为消息发送成功了，那么此时消息就丢失了。注意，**设为1是Kafka的默认配置**！！！可见Kafka的默认配置也不是那么高可用，而是对高可用和高吞吐量做了权衡折中。

**第三种是设为All（或者-1）**，意思是生产者把消息发送出去之后，不仅Leader要接收到，ISR列表中的Follower也要同步到，生产者才会任务消息发送成功。

进一步思考，`Asks=All`就不会出现丢失消息的情况吗？答案是否。当ISR列表只剩Leader的情况下，`Asks=All`相当于`Asks=1`，这种情况下如果节点宕机了，还能保证数据不丢失吗？因此只有在`Asks=All`并且有ISR中有两个副本的情况下才能保证数据不丢失。

### 解决问题 ###

绕了一大圈，了解了Kafka的高可用机制，终于回到我们一开始的问题本身，`Kafka`的一个节点宕机后为什么不可用？

我在开发测试环境配置的`Broker`节点数是3，`Topic`是副本数为3，`Partition`数为6，`Asks`参数为1。

当三个节点中某个节点宕机后，集群首先会怎么做？没错，正如我们上面所说的，集群发现有Partition的Leader失效了，这个时候就要从ISR列表中重新选举Leader。如果ISR列表为空是不是就不可用了？并不会，而是从Partition存活的副本中选择一个作为Leader，不过这就有潜在的数据丢失的隐患了。

所以，只要将Topic副本个数设置为和Broker个数一样，Kafka的多副本冗余设计是可以保证高可用的，不会出现一宕机就不可用的情况（不过需要注意的是Kafka有一个保护策略，当一半以上的节点不可用时Kafka就会停止）。那仔细一想，Kafka上是不是有副本个数为1的Topic？

问题出在了`__consumer_offset`上，`__consumer_offset`是一个Kafka自动创建的`Topic`，用来存储消费者消费的`offset`（偏移量）信息，默认`Partition`数为50。而就是这个Topic，它的默认副本数为1。如果所有的`Partition`都存在于同一台机器上，那就是很明显的单点故障了！当将存储`__consumer_offset`的Partition的Broker给Kill后，会发现所有的消费者都停止消费了。

这个问题怎么解决？

**第一点**，需要将`__consumer_offset`删除，注意这个Topic时Kafka内置的Topic，无法用命令删除，我是通过将`logs`删了来实现删除。

**第二点**，需要通过设置`offsets.topic.replication.factor`为3来将`__consumer_offset`的副本数改为3。

通过将`__consumer_offset`也做副本冗余后来解决某个节点宕机后消费者的消费问题。

最后，关于为什么`__consumer_offset`的Partition会出现只存储在一个Broker上而不是分布在各个Broker上感到困惑，如果有朋友了解的烦请指教~

# 总结 #

三个工作日收到了offer，头条面试体验还是很棒的，这次的头条面试好像每面技术都问了我算法，然后就是中间件、MySQL、Redis、Kafka、网络等等。

**如果你对下面我说的这些笔记感兴趣，可以点赞+关注后，[戳这里即可免费领取][Link 1]**

*  **第一个是算法**

关于算法，我觉得最好的是刷题，作死的刷的，多做多练习，加上自己的理解，还是比较容易拿下的。

而且，**我貌似是将《算法刷题LeetCode中文版》、《算法的乐趣》大概都过了一遍，尤其是这本**

**《算法刷题LeetCode中文版》总共有15个章节：编程技巧、线性表、字符串、栈和队列、树、排序、查找、暴力枚举法、广度优先搜索、深度优先搜索、分治法、贪心法、动态规划、图、细节实现题**

![最新出炉，头条三面技术四面HR，看我如何一步一步攻克面试官？][HR]

**《算法的乐趣》共有23个章节：**

![最新出炉，头条三面技术四面HR，看我如何一步一步攻克面试官？][HR 1]

![最新出炉，头条三面技术四面HR，看我如何一步一步攻克面试官？][HR 2]

*  **第二个是Redis、MySQL、kafka（给大家看下我都有哪些复习笔记）**

基本上都是面试真题解析、笔记和学习大纲图，感觉复习也就需要这些吧（个人意见）

![最新出炉，头条三面技术四面HR，看我如何一步一步攻克面试官？][HR 3]

*  **第三个是网络（给大家看一本我之前得到的《JAVA核心知识整理》包括30个章节分类，这本283页的JAVA核心知识整理还是很不错的，一次性总结了30个分享的大知识点）**

img-MOIoROzu-1620569749656)\]

![最新出炉，头条三面技术四面HR，看我如何一步一步攻克面试官？][HR 4]

[ee8c6e2ff5960839fe89c947871795de.png]: /images/20210720/e85aef706e5a49599612d701ee4330a8.png
[4925ff0b41f34791ae582771af408623.png]: /images/20210720/7462493f19f841f8bd6da402ff229470.png
[729a4ea37cce847c039dec4140c7a5ad.png]: /images/20210720/825b6f525c8f426ba6575ea9e1d4df01.png
[995bc99834e0e33141d69cd3e0620333.png]: /images/20210720/8478a86f0d6c40c5ac1e8e5f260ba15f.png
[Link 1]: https://docs.qq.com/doc/DSmxTbFJ1cmN1R2dB
[HR]: /images/20210720/a5ce609ccc764577a045ab2d3d5b6430.png
[HR 1]: /images/20210720/302ff2a8a3e7490cac4ea98a68f42456.png
[HR 2]: /images/20210720/0ef0e42278d14d4ba9cf241edab5c064.png
[HR 3]: /images/20210720/5df2f6936c2449e3ae9c7a72584e8d71.png
[HR 4]: /images/20210720/4b3a89f3f11b441591eae8583af03377.png