【2024秋招】2023-9-20 度小满信贷系统平台部二面

1 面试官的部门介绍

我们部门是信贷系统平台部，主要是为度小满做一个服务，你应该也接触过信用卡，跟这种差不多，用户可以打进我们的系统申请一个额度，整个部门的规模大概是400-500人左右，我个人来自平台数据团队，主要是收敛整个信贷部门的数据，然后供给其他部门使用，比如风控团队，风控主要做的是用于判断一个人的贷款资质和额度的系统，平台部的技术团队大概40-50人，我们这儿的技术栈主要是spring，springMVC，像spring cloud也有在用，但是自研的也有，我们跟数据打交道比较多，然后还会用一些hadoop，hive等技术栈和能力，除了java，还有go，php，但是可能是其他部门；此外，即使三面都通过的话，也不一定是在我们部门，到时候可能会再做一个挑选

2 场景设计

2.1 如果你接到一个需求，这个需求涉及到访问其他的api，你能从不同的角度，安全性，可用性、高性能角度，说明一下这个接口应该具备哪些能力嘛

答：

当然可以。如果你接到一个需求，需要设计一个接口来访问其他的API，从安全性、可用性和高性能的角度，该接口应具备以下能力：

1. 安全性:

1. 鉴权 (Authentication): 确保只有合法的用户或应用程序可以访问你的接口。常用的方法包括API密钥、OAuth、JWT等。

2. 授权 (Authorization): 确保已经鉴权的用户或应用只能访问它们被允许的资源和操作。

3. 数据加密: 使用HTTPS进行传输，确保数据在传输过程中不被截取或篡改。如果需要，还可以使用端到端加密。

4. 错误处理: 避免显示敏感信息，例如数据库错误或调试信息。

5. 防御性编程: 对输入进行验证和清理，以避免SQL注入、跨站脚本(XSS)等常见的安全威胁。

6. 频率限制: 限制API的调用频率，防止恶意用户进行洪水攻击或过多请求。

2. 可用性:

1. 冗余: 如果可能，确保有备份或多个服务器实例来处理请求，以避免单点故障。

2. 负载均衡: 使用负载均衡器，确保所有的服务器实例都有均匀的流量，并在某个实例故障时自动切换。

3. 健康检查: 定期检查API的健康状况，确保其正常运行。

4. 优雅的降级: 当外部服务或资源不可用时，提供有意义的错误信息或回退到备用的服务。

5. 文档: 提供详细且易于理解的API文档，方便其他开发者使用。

6. 使用限流算法：调用别人的时候，比如运营商接口，可以在运营商一方使用漏桶算法，如果想要应对突发流量，同时保护自己，使用令牌桶算法或者滑动窗口计数器

7. **监控：**监控的时候发现负载过高，添加新节点，

3. 高性能:

1. 缓存: 使用缓存技术（如Redis、Memcached等）来缓存经常被查询的数据或结果，减少数据库或外部API的查询。

2. 异步处理: 对于需要长时间处理的请求，考虑使用异步处理，然后再通知用户结果。

3. 优化数据库查询: 确保数据库查询已经优化，避免N+1问题，使用索引等。

4. 并发处理: 使用并发编程模型，确保API可以同时处理多个请求。

5. 压缩: 使用gzip或其他技术压缩API响应，减少数据传输的大小和时间。

6. 连接持久化: 使用持久化连接如HTTP/2，以减少建立和关闭连接的开销。

7. 监控性能: 使用监控工具来跟踪API的性能，如响应时间、错误率等，以便进行及时的优化。

这只是对这个话题的一个初步概述，每个点都可以深入探讨，取决于具体的应用场景和需求。

2.2 还有没有其他需要考虑的点

当然，除了上述提到的关于安全性、可用性和高性能的建议之外，还有其他一些重要的考虑因素。以下是对一个API应具备的其他能力的扩展：

4. 扩展性：

1. 模块化设计: 设计API时，应考虑到将来可能的变更和扩展，模块化的设计可以确保在不影响现有功能的情况下添加新功能。
2. 版本管理: 随着业务需求的发展，API可能需要进行更改。通过合理的版本管理策略，可以确保向后兼容，同时支持新的功能。

5. 透明度与监控：

1. 日志记录: 记录API的使用情况，包括访问者、时间、响应时间、返回的数据和任何可能的错误。
2. 告警系统: 在出现异常或错误时，系统应能自动发送警报，以便及时处理。
3. 可视化监控: 使用工具如Grafana、Kibana等，以图形化的方式显示API的性能和使用情况。

6. 用户友好性：

1. 清晰的错误信息: 当用户发送的请求有问题时，返回的错误信息应该足够清晰，使用户能够理解问题并采取相应的措施。
2. 支持多种格式: 考虑支持不同的数据格式，如JSON, XML等，以满足不同用户的需求。

7. 兼容性：

1. 跨平台: 保证API可以在不同的操作系统和设备上使用。
2. 跨语言: API应设计成语言无关的，以便各种编程语言都可以方便地调用。

8. 业务相关：

1. 限流与计费: 如果API是一个付费服务，需要有一个机制来跟踪用户的使用情况，并根据使用量进行计费。
2. 数据备份与恢复: 确保有备份策略，并且可以在数据丢失或损坏时恢复。

9. 测试：

1. 自动化测试: 建立自动化测试，确保API的每次更改都不会引入新的错误。
2. 压力测试: 测试API在高流量下的表现，确保其在实际生产环境中的稳定性。

以上只是对API设计和实施时应考虑的方面的一个总览。具体的需求和实践可能会有所不同，但这为你提供了一个良好的起点。

2.3 你的秒杀系统是怎么做测试的

答：使用jmeter，开启1w个线程模拟10000个用户，然后测试三轮，取得的平均值

2.4 你的系统在云服务器部署过是嘛

答：没，单机部署

2.5 一个接口A会调用接口B和C，B返回的时间是100ms，C返回的时间不固定，可能是200ms，也可能是800ms，现在要求A接口在500ms内收到B和C中任意一个接口返回结果，A就返回结果给用户。如何实现

2.5.1 方法一：使用CompletableFuture发送两个异步调用请求，然后再使用CompletableFuture的静态方法编排两个异步请求的返回结果，其中可以加一个500ms的时间戳，如果500ms内有任意一个请求返回则返回，都没有返回就抛异常

import java.util.concurrent.*;

public class InterfaceCaller {
    private static final Executor executor = Executors.newFixedThreadPool(2);

    public static String callInterfaceB() {
        // Simulate calling Interface B
        // ... your implementation here ...
        return "Response from B";
    }

    public static String callInterfaceC() {
        // Simulate calling Interface C
        // ... your implementation here ...
        return "Response from C";
    }

    public static void main(String[] args) {
        CompletableFuture<String> futureB = CompletableFuture.supplyAsync(() -> callInterfaceB(), executor);
        CompletableFuture<String> futureC = CompletableFuture.supplyAsync(() -> callInterfaceC(), executor);

        try {
            String result = CompletableFuture.anyOf(futureB, futureC).get(500, TimeUnit.MILLISECONDS);
            System.out.println(result);
        } catch (TimeoutException e) {
            System.out.println("Timeout exceeded!");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

2.5.2 方法二： 以Apache Kafka为例，详细描述下发消息、消费消息再到返回消息的完整过程：

1. 消息下发:

• 生产者创建：接口A作为消息的生产者，首先需要创建一个Kafka生产者实例。

• 主题选择：接口A选择或创建一个主题（例如request-topic）来发布其请求消息。

• 发布消息：接口A生成一个唯一的请求ID并发布消息到request-topic。这个消息除了包含业务数据外，还应该有其他元数据，如请求ID、时间戳等。

2. 消息消费:

• 消费者创建：接口B和C作为消息的消费者，它们分别创建Kafka消费者实例并订阅request-topic。

• 消息读取：接口B和C监听request-topic，当接口A的请求消息到达时，它们会从主题中拉取消息。

• 业务逻辑处理：接口B或C读取消息内容，并开始进行必要的业务逻辑处理。

3. 消息返回:

• 选择返回的主题：完成处理后，接口B或C选择一个返回主题（例如response-topic-interfaceB或response-topic-interfaceC）来发布其响应消息。

• 发布响应消息：接口B或C生成响应消息，确保在其中包含原始请求的ID和处理结果，然后发布到相应的返回主题。

• 接口A消费返回消息：接口A此时转变为消费者的角色，它订阅并监听response-topic-interfaceB和response-topic-interfaceC等待响应。为了确保在500ms内获得响应，接口A设置一个定时器。

• 超时与响应处理：如果接口A在500ms内收到了来自接口B或C的响应，它会中止其定时器并处理返回的消息。如果超时，接口A可以返回一个错误消息或默认响应。

整个过程涉及了消息的生产、消费、业务处理和响应，是一个典型的发布-订阅模型。使用Apache Kafka，你可以利用其高吞吐量、持久性和分布式特性来实现这一过程。但同样要注意，引入消息队列会带来一定的延迟，尤其是在高并发的场景中，因此在设计时应权衡实时性和可靠性。

2.5.3 使用Kafka和使用CompletableFuture实现异步操作各有优劣。下面是两者的比较：

使用Kafka

优点：

1. 解耦：生产者和消费者之间解耦，它们可以独立地进行扩展、部署和维护。
2. 持久性：Kafka提供了消息持久性，即使消费者或生产者崩溃，消息仍然存在并可以被重新消费。
3. 可靠性：Kafka设计用于处理大量消息流，具有高可靠性和容错能力。
4. 可扩展性：Kafka集群可以水平扩展，以满足更高的吞吐量需求。
5. 后处理能力：由于消息被存储，你可以稍后进行消费，这对于日志处理、分析等后处理任务很有用。

缺点：

1. 延迟：Kafka的消息传递可能不如直接调用快，尤其是在高并发的情况下。
2. 复杂性：引入Kafka会增加系统的复杂性，需要管理和维护Kafka集群。
3. 资源开销：Kafka需要额外的资源如存储、CPU和内存。

使用CompletableFuture

优点：

1. 简单性：使用CompletableFuture实现并发操作通常比设置和维护Kafka更简单。
2. 速度：CompletableFuture为内存中的操作提供了近乎实时的响应速度。
3. 直接性：直接使用Java API，无需额外的中间件或依赖。
4. 灵活性：CompletableFuture提供了丰富的API，如组合、链式操作等，使得编写复杂的异步逻辑更为方便。

缺点：

1. 局限性：CompletableFuture主要用于单个JVM中的并发操作，不适用于分布式系统或跨服务的通信。
2. 非持久性：如果应用崩溃，CompletableFuture中的操作可能会丢失。
3. 资源限制：所有并发操作共享同一个JVM的资源，如果任务太多，可能会导致资源耗尽。

总结：

• 对于在单个应用或服务内需要快速并发处理的场景，CompletableFuture是一个很好的选择。
• 对于需要跨应用、跨服务或分布式环境中的消息传递、解耦和持久性的场景，Kafka或其他消息队列是更合适的选择。

选择哪种方法取决于你的具体需求、资源和项目的复杂性。

3 rpc框架

3.1 你的rpc框架使用http做通信和使用rpc做通信有什么区别吗

答：

首先，我们应当明确一点：RPC（Remote Procedure Call）是一种远程过程调用模式，而HTTP（HyperText Transfer Protocol）是一种应用层协议。RPC不是一个具体的通信协议；实际上，RPC可以使用多种协议来实现，其中HTTP只是其中之一。因此，RPC和HTTP并不是直接相对的概念。

但在许多上下文中，当人们提到"使用RPC做通信"时，他们实际上是指使用某种专门为RPC设计的协议（例如gRPC、Thrift、RMI等），而不是通用的HTTP协议。基于这一点，我们可以讨论使用专为RPC设计的协议与使用HTTP协议进行RPC的区别：

1. 效率与性能:

   • 专为RPC设计的协议（如gRPC）：通常使用了诸如Protocol Buffers这样的二进制格式，这比传统的HTTP+JSON/XML组合更为高效，因为它减少了序列化/反序列化的开销。
   • HTTP：通常使用文本格式（如JSON或XML），这可能比二进制格式慢。

2. 通信模式:

   • 专为RPC设计的协议：支持多种通信模式，包括请求/响应、双向流、服务器推送等。
   • HTTP/1.1：主要是请求/响应模式。尽管可以使用技术如长轮询来模拟服务器推送，但这不是最佳的方法。
   • HTTP/2：支持多种模式，如双向流和服务器推送，因此与专为RPC设计的协议更为相似。

3. 开发友好度:

   • 专为RPC设计的协议：通常需要更多的开发工具和库，如IDL（接口定义语言）工具，用于生成客户端和服务器代码。
   • HTTP：更为普遍且通用，开发者可能已经熟悉它。但为HTTP创建RPC风格的API可能需要更多的手工编码。

4. 互操作性和生态系统:

   • 专为RPC设计的协议：可能需要特定的库和工具，这可能限制了其与其他系统的互操作性。
   • HTTP：由于其普遍性，它具有广泛的互操作性和强大的生态系统。

5. 安全性:

   • 两者都支持加密和认证机制，但具体的实现和工具可能会有所不同。

6. 传输协议:

   • 专为RPC设计的协议：虽然许多都是基于TCP的，但它们可能会使用特定的传输协议，如gRPC使用HTTP/2。
   • HTTP：可以运行在多种传输协议上，但通常是TCP。

总的来说，选择使用专为RPC设计的协议还是HTTP进行RPC主要取决于应用的具体需求，例如性能、开发经验、互操作性等因素。

3.2 说一下你这个自定义协议的结构

答：

3.3 你用的是哪种序列化协议，为什么不考虑kryo，json这种序列化协议呢

答：我和json做了一下对比

我基于OpenAI的设计决策，并不直接决定使用哪种序列化协议。但我可以为你解释为什么在某些应用中，人们可能选择Protocol Buffers而不是Kryo、JSON等其他序列化格式。

1. 性能和效率:

   • Protocol Buffers (ProtoBuf): 是一个二进制格式，非常高效，尤其在序列化和反序列化时。由于其紧凑的特性，ProtoBuf在网络传输和存储时也十分高效。
   • Kryo: 是一个高效的Java序列化库，也是二进制的，通常比Java的默认序列化更快。但Kryo主要针对Java，而ProtoBuf是跨平台和跨语言的。
   • JSON: 是文本格式，通常比二进制格式大并且序列化/反序列化速度相对较慢。但其可读性好并且被广泛支持，非常适合Web API和配置。

2. 跨语言支持:

   • ProtoBuf: 支持多种语言，如Java、C++、Python、Go等。这使得在不同的系统和语言之间进行通信变得简单。
   • Kryo: 主要为Java设计。如果你的系统完全基于Java，Kryo可能是一个很好的选择，但它不如ProtoBuf那么灵活。
   • JSON: 几乎所有编程语言都支持，非常通用。

3. 模式的演进:

   • ProtoBuf: 允许你在不破坏向后兼容性的情况下修改数据结构。这在分布式系统中，特别是在需要进行持续部署的环境中，是非常有价值的。
   • Kryo & JSON: 对模式的变更可能不那么友好，尤其是在大型、快速变化的系统中。

4. 可读性与调试:

   • ProtoBuf: 由于是二进制格式，不如文本格式易于阅读和调试。
   • Kryo: 也是二进制格式，具有与ProtoBuf相同的限制。
   • JSON: 易于阅读和调试，因为它是文本格式。

5. 生态系统和工具支持:

   • ProtoBuf: 有一个成熟的生态系统，包括代码生成、文档工具等。
   • Kryo: 为Java生态系统提供了良好的支持，但不像ProtoBuf那样广泛。
   • JSON: 有大量的库和工具可供选择。

总之，选择哪种序列化协议取决于具体的需求。ProtoBuf在许多高性能、大规模和跨语言的应用中是首选，但在特定的上下文中，Kryo或JSON可能更为合适。

4 tomcat

4.1 tomcat和netty的区别

答：

Tomcat：

• 类型: Tomcat是一个Java Servlet容器和Web服务器。它能够执行Java Servlet和呈现JSP页面。
• 使用: 主要用于部署和运行Java EE应用。
• 性能: 尽管Tomcat进行了优化，但它可能不如专门设计的非阻塞框架如Netty那样高性能。
• 模型: Tomcat使用多线程模型来处理并发请求，通常为每个请求创建一个线程。

Netty：

• 类型: Netty是一个高性能、异步的、基于事件驱动的网络应用框架。它支持多种协议。
• 使用: 主要用于开发高性能、高可靠性的网络应用，如RPC框架。
• 性能: Netty是为高并发、高性能设计的，使用了非阻塞I/O。
• 模型: Netty使用事件驱动模型，可以轻松处理成千上万的并发连接。

4.2 tomcat打破双亲委派模型的目的是什么

答：

双亲委派模型的主要目的是为了保证Java核心库的类型安全性。但是，在Web容器环境中，如果遵循传统的双亲委派模型，可能会遇到一些问题。例如，如果两个Web应用部署在同一个容器中并且它们使用了不同版本的同一个库，传统的委派模型可能会导致其中一个应用获取到错误的库版本。为了解决这个问题并为Web应用提供更大的灵活性，Tomcat选择打破了传统的双亲委派模型。

4.3 tomcat如何打破双亲委派的

Tomcat引入了一个叫做Web Application Classloader的特殊类加载器。按照传统的双亲委派模型，类加载器首先会委托给其父加载器来加载类；只有当父加载器无法加载该类时，类加载器才尝试自己加载该类。

但在Tomcat中，Web Application Classloader会首先尝试加载Web应用下的类，如果没有找到，它才会委派给其父加载器。这样，Web应用就可以自由地使用自己的库版本，而不受共享库的影响。

这种做法确实打破了传统的双亲委派模型，但它为Web应用提供了更大的灵活性，并解决了多个应用在同一个容器中共存时可能遇到的库冲突问题。

5 故障排查

5.1 如何完成故障排查的，举个例子

答：

5.2 有没有使用arthas排查出性能问题，然后做出优化

答：

5.3 如果你负责的项目，经常发生ygc，是什么原因

答：

我的答案：

（1）内存泄露，资源没有回收

（2）应用不断new出新的对象

（3）minorGC时的并发线程数设置的过低，回收速度赶不上

gpt4答案：

经常发生Young GC（YGC）可能是由多种原因导致的。以下是一些常见的原因及其描述：

1. 短生命周期的对象产生过多：

   • 如果应用创建了大量的短生命周期的对象（即对象很快被创建然后变得不可达），这些对象会迅速填满年轻代（Young Generation）并触发YGC。

2. 年轻代空间设置不当：

   • 如果年轻代的大小设置得太小，YGC可能会频繁发生。你可以考虑调整年轻代的大小来适应应用的需求。

3. 代码存在不良的数据结构或算法：

   • 例如，使用了产生大量临时对象的循环或算法。

4. 外部因素：

   • 如频繁的文件I/O操作、数据库查询等，可能间接导致大量的临时对象创建。

5. 使用了不适合的框架或库：

   • 某些框架或库可能在内部创建了大量的临时对象。

6. 频繁的字符串操作：

   • 如大量的字符串拼接操作可能会产生大量的临时字符串对象。

7. 频繁使用了缓存：

   • 如果缓存策略或大小设置不当，可能会导致大量的对象进入年轻代。

8. 应用负载突然增大：

   • 如应用突然接收到大量请求，可能会短时间内产生大量的临时对象。

要诊断和解决频繁的YGC，你可以采取以下措施：

• 使用JVM监控工具，如jstat、VisualVM或Java Mission Control，来查看GC的频率、持续时间和内存使用情况。

• 使用Java的堆分析工具，如HeapDump或jmap，来查看哪些对象占用了最多的年轻代空间。

• 根据上述工具的输出，调整年轻代大小或优化代码来减少短生命周期的对象的产生。

• 在优化后，持续监控以确保问题得到了解决。

5.4 YGC的根引在哪儿

答：方法区，栈帧中的局部变量表中，也存在引用，同时还有常量池

5.5 针对不断new出的对象，如何解决

答：单例

针对不断被new出来的对象，以下是一些解决方案和建议：

1. 对象池化:

   • 对于经常创建和短时间内就被销毁的对象，你可以使用对象池。例如，Apache Commons Pool 提供了一种通用的对象池化解决方案。通过重用对象，你可以减少需要频繁创建和销毁的对象的数量，从而减少GC的压力。

2. 减少临时对象的创建:

   • 优化代码，避免创建不必要的临时对象。例如，对于字符串操作，可以考虑使用StringBuilder或StringBuffer来减少临时字符串的创建。

3. 优化数据结构和算法:

   • 审查代码中使用的数据结构和算法，确保它们不会产生大量的临时对象。

4. 缓存:

   • 对于经常被创建但状态不经常改变的对象，可以考虑使用缓存来存储这些对象，而不是每次都重新创建。

5. 延迟对象的创建:

   • 只有在真正需要对象时才创建它，而不是预先创建。

6. 调整JVM参数:

   • 调整Young Generation的大小，这可能会影响YGC的频率和持续时间。

7. 使用单例：单例能够节约空间，避免对象的重复创建