【校招】2023-9-19 携程火车票后端一面

1 实习

1.1 详细介绍一下架构实例反向同步到架构定义这个需求

1.2 代码量是如何由3000行缩减到1000行的

3 spring

3.1 讲讲IOC

当我们谈论 Spring 框架时，IOC（Inversion of Control）是其核心概念之一。以下是关于 Spring 中的 IOC 的详细介绍：

1. 什么是 IOC？

IOC，即“控制反转”，是一种设计原则，用于将对象的创建、配置和管理从传统的程序代码转移到外部容器。在 Spring 中，这个外部容器就是 Spring 容器。

2. 为什么需要 IOC？

• 解耦：IOC 可以帮助我们将应用程序的各个组件解耦，使得组件之间的依赖关系更加灵活。
• 代码管理：通过外部配置文件管理对象，我们可以轻松地更改对象的行为而不必修改源代码。
• 生命周期管理：Spring 容器负责对象的整个生命周期，从创建到销毁。

3. 如何实现 IOC？

在 Spring 中，IOC 是通过 DI（依赖注入）来实现的。DI 是一种技术，通过它，对象只需定义其依赖项，而不必自己创建或查找它们。Spring 容器负责注入这些依赖项。

4. 依赖注入的方式：

• 构造器注入：通过构造函数将依赖注入到对象中。
• Setter 注入：通过 setter 方法将依赖注入到对象中。
• 方法注入：Spring 也支持通过任意方法注入依赖。

5. Spring 容器：

Spring 容器是实现 IOC 的核心组件。它读取配置文件，创建对象，管理它们的生命周期，并为它们注入依赖。

常见的 Spring 容器有：

• BeanFactory：最基本的容器，提供基础的 DI 支持。
• ApplicationContext：是 BeanFactory 的扩展，提供了更多的高级特性，如事件传播、资源加载等。

6. Bean 的生命周期：

在 Spring 容器中，对象（称为“Bean”）的生命周期如下：

1. Bean 定义从配置文件中读取。
2. Bean 实例化。
3. 依赖注入。
4. 如果 Bean 实现了 BeanNameAware 接口，容器调用 setBeanName 方法传入 Bean 的 ID。
5. 如果 Bean 实现了 BeanFactoryAware 接口，容器调用 setBeanFactory 方法传入 BeanFactory 实例。
6. BeanPostProcessor 的 postProcessBeforeInitialization 方法被调用。
7. 如果 Bean 实现了 InitializingBean 接口，容器调用 afterPropertiesSet 方法。
8. 如果 Bean 在配置文件中定义了 init-method，指定的初始化方法被调用。
9. BeanPostProcessor 的 postProcessAfterInitialization 方法被调用。
10. Bean 可以被应用程序使用了。
11. 当容器关闭时，如果 Bean 实现了 DisposableBean 接口，容器调用 destroy 方法。
12. 如果 Bean 在配置文件中定义了 destroy-method，指定的销毁方法被调用。

这就是 Spring 中的 IOC 和相关概念的简要介绍。希望对您有所帮助！

3.2 讲讲AOP

4 java基础

4.1 线程池在哪些场景中使用

4.2 你怎么自定义线程池，用了什么参数

4.3 java synchronized锁升级过程讲解一下

答：

5 秒杀系统

5.1 库存如何管理的

答：增量库存，防止超卖，库存回退

5.2 mysql的库存同时增和减如何做到数据安全的呢，比如大量用户请求下单的同时，一部分用户取消订单了

答：分布式锁

5.3 多级限流器是指什么

答：nginx，api-gateway，接口级别的限流

5.4 接口的限流怎么做的

答：

5.5 接口限流是怎么做的

5.6 你的秒杀系统是基于微服务架构的，讲讲你对微服务架构的理解，拆分原则

答：

微服务架构是一种将单一应用程序设计为一组小的、独立的服务的方法，这些服务运行在自己的进程中，通常都围绕业务功能进行设计，并通过轻量级的机制（如HTTP的RESTful API）进行通信。以下是我对微服务架构的理解和拆分原则：

微服务架构的理解：

1. 独立性：每个微服务都是独立的，可以单独部署、升级和扩展。
2. 分布式开发：由于微服务是独立的，团队可以并行开发多个微服务。
3. 去中心化：微服务架构倾向于去中心化的数据管理和去中心化的服务治理。
4. 故障隔离：一个微服务的失败不应该影响其他服务。
5. 技术多样性：团队可以根据微服务的需求选择最适合的技术栈。
6. 细粒度的可扩展性：可以根据需求对特定的微服务进行扩展，而不是整个应用。
7. 持续交付和部署：由于微服务的小和独立，可以实现快速、频繁和可靠的部署。

微服务拆分原则：

1. 单一职责原则：每个微服务应该有一个明确的、单一的功能或职责。
2. 业务驱动：微服务应该围绕业务功能或业务领域进行设计和拆分，例如订单服务、用户服务等。
3. 共享最少：微服务之间应该尽量减少直接的依赖和共享，以保持独立性和解耦。
4. 数据分离：每个微服务应该有自己的数据库和数据存储，以避免数据管理的复杂性。
5. 避免过度拆分：虽然微服务应该小，但不应该过小，以避免增加管理和通信的复杂性。
6. 考虑性能和延迟：在拆分微服务时，需要考虑服务间通信的性能和延迟。
7. 团队组织结构：有时，微服务的拆分也可以根据团队的组织结构进行，使每个团队负责一个或多个微服务。

微服务架构提供了一种灵活、可扩展和可维护的方法来构建大型应用程序，但它也带来了一些挑战，如服务发现、负载均衡、数据一致性等。因此，选择微服务架构需要根据具体的业务需求和团队能力进行权衡。

5.7 使用微服务架构的优缺点

答：

微服务架构作为一种流行的软件设计方法，有其明确的优点和缺点。以下是使用微服务架构的主要优缺点：

优点：

1. 灵活性和可扩展性：微服务可以独立部署和扩展，这使得对特定服务的扩展变得更加容易。
2. 技术多样性：每个微服务可以使用最适合其业务需求的技术栈。
3. 故障隔离：一个微服务的故障不会直接影响其他服务，提高了系统的整体稳定性。
4. 独立部署和持续交付：微服务可以独立部署，这使得持续集成和持续交付变得更加简单和快速。
5. 团队自治：团队可以独立地开发、部署和维护自己的服务，提高了开发效率。
6. 优化资源使用：可以根据每个服务的需求进行资源分配，如CPU、内存等。
7. 易于维护和迭代：由于每个服务都是小的和专注于特定功能，它们更容易维护和迭代。

缺点：

1. 复杂性增加：管理多个微服务比管理单一的大型应用更复杂。
2. 网络通信问题：微服务之间的通信可能会导致网络延迟和数据不一致性问题。
3. 数据一致性：由于每个微服务可能有自己的数据库，保持数据的一致性变得更加挑战。
4. 部署挑战：需要管理和部署更多的服务和数据库。
5. 服务发现和负载均衡：随着服务数量的增加，服务发现和负载均衡变得更加重要和复杂。
6. 版本管理：不同的微服务可能需要不同的版本，这需要一个有效的版本管理策略。
7. 安全挑战：每个微服务都可能成为攻击的目标，需要确保每个服务都有适当的安全措施。

总的来说，微服务架构提供了很多优势，特别是对于大型和复杂的应用程序，但它也带来了一些挑战。在决定是否采用微服务架构时，需要根据项目的具体需求和团队的能力进行权衡。

5.8 你的秒杀系统是如何保证一致性的

答：

5.9 你觉得哪些场景不适合用微服务的呢

答：

微服务架构虽然带来了许多优势，但并不是所有场景都适合使用它。以下是一些可能不适合使用微服务架构的场景：

1. 小型项目：对于小型或简单的项目，使用微服务可能会引入不必要的复杂性。在这种情况下，单体架构可能更为合适。

2. 团队经验不足：如果团队缺乏微服务架构的经验或知识，尝试采用微服务可能会导致许多问题，如不恰当的服务拆分、网络问题等。

3. 紧密耦合的业务逻辑：如果业务逻辑高度耦合，拆分成多个服务可能会导致大量的跨服务通信，从而降低性能。

4. 快速原型开发：在早期的产品或项目阶段，可能需要快速迭代和验证。在这种情况下，微服务可能会增加开发和部署的复杂性。

5. 资源限制：对于有限的资源或预算的项目，管理和维护多个服务和相关的基础设施可能是一个挑战。

6. 技术限制：在某些技术堆栈或平台上，实现微服务可能会遇到限制或挑战。

7. 数据一致性要求高：如果应用需要强数据一致性，微服务可能不是最佳选择，因为跨服务的数据同步和事务管理可能会变得复杂。

8. 网络不稳定：在网络不稳定或带宽有限的环境中，微服务之间的通信可能会成为瓶颈。

9. 安全考虑：如果应用有严格的安全要求，微服务可能会引入更多的安全风险，因为每个服务都需要进行适当的安全配置和管理。

10. 集成第三方系统：如果应用需要与多个第三方系统紧密集成，微服务可能会增加集成的复杂性。

总之，虽然微服务架构为许多场景提供了优势，但在决定是否采用它之前，需要仔细评估项目的具体需求、团队的能力和潜在的挑战。

6 反问

6.1 你们是哪个部门的

答：火车票部门，其实还包括船票，但是不包括飞机票

6.2 你们现在处于扩张期还是恢复期呢

答：这个分业务，国内业务今年属于已经超过疫情前期了，国际业务因为处境限制还没达到历史最高点

6.3 还有几轮面试

答：过了的话，还有一轮技术+hr

6.4 你们部门的技术栈

答：redis，mysql这些都会用，集团内部一般有一套主流的推荐，比如ES，Ocean，mongodb之类的

6.5 你们大多是自研吗

答：其实都算是自研的，因为有一些中间件发现了高危漏洞，可能强制升级，为了实现升级的兼容，通常都会在这个上面做一层封装的。

6.6 我过了吗

答：我们会打分，然后会和其他同学进行对比