宇宙条一面：十道经典面试题解析
时间：2021-10-14 17:13:36
手机看文章
扫描二维码
随时随地手机看文章
[导读]前言有位朋友面试了宇宙条，后端方向。整理了这几道面试真题以及答案，如有错误，欢迎大家留言区讨论哈。金九银十冲刺，面试的小伙伴加油呀。1.http请求头里，expire和cache-control字段含义，说说HTTP状态码1.1expire和cache-control字段含义Ca...
前言
有位朋友面试了宇宙条，后端方向。整理了这几道面试真题以及答案，如有错误，欢迎大家留言区讨论哈。金九银十冲刺，面试的小伙伴加油呀。
1.http请求头里，expire和cache-control字段含义，说说HTTP状态码
1.1 expire和cache-control字段含义
- Cache-Control是HTTP/1.1的头字段，用来区分对缓存机制的支持情况，请求头和响应头都支持这个属性。通过它提供的不同的值来定义缓存策略。主要有
public、private、no-cache等值。 - expires是http1.0的头字段，过期时间，如果设置了时间，则浏览器会在设置的时间内直接读取缓存，不再请求。
1.2 常见HTTP状态码
2.https原理，数字签名，数字证书。
2.1 https 原理
- HTTPS = HTTP SSL/TLS，即用SSL/TLS对数据进行加密和解密，Http进行传输。
- SSL，即Secure Sockets Layer（安全套接层协议），是网络通信提供安全及数据完整性的一种安全协议。
- TLS，即Transport Layer Security(安全传输层协议)，它是SSL 3.0的后续版本。
- 用户在浏览器里输入一个https网址，然后连接到server的443端口。
- 服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过。这套证书其实就是一对公钥和私钥。
- 服务器将自己的数字证书（含有公钥）发送给客户端。
- 客户端收到服务器端的数字证书之后，会对其进行检查，如果不通过，则弹出警告框。如果证书没问题，则生成一个密钥（对称加密），用证书的公钥对它加密。
- 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
- 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到客户端密钥，然后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。
- 服务器将加密后的密文返回给客户端。
- 客户端收到服务器发返回的密文，用自己的密钥（客户端密钥）对其进行对称解密，得到服务器返回的数据。
2.2 数字签名，数字证书
了解过Https原理的小伙伴，都知道数字证书这玩意。为了避免公钥被篡改，引入了数字证书，如下：- 公钥和个人信息，经过Hash算法加密，形成消息摘要；将消息摘要拿到拥有公信力的认证中心（CA），用它的私钥对消息摘要加密，形成数字签名.
- 公钥和个人信息、数字签名共同构成数字证书。
3.tcp连接client和server有哪些状态，time_wait状态
3.1 tcp 连接
tcp连接时，客户端client 有SYN_SEND、ESTABLISHED状态，服务端server有SYN_RCVD、ESTABLISHED状态。- 第一次握手(SYN=1, seq=x)，发送完毕后，客户端进入 SYN_SEND 状态
- 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x 1)， 发送完毕后，服务器端进入 SYN_RCVD 状态。
- 第三次握手(ACK=1，ACKnum=y 1)，发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时,也进入 ESTABLISHED 状态，TCP 握手，即可以开始数据传输。
3.2 time_wait状态
可以先回忆下TCP的四次挥手哈，- 第一次挥手(FIN=1，seq=u)，发送完毕后，客户端进入FIN_WAIT_1状态
- 第二次挥手(ACK=1，ack=u 1,seq =v)，发送完毕后，服务器端进入CLOSE_WAIT状态，客户端接收到这个确认包之后，进入FIN_WAIT_2状态
- 第三次挥手(FIN=1，ACK1,seq=w,ack=u 1)，发送完毕后，服务器端进入LAST_ACK状态，等待来自客户端的最后一个ACK。
- 第四次挥手(ACK=1，seq=u 1,ack=w 1)，客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入TIME_WAIT状态，等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。
2MSL，2 Maximum Segment Lifetime，即两个最大段生命周期
- 1个 MSL 保证四次挥手中主动关闭方最后的ACK 报文能最终到达对端
- 1个 MSL 保证对端没有收到 ACK 那么进行重传的FIN报文能够到达
4.什么是虚拟内存? 什么是物理内存？
4.1 什么是虚拟内存？
虚拟内存，是虚拟出来的内存，它的核心思想就是确保每个程序拥有自己的地址空间，地址空间被分成多个块，每一块都有连续的地址空间。同时物理空间也分成多个块，块大小和虚拟地址空间的块大小一致，操作系统会自动将虚拟地址空间映射到物理地址空间，程序只需关注虚拟内存，请求的也是虚拟内存，真正使用却是物理内存。4.2 什么是物理内存
物理内存，指通过物理内存条而获得的内存空间，而虚拟内存则是指将硬盘的一块区域划分来作为内存。我们常说的物理内存大小，其实是指内存条的大小。一般买电脑时，我们都会看下内存条是多大容量的，话说如果内存条大小是100G，那这100G就都能够被使用吗？不一定的，更多的还是要看CPU地址总线的位数，如果地址总线只有20位，那么它的寻址空间就是1MB，即使可以安装100G的内存条也没有意义，也只能视物理内存大小为1MB。4.3 虚拟内存如何映射到物理内存？
如下图，CPU里有一个内存管理单元（Memory Management Unit），简称为MMU，虚拟内存不是直接送到内存总线，而是先给到MMU，由MMU来把虚拟地址映射到物理地址，程序只需要管理虚拟内存就好，映射的逻辑自然有其它模块自动处理。5.一台机器最多可以建立多少个tcp连接，client端，server端，超过了怎么办
- TCP连接的客户端机：每一个ip可建立的TCP连接理论受限于ip_local_port_range参数，也受限于65535。但可以通过配置多ip的方式来加大自己的建立连接的能力。
- TCP连接的服务器机：每一个监听的端口虽然理论值很大，但这个数字没有实际意义。最大并发数取决你的内存大小，每一条静止状态的TCP连接大约需要吃3 .3K的内存。
6.Eureka原理，是否是强一致性，eureka集群。宕机了服务还能调用么？Eureka和ZooKeeper对比
6.1 eureka架构
注册中心是分布式开发的核心组件之一，而eureka是spring cloud推荐的注册中心实现。架构图如下：- Eureka Server：提供服务注册和发现，多个Eureka Server之间会同步数据，做到状态一致
- Service Provider：服务提供方，将自身服务注册到Eureka，从而使服务消费方能够找到
- Service Consumer：服务消费方，从Eureka获取注册服务列表，从而能够消费服务
6.2 基于集群的Eureka架构图
服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。
6.3 宕机了服务还能调用么？
Eureka 挂了，微服务是可以调通的，不过有个前提：provider的地址没变！如果 provider换了一个 IP 地址或者端口，这个时候，consumer 就无法及时感知到这种变化，就会调不通。6.4 Eureka和ZooKeeper对比
- Zookeeper保证CP(一致性和分区容错性)，但是不保证可用性，ZK的leader选举期间，是不可用的。
- Eureka保证AP（可用性和分区容错性），它优先保证可用性，几个节点挂掉不会影响正常节点的工作。
7.Hystrix了解嘛？说说Hystrix的工作原理
Hystrix 工作流程图如下:- 构建命令
Hystrix 提供了两个Command， HystrixCommand 和 HystrixObservableCommand，可以使用这两个对象来包裹待执行的任务。
- 执行命令
- R execute()：同步执行，从依赖服务得到单一结果对象
- Future queue()：异步执行，返回一个 Future 以便获取执行结果，也是单一结果对象
- Observable observe()：hot observable，创建Observable后会订阅Observable，可以返回多个结果
- Observable toObservable()：cold observable，返回一个Observable，只有订阅时才会执行，可以返回多个结果
- 检查缓存
8.zookeeper一致性保证，zab协议原理，zookeeper属于哪种一致性，强一致性么，还是最终一致性
Zab协议，英文全称是Zookeeper Atomic Broadcast（Zookeeper原子广播）。Zookeeper是通过Zab协议来保证分布式事务的最终一致性。Zab协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议 ，是Zookeeper保证数据一致性的核心算法。Zab借鉴了Paxos算法，是一种通用的分布式一致性算法。基于Zab协议，Zookeeper实现了一种主备模型（即Leader和Follower模型）的系统架构来保证集群中各个副本之间数据的一致性。就是指只有一台Leader节点负责处理外部的写事务请求，然后它（Leader）将数据同步到其他Follower节点。Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求，那么节点就会向Leader提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。- 发现：要求zookeeper集群必须选举出一个 Leader 进程，同时 Leader 会维护一个 Follower 可用客户端列表。将来客户端可以和这些 Follower节点进行通信。
- 同步：Leader 要负责将本身的数据与 Follower 完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错。Follower将队列中未处理完的请求消费完成后，写入本地事务日志中。
- 广播：Leader 可以接受客户端新的事务Proposal请求，将新的Proposal请求广播给所有的 Follower。
9. 聊聊zookeeper选举机制
服务器启动或者服务器运行期间（Leader挂了），都会进入Leader选举，我们来看一下~假设现在ZooKeeper集群有五台服务器，它们myid分别是服务器1、2、3、4、5，如图：9.1 服务器启动的Leader选举
zookeeper集群初始化阶段，服务器（myid=1-5）依次启动，开始zookeeper选举Leader~- 服务器1（myid=1）启动，当前只有一台服务器，无法完成Leader选举
- 服务器2（myid=2）启动，此时两台服务器能够相互通讯，开始进入Leader选举阶段
- 2.1. 每个服务器发出一个投票
服务器1和服务器2都将自己作为Leader服务器进行投票，投票的基本元素包括：服务器的myid和ZXID，我们以（myid，ZXID）形式表示。初始阶段，服务器1和服务器2都会投给自己，即服务器1的投票为（1,0），服务器2的投票为（2,0），然后各自将这个投票发给集群中的其他所有机器。
- 2.2 接受来自各个服务器的投票
每个服务器都会接受来自其他服务器的投票。同时，服务器会校验投票的有效性，是否本轮投票、是否来自LOOKING状态的服务器。
- 2.3. 处理投票
收到其他服务器的投票，会将被人的投票跟自己的投票PK，PK规则如下：
- 优先检查ZXID。ZXID比较大的服务器优先作为leader。
- 如果ZXID相同的话，就比较myid，myid比较大的服务器作为leader。
服务器1的投票是（1,0），它收到投票是（2,0），两者zxid都是0，因为收到的myid=2，大于自己的myid=1，所以它更新自己的投票为（2,0），然后重新将投票发出去。对于服务器2呢，即不再需要更新自己的投票，把上一次的投票信息发出即可。
- 2.4. 统计投票
每次投票后，服务器会统计所有投票，判断是否有过半的机器接受到相同的投票信息。服务器2收到两票，少于3（n/2 1,n为总服务器），所以继续保持LOOKING状态
- 服务器3（myid=3）启动，继续进入Leader选举阶段
- 3.1 跟前面流程一致，服务器1和2先投自己一票，因为服务器3的myid最大，所以大家把票改投给它。此时，服务器为3票（大于等于n/2 1）,所以服务器3当选为Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；
- 服务器4启动，发起一次选举。
- 4.1 此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。选票信息结果：服务器3为3票，服务器4为1票。服务器4并更改状态为FOLLOWING；
- 服务器5启动，发起一次选举。
- 同理，服务器也是把票投给服务器3，服务器5并更改状态为FOLLOWING；
- 投票结束，服务器3当选为Leader
9.2 服务器运行期间的Leader选举
zookeeper集群的五台服务器（myid=1-5）正在运行中，突然某个瞬间，Leader服务器3挂了，这时候便开始Leader选举~- 变更状态
Leader 服务器挂了之后，余下的非Observer服务器都会把自己的服务器状态更改为LOOKING，然后开始进入Leader选举流程。
- 每个服务器发起投票
每个服务器都把票投给自己，因为是运行期间，所以每台服务器的ZXID可能不相同。假设服务1,2,4,5的zxid分别为333,666,999,888，则分别产生投票（1,333），（2，666），（4,999）和（5,888），然后各自将这个投票发给集群中的其他所有机器。
- 接受来自各个服务器的投票
- 处理投票
投票规则是跟Zookeeper集群启动期间一致的，优先检查ZXID，大的优先作为Leader，所以显然服务器zxid=999具有优先权。
- 统计投票
- 改变服务器状态
10. 算法：给定一个字符串s ，请你找出其中不含有重复字符的最长连续子字符串的长度。
可以使用滑动窗口实现，代码如下：public int lengthOfLongestSubstring2(String s) {
int n = s.length();
if (n <= 1) return n;
int maxLen = 1;
//左、右指针
int left = 0, right = 0;
Set window = new HashSet<>();
while (right < n) {
char rightChar = s.charAt(right);
while (window.contains(rightChar)) {
window.remove(s.charAt(left));
left ;
}
//最大长度对比
maxLen = Math.max(maxLen, right - left 1);
window.add(rightChar);
right ;
}
return maxLen;
}
参考与感谢
[1]Spring Cloud 源码学习之 Hystrix 工作原理: https://chenyongjun.vip/articles/88[2]Zookeeper——一致性协议:Zab协议: https://www.jianshu.com/p/2bceacd60b8a
下载文档
