关于后端:2天时间3个面试百度进了3面二三线城市却异常惨淡

昨天和敌人复盘了一下最近的面试经验，分享给大家：

对于待业环境

忠告：如果不是在二三线买车买房结婚生子了，还是到一线城市去吧。

或者 换个行业！

对于焦虑和摆烂

如果你也在焦虑迷茫、精力内耗。找阳哥给你做“心理按摩”，保障让你像打鸡血一样，斗志满满，不再摆烂。

微信号：wangzhongyang1993

局部面经分享

以下内容是针对特定简历和面试过程做的复盘总结，不是标准答案，仅供参考和探讨：

1. 自我介绍感觉话术表述不是很好，须要刻意筹备打磨

• 重点强调 Go 语言相干教训，比方 X 年工作教训，次要做后端开发。不要提旁枝末节和后端开发无关的事件
• 联合面试公司的状况，重点介绍相干的工作教训
• 如果有开源我的项目和博客最初也提一下，酷爱技术，酷爱分享比方多少 star，多少粉丝等等

2. 我的项目介绍上表白容易卡顿或者不连贯，给人一种对我的项目不熟的感觉。我的项目是先介绍模块划分还是先介绍架构好？

• 先介绍模块，让对方有个整体意识，再介绍架构，这样更好了解

3. 架构是从网关讲到底层服务层好，还是从底层讲到下面好

• 网关层讲到底层服务，这样更清晰，更好了解

4. 每个层级是如何进行冗灾？

• 应用层容灾：应用层容灾次要是通过负载平衡和故障转移来实现的。能够将利用部署在多台服务器上，通过负载均衡器将申请散发到不同的服务器上，以实现负载平衡和故障转移。同时，能够应用容器技术如 Docker，将利用打包成镜像，以便疾速部署和迁徙。
• 服务层容灾：服务层容灾次要是通过服务治理和容错机制来实现的。能够应用服务注册核心如 ZooKeeper、Consul 等来实现服务的注册和发现，以便疾速定位故障服务并进行故障转移。同时，能够应用熔断器、限流器等容错机制来爱护服务的稳定性和可靠性。
• 数据层容灾：数据层容灾次要是通过数据备份、数据同步和数据恢复来实现的。能够应用数据库主从复制、分布式数据库等技术来实现数据备份和同步，以保证数据的可靠性和一致性。同时，能够应用数据恢复工具如 mysqldump、pg_dump 等来进行数据恢复。

5. 看你我的项目是选 gin 作为框架的，为啥没思考集成度更高的 go-zero, 你对 go-zero 理解多少？

• gin 入门简略、我的项目工夫紧
• gozero 作为 rpc 微服务框架，起初有钻研，比方：xxxxx 巴拉巴拉

6. 为什么你抉择 Kong 作为网关，基于什么思考的

• Kong 作为一个 API 网关，具备以下几个劣势：

  • 高性能：Kong 应用了 Nginx 作为底层引擎，具备高性能和高并发的特点，能够解决大量的 API 申请。
  • 可扩大：Kong 提供了一系列的插件和扩大机制，能够帮忙开发者疾速扩大和定制 API 网关的性能和性能。
  • 易于应用：Kong 提供了一系列的治理界面和 API，能够帮忙开发者疾速配置和治理 API 网关。
  • 安全可靠：Kong 提供了一系列的平安机制，如身份验证、访问控制、避免 SQL 注入等，能够保障 API 的安全性和可靠性。
  • 社区沉闷：Kong 有一个十分沉闷的社区，提供了大量的文档、教程、插件和扩大，能够帮忙开发者疾速学习和应用 Kong。

7. 你在哪些层面做了限流及负载平衡？为什么这么思考？

• 目前就网关层和 srv 层做了限流和负载平衡

• 网关层通过 kong 自带计数器模式进行限流，比方依据 IP 限流，设置每分钟能拜访 50 次

  POST http://127.0.0.1:9001/services/audio-service/plugins
  {
    "name":"rate-limiting",
    "config.minute":50, 
    "config.limit_by":"ip"
  }

• 录入零碎单元通过 IP 黑白名单进行限流

8. kong 的负载平衡该怎么形容？

• Kong 的负载平衡是基于 Nginx 的负载平衡实现的。
• Kong 应用 Nginx 作为底层引擎，通过 Nginx 的负载平衡模块实现负载平衡性能。
• 具体来说，Kong 会将 API 申请散发到多个后端服务节点上，以实现负载平衡。
• Kong 的负载平衡反对多种负载平衡算法，如轮询、IP 哈希、起码连接数等。
• 咱们能够依据本人的需要抉择适合的负载平衡算法。同时，Kong 还提供了一系列的负载平衡配置选项，如权重、健康检查、故障转移等，能够帮忙开发者更加灵便地配置和治理负载平衡。

9. 我的项目中用到了 gRPC，谈谈你对 gRPC 的了解，及我的项目中是如何应用到的？

• gRPC 是一个高性能、开源的近程过程调用（RPC）框架，它应用 Protocol Buffers 作为接口定义语言（IDL），能够帮忙开发者疾速构建分布式应用程序。gRPC 的特点包含：

  • 高性能：gRPC 应用了基于 HTTP/2 的协定，能够进步应用程序的性能和吞吐量。
  • 跨语言反对：gRPC 反对多种编程语言，如 Go、Java、Python、C# 等，能够帮忙开发者构建跨语言的分布式应用程序。
  • 主动生成代码：gRPC 应用 Protocol Buffers 作为接口定义语言（IDL），能够主动生成客户端和服务器端的代码，简化了开发者的工作量。

  • 安全可靠：gRPC 提供了一系列的平安机制，如身份验证、访问控制、加密传输等，能够保障应用程序的安全性和可靠性。

    • 在我的项目中，gRPC 能够用于实现微服务之间的通信。具体来说，开发者能够应用 gRPC 定义服务接口和数据类型，而后应用 gRPC 主动生成客户端和服务器端的代码，最初在客户端和服务器端之间进行近程调用。
    • gRPC 能够帮忙开发者实现高性能、跨语言、安全可靠的微服务通信，进步应用程序的可扩展性和可维护性。
• 简历优化 & 就业辅导 能够加我微信：wangzhongyang1993
• 或者关注公众号：程序员升职加薪之旅

10. nacos 做服务发现的原理？

• Nacos 是一个开源的服务发现和配置管理平台，它能够帮忙开发者实现服务注册、服务发现、配置管理等性能。Nacos 的服务发现原理次要包含以下几个步骤：

  • 服务注册：服务提供者在启动时向 Nacos 注册核心注册本人的服务信息，包含服务名称、服务地址、服务端口等。
  • 服务发现：服务消费者在启动时向 Nacos 注册核心查问本人所需的服务信息，Nacos 注册核心返回符合条件的服务提供者列表。
  • 负载平衡：服务消费者从服务提供者列表中抉择一个服务提供者进行调用，能够应用负载平衡算法来抉择服务提供者。
  • 心跳检测：服务提供者定期向 Nacos 注册核心发送心跳信息，以保障服务提供者的可用性。
  • 服务下线：服务提供者在进行服务时向 Nacos 注册核心登记本人的服务信息，以保障服务提供者的及时下线。
  • 总结一下：Nacos 的服务发现原理次要是通过服务注册、服务发现、负载平衡、心跳检测和服务下线等步骤来实现的。Nacos 注册核心作为服务发现的外围组件，能够帮忙开发者实现高可用、高性能的服务发现性能。

11. nacos 如何感知服务故障了或者离线了

• Nacos 通过心跳检测机制来感知服务故障或者离线。具体来说，服务提供者在启动时向 Nacos 注册核心注册本人的服务信息，并定期向 Nacos 注册核心发送心跳信息。如果服务提供者在肯定工夫内没有发送心跳信息，Nacos 注册核心会认为该服务提供者曾经故障或者离线，将其从服务列表中移除。

• Nacos 的心跳检测机制能够通过以下几个参数进行配置：

  • 心跳距离（默认为 5 秒）：服务提供者向 Nacos 注册核心发送心跳信息的工夫距离。
  • 心跳超时工夫（默认为 15 秒）：Nacos 注册核心在服务提供者未发送心跳信息的工夫超过该值时，认为服务提者曾经故障或者离线。
  • 实例存活工夫（默认为 90 秒）：Nacos 注册核心在服务提供者未发送心跳信息的工夫超过该值时，将主动登记该服务提供者的服务实例。
  • 通过配置这些参数，咱们就能够依据本人的需要来调整心跳检测机制的敏感度和精度，以保障服务发现的及时性和可靠性。

12. Nacos 如何进行故障复原？

• Nacos 通过以下几种形式来进行故障复原：

  • 主动切换：Nacos 反对多个注册核心节点的部署，当某个节点产生故障时，Nacos 能够主动切换到其余节点进行服务发现和配置管理。
  • 主动复原：Nacos 反对多个服务提供者的部署，当某个服务提供者产生故障时，Nacos 能够主动切换到其余服务提供者进行服务调用。
  • 主动重试：Nacos 反对主动重试机制，当服务调用失败时，Nacos 能够主动重试，直到服务调用胜利或者达到最大重试次数。
  • 健康检查：Nacos 反对健康检查机制，能够定期检查服务提供者的衰弱状态，当服务提供者产生故障时，Nacos 能够主动将其从服务列表中移除，直到服务恢复正常。
  • 总结一下：Nacos 通过主动切换、主动复原、主动重试和健康检查等机制来进行故障复原，能够帮忙咱们实现高可用、高性能的服务发现和配置管理性能。同时，Nacos 还提供了一系列的监控和告警机制，能够帮忙开发者及时发现和解决故障，进步应用程序的可靠性和稳定性。

13. 故障复原的负载平衡是哪一部分做的？

• 在故障复原的过程中，Nacos 的负载平衡是由服务消费者的负载平衡模块来实现的。具体来说，当服务消费者向 Nacos 注册核心查问服务提供者列表时，Nacos 注册核心会返回符合条件的服务提供者列表，服务消费者会依据负载平衡算法从服务提供者列表中抉择一个服务提供者进行调用。如果抉择的服务提供者产生故障或者离线，服务消费者会从新抉择一个服务提供者进行调用，以实现故障复原和负载平衡。
• Nacos 反对多种负载平衡算法，如轮询、随机、起码连接数等，服务消费者能够依据本人的需要抉择适合的负载平衡算法。同时，Nacos 还提供了一系列的负载平衡配置选项，如权重、健康检查、故障转移等，能够帮忙咱们更加灵便地配置和治理负载平衡。
• 在故障复原的过程中，Nacos 的负载平衡是由服务消费者的负载平衡模块来实现的，服务消费者能够依据本人的需要抉择适合的负载平衡算法和配置选项，以实现故障复原和负载平衡。

14. 网关层的缓存、限流是如何做的，故障转移是如何做的?

• 网关层的缓存和限流是通过网关层的插件来实现的。具体来说，网关层能够应用缓存插件和限流插件来实现缓存和限流性能。缓存插件能够将常常申请的数据缓存到内存中，以进步响应速度和升高后端服务的压力；限流插件能够限度申请的速率和数量，以爱护后端服务的稳定性和可靠性。
• 在故障转移方面，网关层能够通过负载平衡插件来实现。具体来说，网关层能够将申请散发到多个后端服务节点上，以实现负载平衡和故障转移。当某个后端服务节点产生故障或者离线时，网关层能够主动将申请转发到其余可用的后端服务节点上，以保障服务的可用性和稳定性。
• 总结一下：网关层的缓存、限流和故障转移是通过网关层的插件来实现的。网关层能够应用缓存插件和限流插件来实现缓存和限流性能，应用负载平衡插件来实现故障转移性能。这些插件能够帮忙开发者实现高性能、高可用、高稳定性的网关层服务。

15. redis 如何实现分布式锁有哪些？有哪些优缺点？

• Redis 实现分布式锁的形式次要有以下几种：

  • 基于 SETNX 命令：应用 SETNX 命令能够将一个键值对设置为锁，如果该键值对不存在，则设置胜利，示意获取锁胜利；否则设置失败，示意获取锁失败。开释锁时能够应用 DEL 命令删除该键值对。
  • 基于 Lua 脚本：应用 Lua 脚本能够将获取锁和开释锁的操作封装为一个原子操作，防止了多个 Redis 命令之间的竞争条件。
  • 基于 Redlock 算法：Redlock 算法是一种分布式锁算法，能够在多个 Redis 节点之间实现分布式锁。具体来说，Redlock 算法将锁分为多个正本，每个正本在不同的 Redis 节点上，获取锁时须要在多个正本上都获取胜利才算获取锁胜利。

• Redis 实现分布式锁的优缺点如下：

  • 长处：

    • 高性能：Redis 是一种高性能的内存数据库，能够疾速地进行锁的获取和开释操作。
    • 可靠性高：Redis 反对主从复制和 Sentinel 高可用计划，能够保障分布式锁的可靠性和稳定性。
    • 易于应用：Redis 提供了多种实现分布式锁的形式，开发者能够依据本人的需要抉择适合的形式。

  • 毛病：

    • 竞争条件：在高并发的状况下，多个客户端同时获取锁可能会导致竞争条件，须要应用适当的算法和技术来防止竞争条件的产生。
    • 锁过期问题：如果锁的过期工夫设置不合理，可能会导致锁过期后其余客户端获取锁，导致数据不统一或者死锁等问题。因而，须要依据理论状况正当设置锁的过期工夫。
    • 性能损失：在应用 Redlock 算法时，须要在多个 Redis 节点之间进行通信和协调，可能会导致性能损失和提早减少。
• 总结一下：Redis 实现分布式锁是一种高性能、可靠性高、易于应用的形式，但须要留神竞争条件、锁过期问题和性能损失等问题。开发者能够依据本人的需要抉择适合的实现形式，并结合实际状况进行优化和调整，以保障分布式锁的可靠性和性能。

16. 目前服务大略并发是多少？

• 介绍并发应该从以下几个指标来答复：QPS PV UV 并发连接数 响应工夫

  • QPS（每秒查问率）：QPS 是指每秒钟可能解决的查问申请的数量，是掂量零碎性能的重要指标之一。
  • TPS（每秒事务数）是指零碎每秒钟可能解决的事务数量，其中事务能够是数据库事务、HTTP 申请、RPC 调用等。
  • PV（页面浏览量）：PV 是指用户拜访网站的页面数量，是掂量网站流量的重要指标之一。
  • UV（独立访客数）：UV 是指拜访网站的独立用户数量，是掂量网站用户数量的重要指标之一。
  • 并发连接数：并发连接数是指同时连贯到服务器的用户数量，是掂量零碎并发能力的重要指标之一。
  • 响应工夫：响应工夫是指零碎解决申请的工夫，是掂量零碎性能和用户体验的重要指标之一。

• 举个栗子，对于一个用户量为 100 万 + 的电商网站，以下是一些可能的指标取值范畴：

  • QPS：依据业务场景和零碎设计，QPS 可能在几百到几千之间，甚至更高。
  • 数据库事务：依据业务场景和数据库设计，TPS 可能在几百到几千之间，甚至更高。
  • HTTP 申请：假如每个用户均匀每天拜访网站 10 次，那么每天的 HTTP 申请可能在 1000 万 +，每秒钟的 TPS 可能在几百到几千之间。
  • RPC 调用：假如每个用户均匀每天进行 10 次 RPC 调用，那么每天的 RPC 调用可能在 1000 万 +，每秒钟的 TPS 可能在几百到几千之间。
  • PV：假如每个用户均匀拜访网站 10 个页面，那么每天的 PV 可能在 1000 万 +。
  • UV：假如每个用户均匀每天拜访网站 1 次，那么每天的 UV 可能在 100 万到数百万之间。
  • 并发连接数：依据业务场景和零碎设计，可能须要反对数千到数万的并发连接数。
  • 响应工夫：依据业务场景和用户体验要求，响应工夫应该管制在几百毫秒以内。

17. 应用层与服务层的部署散布部署了多少节点？

• 依然以用户量 100 万 + 作为预估：
• 应用层：将应用层部署在多台服务器上，每台服务器部署多个利用实例，来实现负载平衡和故障转移。可能须要 10 台~100 台服务器，每台服务器部署 10 个左右的利用实例
• 服务层：和应用层是一样的，可能须要 10 台~100 台服务器，每台服务器部署 10 个左右的利用实例。

18. 我的项目中目前是基于什么实现的高并发，以及在解决的时候须要留神哪些问题？遇到哪些印象比拟粗浅的问题？

• 高并发

  • 分布式架构
  • 缓存技术
  • 异步音讯

• 须要留神的问题

  • 数据一致性

  • 追踪定位剖析问题的形式

    • jaeger

  • 数据库优化

    • 慢查问

    • 索引

      • 索引命中
      • 索引类型
  • 负载平衡和故障转移
  • 容灾问题

• 印象粗浅的问题：

  • mongo 链接数过多
  • 数据库连接池过多
  • 缓存穿透、击穿的问题

  • 安全性问题

    • 备份
    • 数据传输
  • 三方服务对接的坑，对接上游和上游别离遇到的问题
  • Go 语言开发和之前 Python 开发的比照
  • 分布式开发和单体开发的比照

欢送关注 ❤

我的微信：wangzhongyang1993

视频号：王中阳 Go

公众号：程序员升职加薪之旅