2天时间3个面试，百度进了3面！

昨天和朋友复盘了一下最近的面试经历，分享给大家：

关于就业环境

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

或者换个行业！

关于焦虑和摆烂

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

部分面经分享

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

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开发的对比
- 分布式开发和单体开发的对比