经典面试题

Archie丶z

已于 2023-06-27 10:12:28 修改

阅读量484

点赞数

文章标签： java 数据库 redis

于 2023-06-15 17:06:02 首次发布

本文链接：https://blog.csdn.net/qq_53205308/article/details/131230303

版权

sql优化

1、确定正确的索引

索引是数据库优化的主要手段之一。在表中添加索引可让数据库更快地搜索和筛选数据。应该对经常查询的列添加索引，以提高查询性能。但是，对于数据重复率较高的列，不要过度使用索引，因为它们会影响写入性能，甚至影响查询性能。此外，注意要对联合索引的列顺序进行优化，以便充分利用索引。

2、避免多重连接和嵌套查询

避免在查询中多次连接和嵌套子查询，这些操作可能会导致查询性能下降，并且可能使查询变得复杂和难以理解，同时使用多个连接可增加数据库交互的成本。考虑使用JOIN语句来代替嵌套查询，并避免使用子查询。

3、使用批量操作

一次性的批量操作会比许多单个操作更快，尽量减少频繁的交互。例如，使用INSERT INTO语句插入多行数据，而不是单个INSERT INTO 语句。

4、避免在查询中使用 DISTINCT

DISTINCT关键字会调取数据表中的所有唯一值，这会消耗更多的资源。如果可以，应该尝试避免使用 DISTINCT，以提高查询性能。

5、避免使用通配符

通配符的使用可能会导致查询变得缓慢，尤其是在大型表中使用。使用 LIKE 或 % 操作符的查询要谨慎，可考虑用其他条件替代。

6、优化查询语句

尽可能使用简单的查询语句进行数据访问，避免不必要的复杂查询，也要考虑SQL语句在编写时候的规范性。

7、分批次返回数据

如果你的查询会返回大量行数，可以考虑使用分页技术将结果分成多个批次返回，这可以减少服务器的负担，加快用户访问速度。

8、避免使用 OR 操作符

多个条件之间使用 OR 操作符可能会导致查询变得缓慢，因为它不利于索引的使用。如果可以，应该尽量避免使用 OR 操作符，或者考虑使用 UNION 命令来组合多个查询。

9、正确的分区和归档

对于大型表，通常需要进行表分区和表归档，以提高查询性能和数据管理效率。

mysql查看索引

MySQL 提供了多种方法来查看表的索引信息，以下是一些常用方法：

1. DESC 表名

使用 DESC 命令可以查看表的元数据信息，包括表的结构和索引信息。例如：

DESC table_name;

这个命令会返回表的字段名称，数据类型，空值约束，键等。

2. SHOW INDEXES FROM 表名

使用 SHOW INDEXES FROM 命令可以查看表的索引信息，如索引名、字段名等。例如：

SHOW INDEXES FROM table_name;

这个命令会返回表的索引名称、索引类型、关联字段、独特性、区分度等信息。

3. EXPLAIN SELECT 命令

在 SELECT 语句中使用 EXPLAIN 命令可以查看查询计划、索引使用情况等详细信息。例如：

EXPLAIN SELECT * FROM table_name WHERE col_name = 'value';

这个命令会返回查询计划和使用的索引的信息。在这个命令中，您可以看到是否使用了索引，以及使用哪些索引。

4. INFORMATION_SCHEMA database

使用 INFORMATION_SCHEMA 数据库可以查询表、索引等的详细信息。例如：

SELECT * FROM information_schema.statistics WHERE table_name = 'table_name';

这个命令会返回表的主键、索引、列名等详细信息。INFORMATION_SCHEMA 还提供了其他有关数据表和索引的各种信息，例如如何确定约束、表空间等。

MQ:

1、常用消息中间件有哪些？

Kafka：由Apache软件基金会创建的分布式流处理平台，支持高吞吐量的消息处理，可用于数据传输、日志传输、流式处理等场景。
RabbitMQ：一个开源的消息队列系统，基于AMQP（高级消息队列协议）实现，支持多种编程语言，易于部署和维护。
ActiveMQ：是一个可扩展的开源消息代理，支持多种协议（包括AMQP、STOMP、MQTT、OpenWire等），可用于异步通信、消息传递等场景。
Redis：一个高性能的键值存储系统，也可以用作消息中间件。它支持发布/订阅模式和消息队列模式来处理消息，也支持多种编程语言。
ZeroMQ：是一个开源的高性能消息中间件，可在单机或多机环境下使用，支持多种消息传递模式，包括发布/订阅模式、请求/响应模式等。

2、如何保证消息可靠性

保证消息的可靠性是消息中间件的一个重要特征。消息中间件要保证消息的发送、接收、处理过程中不会丢失、重复、乱序等问题。以下是几种保证消息可靠性的常用方法：

持久化：将消息存储到磁盘或数据库中，这样即使消息中间件宕机重启后也可以恢复消息。
确认机制：消费者在处理消息之后向消息中间件发送确认消息，告知消息中间件该消息已经被正常处理。如果消费者在接收到消息后未能及时确认，那么消息中间件可以重新发送该消息。
可靠性传输协议：使用TCP等可靠性传输协议来保证消息的可靠传输，防止网络丢包等现象。
幂等性设计：即对同一条消息的多次处理和对一条消息的一次处理效果相同，这样可以防止重复处理消息的问题。
消息重试：当消息处理失败时，消息中间件可以自动将消息重新发送给消费者，直到消息被正确处理为止。

3、什么是死信交换机

死信交换机（Dead Letter Exchanges，DLX）是一种用于处理无法被消费的消息的机制。当消息被拒绝、消息过期或者消息的队列达到了最大长度，会被转发到死信交换机。

处理死信交换机中的消息，可以采取以下两种方式：

重新投递：将死信消息重新投递到原有的队列或者交换机中，这样可以避免消息的丢失，同时可以让消费者重新处理该消息。
移除消息：将死信消息从队列中删除，避免对消息的无限次重试。

死信交换机通常会和Routing Key等配合使用，这样可以将一些特定的消息转发到对应的死信交换机中。例如，当消息无法被消费时，就可以将其转发到死信交换机中，然后再将该死信队列的信息发送给开发人员，以便调查分析。

4、交换机类型有哪些

直接交换机（Direct Exchange）：将消息通过确定的“路由键”转发到绑定的队列中。如果消息和队列绑定的路由键一致，则该消息将被路由到对应的队列中。
主题交换机（Topic Exchange）：将消息通过匹配的规则转发到相应的队列中。这种交换机可以根据绑定的路由键进行模糊匹配，例如使用“*”进行单个单词通配符匹配，使用“#”进行多个词通配符匹配等。
扇形交换机（Fanout Exchange）：将消息广播到所有绑定到该交换机的队列中。这种交换机不关心路由键，只要有队列绑定到该交换机中，消息都会被传送到这些队列中。
头交换机（Headers Exchange）：根据消息头中的属性进行路由，而不是像其他交换机那样基于路由键进行路由。在此种交换机中，消息头中的属性需要与队列的匹配规则直接匹配。

5、如何解决消息堆积问题

消息堆积是一种常见的问题，它可能导致消息队列中消息的积压，进而导致性能的下降和延迟的增加。以下是一些解决消息堆积问题的常见方法：

增加消费者数量：增加消息队列消费者的数量可以加快消息的处理速度，从而减少消息堆积的发生概率。

提高消费者的处理能力：优化消费者端的代码、调整消费者的资源配置等方式可以提高消费者的消息处理速度，缓解消息堆积的问题。

扩容消息队列：通过扩容消息队列节点的数量，可以增加消息队列的吞吐量，从而减少消息堆积的风险。

设置消息 TTL：在消息发布时，设置消息的TTL，当消息过期时，可以自动将其清除，防止消息过期后继续占用队列资源。

使用分布式锁：在消息处理时使用分布式锁，可以防止多个消费者同时处理同一个消息，从而提高消息处理效率。

预取限制：在拉取消息时控制拉取的消息数量，并及时确认处理完的消息，这样可以避免一次性拉取大量消息导致的消息堆积问题。

6、如何解决MQ消息重复消费

MQ消息重复消费是一个常见的问题，可能会导致数据的重复处理或数据处理的不一致性。以下是一些解决MQ消息重复消费问题的常见方法：

增加幂等性：通过在生产者和消费者中增加唯一性标识，可以避免相同数据被多次处理，从而避免重复消费。

消费者互斥：通过设置同一时刻只有一个消费者能消费并处理消息的方式，即同一条消息在多个消费者中只能被其中一个消费者处理，避免重复消费。

消息状态标记：在处理消息时，将该消息的处理状态标记在数据库中，当收到已经标记为已处理的消息时，直接忽略该消息，从而避免重复消费。

消息过期时间：设置消息的过期时间，在消息过期后不再处理消息，避免在处理过期消息时重复消费。

消息去重：通过消息队列本身提供的特性，如afka的Exactly Once或RocketMQ的去重复机制，避免消费者重复消费。

SpringCloud

1、CAP/BASE理论

CAP理论是指一种关于分布式系统一致性、可用性和网络分区容忍性之间的权衡的理论。CAP代表Consistency、Availability和Partition tolerance，其中一致性指的是所有节点在同一时间给出相同的数据；可用性指系统可用性高，即时响应用户请求；分区容忍性指即使系统中某些节点之间无法通信，仍然能够继续正常工作。

也就是说，CAP理论认为在分布式系统中，无法同时保证一致性、可用性和分区容忍性，只能在这三者之间进行取舍，具体的取舍方式需要根据具体业务需求和系统特点进行选择。

而BASE理论是对CAP理论的一种补充和具体实践，BASE代表基本可用，软状态和最终一致性。BASE理论认为对于大规模分布式系统，完全一致性会带来很高的资源消耗和性能开销，因此可以允许系统在一定程度上保持软状态，并以最终一致性为目标，从而提高系统的可用性和性能。基本可用则指系统要能基本可用，即时部分功能失效也不能影响整个系统的可用性。

2、RPC和JRPC的区别

RPC（Remote Procedure Call，远程过程调用）是指一个计算机节点上的程序调用另一个节点上的程序，就像调用本地程序一样，不同的是调用的是远程的程序。RPC框架能够使得开发者像调用本地函数一样调用远端服务器上的函数，简化了远程过程调用的实现过程。

JRPC（JSON-RPC）是基于JSON格式编码的轻量级RPC协议。与其他RPC协议不同，JRPC使用JSON作为消息传递格式，并使用HTTP或其他可靠传输协议来传输RPC请求和响应。JRPC不依赖特定的编程语言或平台，可以跨越各种编程语言和操作系统。

因此，两者的主要区别在于：

1. 数据传输格式不同：RPC可以使用二进制或文本等格式进行数据传输，而JRPC只使用JSON格式进行数据传输。

2. 序列化和反序列化方式不同：RPC使用二进制编码方式对数据进行序列化和反序列化，而JRPC采用JSON格式进行序列化和反序列化。

3. 功能复杂度不同：相对于RPC来说，JRPC的功能相对简单，而且使用更加方便，同时JRPC也对跨平台跨语言的实际情况提供了一个良好的解决方案。

3、RPC和Http的区别

HTTP（HyperText Transfer Protocol，超文本传输协议）是一种在计算机世界里，用于传输超文本文件的，通过因特网进行通信的协议。HTTP协议是建立在TCP/IP协议基础上传输数据的，常用于浏览器和服务器之间的数据通信。

下面是RPC和HTTP的主要区别：

1. 通信协议不同：RPC通常使用二进制协议，以提高通信的效率和安全性，而HTTP协议则使用文本协议（以HTTP包为基础），因此RPC的传输方式可以更灵活，且协议开销比HTTP小。

2. 序列化和反序列化方式不同：RPC通常使用一些特定的序列化协议，如protobuf、Apache Avro等，而HTTP则使用通用的文本数据格式，如JSON或XML。

3. 功能复杂度不同：RPC框架通常提供更为丰富和复杂的功能，比如支持异步调用、流式传输等，而HTTP通常只提供单向的请求响应操作。

4. 安全机制不同：RPC框架通常会提供一些安全机制，如身份验证和加密等，而HTTP则需要通过其他的安全协议（如HTTPS）来保证通信安全。

总之，RPC和HTTP都是应用程序之间通信方式的代表，根据不同的场景和需求，可以使用不同的通讯协议进行数据传输。

4、Eureka注册中心有什么用

Eureka是Netflix开源的一款服务发现工具，常用于构建微服务架构中的注册中心。 Eureka提供了REST API的方式进行服务注册、发现、查看和监控，是一个分布式的、可复制的、高可用的服务治理组件。

Eureka注册中心主要用于以下方面：

1. 服务发现和注册：Eureka提供了服务发现和注册功能，当有新的服务实例加入或下线时，Eureka会更新注册表，并通知其他服务实例。服务能够自动地发现和使用其他服务的实例。

2. 服务负载均衡：Eureka可以帮助实现基于可用性的负载均衡，根据负载情况自动选择可用的服务实例进行调用。

3. 服务监控和故障切换：Eureka可以监控服务实例的运行状态，当服务发生故障时，可以自动地从其他可用的服务实例中选择切换过去。

4. 服务扩展和缩减：通过Eureka可以方便地实现服务扩展和缩减，只需要向Eureka注册中心注册或注销服务实例即可。

总之，Eureka注册中心为构建微服务架构提供了一个高效的服务治理和发现组件，可以帮助开发者简化服务的管理和部署，提高服务的可用性和可扩展性。

5、注册中心如何保证服务可用

在分布式系统中，注册中心是一个关键组件，服务的可用性直接影响到整个系统的可用性。以下是几种保证注册中心服务可用性的方法：

1. 高可用性部署：采用集群部署，通过多节点实现注册中心的高可用性，任意节点发生故障时，其他节点可以顶替它继续提供服务。

2. 容错与故障转移：注册中心需要具备容错能力，在节点崩溃时，集群可以快速知道其故障，并将该节点从集群中移除或禁止节点接收新的请求，并在其余节点中重新选择一个主节点来继续提供服务。

3. 心跳监测机制：注册中心通过心跳机制监测服务的可用性，服务提供者通过定期发送心跳包告知注册中心服务的运行状态，若长时间未收到心跳包，则认为服务宕机，将其从注册中心中移除。

4. 数据备份和恢复机制：注册中心需要有数据备份和恢复机制，在节点崩溃时能及时恢复数据，避免数据丢失。

5. 可视化和监控：通过监控注册中心的状态和服务的健康状况，及时发现问题，方便快速定位和解决问题。

6、服务降级和熔断降级是什么

服务降级和熔断降级都是为了提高系统的可用性和稳定性，处理系统遇到异常情况下的访问请求，但它们的实现方式和应用场景不同。

1. 服务降级

服务降级指的是针对服务的不同情况，实际响应不同的服务，以保证基础服务的优先级和可用性，比如在高峰时期将部分不必要的服务暂时停止，以保证核心服务的正常运行。常见的服务降级方式有：

- 返回默认值：若服务不可用或出现故障，直接返回预定义的默认值。
- 返回空值或错误码：若服务不可用或出现故障，直接返回空值或错误码。
- 返回缓存值：若服务不可用或出现故障，直接返回之前缓存的请求结果。

2. 熔断降级

熔断降级指的是在微服务中，当一个服务出现错误或超时时，就会将该服务的请求熔断，直接返回一个预设的错误值或默认结果，而不会真正去请求该服务，这样可以有效避免由该服务造成的雪崩效应。熔断降级的主要目的在于减少资源的消耗，并将流量切换到其他请求正常的服务上进行处理。

总之，服务降级和熔断降级都是处理系统遇到异常情况下的访问请求的措施，它们的实现方式和应用场景不同，服务降级主要是为了保证基础服务的正常运行，而熔断降级则是为了避免不稳定服务对整个系统的影响。

7、Hystrix的执行原理

Hystrix是Netflix开源的一款熔断框架，主要用于处理分布式系统中依赖服务间的失败和延迟问题。它通过提供熔断、隔离、降级和监控等多种功能来增强系统的容错性和稳定性，避免由于某一个依赖服务故障引起整个系统的崩溃。

Hystrix的执行原理如下：

1. 对命令进行封装：开发者使用Hystrix构建一个对象继承自HystrixCommand（同步）或HystrixObservableCommand（异步），在对象的构造函数中，指定调用远程服务的方法、超时时间和熔断策略等信息。Hystrix会对该命令进行封装和隔离，当远程服务不可用时，命令会直接被降级或进行熔断处理，避免等待超时或继续执行导致的资源浪费。

2. 熔断器的开启与关闭：当系统出现异常或者延迟时，Hystrix会记录相应的指标，如果这些指标达到一定阈值，Hystrix会自动开启熔断器，将请求转向降级程序。当熔断器关闭之后，一段时间内部分请求会重新调用远程服务，以便重新检测远程服务是否恢复正常。

3. 断路器的状态切换：Hystrix内置了断路器来实现熔断处理，当熔断器达到一定状态之后，Hystrix会自动地进行状态的转换，进入断开远程服务的状态。当熔断器再次感知到远程服务的恢复，会重新进行请求的执行。

4. 资源的隔离：Hystrix会将服务隔离在单独的线程池中，保证熔断的时候只会影响到自己这个服务的线程池，避免由于某一个服务的不稳定造成整个应用的崩溃。

5. 监控和统计：Hystrix会将线程池的使用情况、请求响应时间、断路器状态等指标进行监控和统计，开发者可以通过监控接口对这些指标进行访问和分析，以便于进行性能的优化和调试。

总之，Hystrix通过封装命令、熔断器、隔离器和监控等多种机制，增强了系统的容错性和稳定性，在分布式系统中可有效处理依赖服务的失败和延迟问题。

8、Feign的作用

Feign是一个声明式的 HTTP 客户端框架，主要用于简化调用 HTTP API 的流程，减少样板代码以及提供一致的异常处理机制，从而使客户端和服务端的接口定义更容易维护。

Feign的主要作用有：

1. 服务调用：Feign可以通过简单的接口注解绑定服务接口，然后调用远程服务。它可以自动生成请求代理，隐藏了底层的 HTTP 客户端实现，使得客户端使用 HTTP 客户端调用服务更加简单方便，也可以更快的上手使用。

2. 接口映射：Feign基于接口定义的注解，生成实际的请求处理代码。客户端只需要调用注解绑定的接口方法，而无需关心具体请求地址和请求参数的处理。

3. 负载均衡：Feign集成了Ribbon，可支持负载均衡。通过使用Eureka或Consul等服务注册中心，Feign可以轻松地实现服务地址的自动发现和选择。

4. 提供了统一的异常处理机制：Feign可以捕获 HTTP 请求异常，并将其封装在自己的异常类型中，从而统一了异常处理机制。

5. 基于动态代理机制，实现请求调用的透明化：Feign底层使用的是动态代理技术，可以帮助开发者实现请求调用的透明化。开发者使用 Feign 就像是调用本地服务一样，完全不需要关心底层的实现细节，从而减少了开发者的编码工作量。

总之，Feign主要用于简化客户端调用 HTTP API 的流程，具有接口映射、统一异常处理、负载均衡等多种功能特性，是构建微服务架构中客户端调用的常用框架。

9、网关的作用有哪些

网关（Gateway）是在分布式系统中对服务进行统一的API入口管理的架构模式，主要作用是提供单一入口，简化了客户端的访问，并统一了请求的处理方式，同时也提供了许多其他的功能特性。

以下是网关的主要作用：

1. API接口聚合：通过网关，客户端可以使用单一的API入口，访问多个微服务，网关将客户端请求路由到对应的微服务提供者，从而减少了客户端的维护成本和请求延迟时间。网关还可以将多个微服务的接口聚合到一个API中，供客户端调用。

2. 安全控制：网关可以提供身份认证、权限控制等安全控制能力，保护微服务免受未授权访问和恶意攻击。

3. 负载均衡：通过网关来实现负载均衡可以让客户端请求分流到多个服务实例，从而提高了服务的稳定性和可用性。

4. 缓存加速：网关可以为微服务提供缓存功能，减少服务的重复计算和查询，从而提高了服务的响应效率和降低了服务的成本。

5. 限流熔断：网关可以对微服务进行限流和熔断控制，防止单个服务的大量请求，降低服务的雪崩效应，从而保证服务的可用性不受影响。

6. 监控统计：网关可以提供服务的监控和统计，对请求失败、请求量、响应时间等指标进行监控，收集到的数据可以让开发团队及时监控和调整服务性能。

总之，网关可以像一个路由器一样统一管理服务的出入口，提供了许多非常有用的功能特性，而且应用业界广泛，是构建微服务架构中常用的组件之一。

10、Nacos和Eureka的区别

Nacos和Eureka都是用于服务发现和注册的开源服务，两者有一些共同的功能，如服务发现、注册和健康检查，但也有许多不同之处。

以下是Nacos和Eureka的区别：

1. 支持的平台和语言：Nacos支持多种平台和语言，如Java、Go、Node.js、.NET、Python等，而Eureka主要是为Java平台开发的。

2. 高可用性和扩展性：Nacos在设计方面更注重高可用性和扩展性，通过集群和高可用保证服务的可用性，并具备更好的横向扩展能力。Eureka则更加注重简洁性和轻量性，对高可用配置需要用户自己搭配复杂的架构。

3. 健康检查：Nacos可以自定义健康检查指标，支持多种健康检查方式，并能向上报服务的健康状态，而Eureka仅支持HTTP方式的健康检查。

4. 支持的注册中心协议：Nacos支持三种注册中心协议，包括DNS（Domain Name System）、RPC（Remote Procedure Call）和HTTP（Hyper Text Transfer Protocol）协议，而Eureka仅支持自己的基于HTTP协议的RESTful API。

5. 配置中心：Nacos提供了配置中心的功能，可以统一管理配置信息，而Eureka没有这样的功能。

6. 服务网格：Nacos支持服务网格，可以轻松实现微服务的治理，包括服务流量、熔断降级、服务限流、访问控制和负载均衡等功能，而Eureka不支持服务网格。

综上所述，Nacos和Eureka在功能方面存在很大的差异，Nacos更加注重在高可用性、扩展性、健康检查、多协议注册等方面强化自己的特性，而Eureka则更加注重轻量级的特性。因此在为与使用者可能根据自身业务和技术的情况选择使用Nacos或Eureka注册中心。

11、Nacos属于AP还是CP

Nacos可以支持AP和CP两种模式。

默认情况下，Nacos采用AP模式，即支持服务的高可用和分区容错性，而数据的一致性需要应用自行保证。这种模式适用于对数据一致性要求不是非常高，在数据丢失的情况下可以通过业务逻辑自行恢复的场景。

当应用对数据的一致性要求比较高时，可以采用CP模式，Nacos也支持这种模式。在这种模式下，Nacos会采用Paxos算法保证数据的强一致性，但会对服务的可用性产生一定的影响，因为Paxos需要在多个节点之间达成一致，这会增加响应时间和复杂性，并且可能会影响整个系统的性能。

综上所述，Nacos支持AP和CP两种模式，可以根据业务场景和需求选择合适的模式。如果数据的一致性要求比较高，可以选择CP模式，否则可以选择默认的AP模式，从而在保证服务高可用的同时，最大化提升系统性能和可扩展性。

12、getway和zuul的区别

Gateway和Zuul是Spring Cloud框架的两个主要组件，用于微服务的路由网关和服务发现。

以下是Gateway和Zuul的主要区别：

1. 架构模型：Gateway基于WebFlux构建，Zuul是基于Servlet容器。Gateway采用非阻塞I/O模型，能够更好地支持响应式编程，处理高并发的请求。而Zuul则是采用的传统的阻塞式I/O模型，在高并发的场景下性能会受到限制。

2. 过滤器链模型：Gateway采用断言（Predicate）和过滤器（Filter）的链式调用模型，更加灵活，每一个过滤器都可以处理请求和响应，自定义性更高。而Zuul则采用过滤器的顺序模型，每一个过滤器处理后将结果传递给下一个过滤器，缺乏灵活性。

3. 路由类型：Gateway支持多种类型的路由规则，如Path、Header、Cookie等，可以更加精细地对请求进行路由。而Zuul则只支持基于Path的路由，功能相对较弱。

4. 服务发现：Gateway支持多种服务发现组件，如Eureka、Consul等，但是对于Kubernetes来说支持不是很友好。而Zuul基于Ribbon客户端负载均衡库进行服务发现和负载均衡，可以轻松地集成到Spring Cloud和Eureka中。

5. 性能和可扩展性：Gateway相对于Zuul的性能更好，并且更加容易水平扩展。同时Gateway还提供了更多的关于WebFlux的自定义参数，保证了更好的可扩展性。

综上所述，Gateway和Zuul都是Spring Cloud中非常重要的路由网关和服务发现组件。Gateway的性能好、扩展性高、功能更强大，适合高并发和响应式场景，而Zuul则是一个成熟和稳定的组件，在基本的路由和服务发现方面工作得很好。选择哪一个取决于业务需求和技术选型。

13、Sentinel和Hystrix的区别

Sentinel和Hystrix都是流行的服务熔断器，用于微服务架构中的故障容错和降级处理。

以下是Sentinel和Hystrix的区别：

1. 基于不同的理念：Hystrix是Netflix公司开源的熔断器，它基于线程池的隔离和断路器来实现故障处理和容错；而Sentinel则是阿里巴巴开源的基于流量控制和降级的弹性治理框架，提供了更精细的、基于QPS的流量控制能力和更全面的指标统计。

2. 适用场景不同：Hystrix适用于服务之间的通信错误和延迟而导致的故障，如读写超时、网络出错等，而Sentinel更适用于服务的请求频率超过阈值、流量过载、排队请求过多等需要进行流量控制和降级处理的场景。

3. 熔断策略不同：Hystrix主要侧重于快速失败，通过熔断、降级等方式保证请求的高可用性。而Sentinel则更侧重于平滑降级，提供了复杂的流量控制、降级和系统保护策略，可自定义熔断规则和熔断器状态流转。

4. 依赖和集成：Hystrix依赖于Netflix的Ribbon、Eureka等来实现服务的注册和发现，而Sentinel则支持各种服务注册中心和各种HTTP、Dubbo和Spring Cloud等服务框架的集成，可与各种微服务框架高度集成。

综上所述，Sentinel和Hystrix虽然都是用于微服务故障容错和降级处理的熔断器，但两者之间有许多不同。Hystrix侧重于快速失败、基于线程池的隔离和断路器的实现，适用于服务之间的通信错误和延迟；而Sentinel侧重于平滑降级、基于流量控制和降级等方式的实现，更适用于请求频率超过阈值、流量过载、排队请求过多等需要进行流量控制和降级处理的场景。两者的功能和特点有其各自的优点，可根据业务需求和技术栈选择适合的熔断框架。

14、什么是单点登录，如何实现

单点登录（Single Sign-On，简称SSO）是指用户只需登录一次，即可访问多个应用系统的业务数据，而不需要在其他应用系统中再次登录的一种技术。

实现单点登录需要一个身份认证中心和多个应用系统。用户首先登录身份认证中心，中心为其颁发一个令牌。在用户访问其他应用系统时，应用系统会携带该令牌向认证中心请求认证，认证中心验证通过后即可允许用户访问对应的应用系统。

实现单点登录的关键在于身份认证中心的设计，它需要为用户提供统一的认证服务，维护用户的身份信息和令牌，并与各个应用系统进行集成，实现对用户的认证和授权。

常见的实现单点登录的技术方案包括：

1. 基于Cookie和Session认证的实现方式：用户登录时将身份信息存储在中心服务器中，中心服务器生成一个令牌并返回给客户端。以后客户端再次访问时，请求中会带上令牌，服务端根据令牌去中心服务器进行认证，认证成功后返回业务数据。

2. 使用基于Token的认证方式：客户端首次请求带上用户名和密码，在服务端进行身份认证成功后，返回Token给客户端，客户端在后续请求中携带该Token即可访问对应的业务系统。

3. 使用OAuth2.0认证协议实现单点登录：基于OAuth2.0协议的认证服务器和客户端的认证方式，将认证登录的数据存储在授权服务器上，通过OAuth协议的令牌机制控制用户的身份认证。

综上所述，实现单点登录需要中心化的身份认证服务器，可以使用Cookie、Session、OAuth和基于Token等各种技术方式实现。通过有效的身份认证设计和一个集中管理的认证服务器，可以保证用户的身份安全和应用系统的可用性，方便了用户的访问和管理。

15、说一下支付流程

支付流程一般包括以下几个步骤:

1. 下单: 用户选择商品或服务后，提交订单，订单信息由商家处理并生成交易号（已售出商品的订单）和付款二维码（待付款订单）。

2. 选择支付方式: 用户在多种支付方式中选择一种，并输入相关信息（如银行账号、密码等）。

3. 绑定并验证: 当选择银行卡或第三方支付方式付款时，需要绑定相关信息（如银行卡号、支付宝账号等），并输入身份验证信息（如验证码、短信验证等）。

4. 支付: 用户点击支付后，付款系统会发送支付请求到相应的支付通道。

5. 支付确认: 支付通道收到支付请求后，根据具体支付方式执行相应的支付操作，包括资金划转、订单状态更新等。

6. 支付结果查询: 用户可以在支付完成后通过商家提供的渠道（如短信、邮件）或查询账单的方式，获取支付结果。

7. 对账和结算: 商家需要对账和确认用户的支付信息，并将成功支付的订单状态更新为已付款。支付渠道进行结算，将用户支付的款项划转到商家的账户中。

不同的支付流程在具体实现中可能存在一些差异，例如第三方支付和线下支付的实现方式可能有所不同。但总体上来说，以上流程是一个比较通用的支付流程，可供参考。

Spring

1、Spring框架用过那些设计模式

Spring框架使用了很多设计模式，以下是其中一些常见的：

1. 依赖注入 (Dependency Injection)：这是Spring框架的核心，通过使用依赖注入模式，Spring可以管理应用程序中的对象及其依赖关系。

2. 单例模式 (Singleton)：Spring默认使用单例模式作为对象的创建和管理方式，这使得应用程序在运行期间可以共享同一个对象实例。

3. 工厂模式 (Factory)：Spring使用工厂模式来创建和管理对象，通过配置文件或注解的方式来指定对应的工厂实现类，从而方便灵活的管理对象的创建过程。

4. 观察者模式 (Observer)：Spring使用观察者模式来实现事件驱动模型，在应用程序中定义事件监听器，当事件发生时，Spring可以自动调用对应的监听器进行处理。

5. 模板方法模式 (Template Method)：Spring使用模板方法模式来实现一些通用的流程或操作，例如JdbcTemplate中定义的execute()方法，将数据库连接、预处理语句、参数绑定、结果集处理等操作封装在一个方法中，方便使用者直接调用。

6. 适配器模式 (Adapter)：Spring使用适配器模式来进行框架与第三方库的适配，例如Spring MVC框架中的HandlerAdapter，将处理Web请求的Controller适配到具体的处理器方法上。

以上是Spring框架常用的一些设计模式，实际上Spring框架使用的设计模式还有很多，不过总的来说，Spring框架的设计理念是轻量级、松耦合、简单易用，这也是它成为最受欢迎的Java企业级应用开发框架之一的原因之一。

2、Bean的生命周期和作用域

在Spring框架中，Bean是指在IOC容器中管理的一个组件，它和Java对象的概念类似，但是具有更加灵活的生命周期和作用域。

Bean的生命周期包括以下几个阶段：

1. 实例化（Instantiation）：在IOC容器中实例化Bean对象，可以通过XML配置、注解或JavaConfig等方式进行定义。

2. 属性设置（Populate properties）：IOC容器通过Bean的Setter方法或直接访问属性的方式为Bean设值。

3. 初始化/后处理（Initialization/Post processing）：IOC容器可以为Bean添加自定义的初始化方法或后处理器，来在Bean初始化之前或之后执行一些特定的操作。

4. 使用（In use）：Bean实例被放到IOC容器中，供其他组件使用。

5. 销毁（Destruction）：IOC容器可以通过回调Bean的自定义销毁方法来清理Bean的资源。

Bean的作用域包括以下几种：

1. Singleton：在所有的应用中只有一个Bean实例，这也是IOC容器默认的作用域。

2. Prototype：每次请求Bean的时候，IOC容器都会创建一个新的Bean实例。

3. Request：在Web环境下每个请求都会创建一个新的Bean实例。

4. Session：在Web环境下每个会话都会创建一个新的Bean实例。

5. Global Session：在Portlet环境下，每个全局会话都会创建一个新的Bean实例。

以上是Spring框架中Bean的生命周期和作用域，理解了这些概念，可以更好的使用Spring框架来进行开发。

3、单例模式

单例模式是一种创建型设计模式，它的目的在于确保一个类只有一个实例，并且提供全局访问点。在单例模式中，类的构造函数被私有化，只有一个静态方法可以获取该类的唯一实例。这个静态方法通常被称为getInstance()方法。

public class Singleton {

   //用来保存唯一的Singleton实例
   private static Singleton instance;

   //将构造函数私有化，禁止外部通过new关键字来实例化该类
   private Singleton() {}

   //通过getInstance()方法来获取唯一的Singleton实例，该方法是静态的，可以直接通过类名调用。
   public static Singleton getInstance() {
      if(instance == null) {
         instance = new Singleton();
      }
      return instance;
   }
}

在上面的示例代码中，我们将Singleton类的构造函数私有化，禁止外部通过new关键字来实例化该类，然后定义了getInstance()方法，通过懒加载的方式来创建单例实例。如果instance变量还没有被实例化，getInstance()方法就会创建一个新的Singleton实例，来保证在整个应用中只有一个Singleton对象。

虽然单例模式能够保证一个类只有一个实例，但在多线程环境下，使用单例模式需要特别注意线程安全的问题，可以通过加锁来保证线程安全，或者使用饿汉式的单例模式来避免线程安全问题。

4、项目中哪里用过AOP

在实际项目开发中，AOP（面向切面编程）经常被用来实现以下一些功能：

1. 日志记录：AOP可以通过在关键方法上添加切面来记录方法的调用信息和输入输出参数，方便进行调试和分析。

2. 安全检查：AOP可以通过在关键方法上添加切面来实现访问控制和身份认证等安全检查。

3. 缓存管理：AOP可以通过在方法上添加切面来实现自动缓存管理，可以在方法调用前检查缓存是否已经存在需要的结果，如果存在则不执行方法，直接从缓存中获取结果。

4. 事务管理：AOP可以通过在关键方法上添加切面来实现事务管理，对于事务性操作，通过AOP的方式来在方法执行前开启事务，在方法执行后提交或回滚事务。

在Spring框架中，AOP是一个非常重要的特性，它可以通过使用AspectJ注解或XML进行配置，来支持以上提到的各种AOP应用场景。通过使用AOP，可以将应用程序的核心业务逻辑与横切关注点分离，提高了代码的复用性和可维护性。

5、Mybatis和hibernate有什么区别

MyBatis 和 Hibernate 都是 Java 开发中流行的 ORM（Object-Relational Mapping）框架，它们都是用来应对关系型数据库和Java对象之间的映射，但是在实现机制和使用方式上有一定的区别：

1. 映射方式：MyBatis 和 Hibernate 都支持ORM映射，但是它们的映射方式不同。MyBatis通过XML文件或注解的方式进行映射，使用者需要手动编写SQL语句，以及与Java对象之间的映射规则。而Hibernate采用JPA标准或自身的映射文件，它可以通过对象关系映射描述对象图与数据表之间的映射，不需要编写SQL语句。

2. SQL控制：MyBatis 中的SQL是手动编写的，可以使开发者直接掌控SQL可读性和性能，而Hibernate会自动生成SQL，这样可以简化开发过程，但是对于复杂查询可能会引起性能问题。

3. 性能优化：由于MyBatis是手写 SQL 操作数据库，因此开发者可以精细地调试和优化 SQL 查询语句，从而提高查询速度和性能。而Hibernate则由于自身的ORM机制，可能会出现懒加载或重复查询的问题。

4. 控制粒度：MyBatis 可以精细地控制每个SQL语句的执行过程，可以自定义数据库连接、提交事务等。而Hibernate则对这些过程有约定，需要按照约定来执行。

5. 学习成本： MyBatis的学习成本更低，因为它的使用和书写类似于SQL；而Hibernate的学习成本更高，因为它需要学习JPA规范以及Hibernate自身的使用规则和映射方式。

综上所述，MyBatis和Hibernate都是优秀的ORM框架，它们根据不同的需求、项目规模和能力要求，选择适合自己的ORM框架。

6、事务的四个特性、四个隔离级别、七个传播途径

事务是并发控制的基本单位，为了确保数据的完整性和一致性，数据库需要支持事务机制。事务具有四个特性，包括：

1. 原子性（Atomicity）：事务中的所有操作要么全部执行成功，要么全部回滚。

2. 一致性（Consistency）：事务执行前后，数据库的状态应该保持一致，不会因为事务执行的失败而进入不一致的状态。

3. 隔离性（Isolation）：多个事务之间应该互相隔离，不会相互干扰，执行顺序不应该影响到事务执行的结果。

4. 持久性（Durability）：事务提交后，对数据库的更新应该得到永久保存，不会因为系统故障等原因而丢失。

在数据库中，事务还有四个隔离级别，包括：

1. 读未提交（Read Uncommitted）：事务中的修改操作立即被其他事务可见，可以导致脏读、不可重复读、幻读等问题。

2. 读已提交（Read Committed）：事务中的修改操作提交后才会对其他事务可见，可以避免脏读，但可能仍受到不可重复读、幻读等影响。

3. 可重复读（Repeatable Read）：保证在同一事务内多次读取同一数据时，得到的结果是一致的，可以避免脏读、不可重复读，但可能仍受到幻读的影响。

4. 序列化（Serializable）：所有事务按照顺序依次执行，避免脏读、不可重复读和幻读。

此外，事务还有七个传播属性，包括：

1. REQUIRED：当前方法必须在一个事务中执行，如果不存在则创建新事务。

2. SUPPORTS：当前方法支持在一个事务中执行，如果不存在则以非事务状态执行。

3. MANDATORY：当前方法必须在一个事务中执行，如果不存在则抛出异常。

4. REQUIRES_NEW：当前方法必须创建一个新的事务并在它的事务中执行，如果存在当前事务则将其挂起。

5. NOT_SUPPORTED：当前方法不应该在一个事务中执行，如果存在当前事务则将其挂起。

6. NEVER：当前方法不应该在一个事务中执行，如果存在事务则抛出异常。

7. NESTED：当前方法应该在一个嵌套事务中执行，如果存在当前事务则将其嵌套在当前事务中，与当前事务同步提交或回滚。

7、什么是脏读、幻读、读未提交

在数据库中，脏读、幻读、读未提交都是事务隔离级别中的问题，即多个事务同时访问同一数据时，可能会发生的数据错误问题。

1. 脏读（Dirty Read）：事务A读取了事务B未提交的数据，如果事务B回滚了本次操作，那么事务A读取的数据就是脏数据。脏读是最严重的一种数据不一致性问题。

2. 幻读（Phantom Read）：事务A执行第一次SELECT操作时，得到了若干条符合条件的数据，然后事务B对其中一条数据做出了修改或删除操作，事务A在再次执行SELECT时，结果发现出现了新的数据或者少了一条数据，这样的问题就是幻读。

3. 读未提交（Read Uncommitted）：一种最低的隔离级别，事务A读取到了其他事务B未提交的数据，可能造成的问题就包括脏读、不可重复读和幻读。

8、声明式事务和编程式事务的区别

在 Spring 框架中，可以通过声明式事务（Declarative Transaction）和编程式事务（Programmatic Transaction）来实现事务管理。

1. 声明式事务：通过在 Spring 配置文件或注解中声明事务属性，Spring 容器在运行过程中会自动根据这些事务属性创建和管理事务。使用声明式事务可以使业务代码与事务管理代码分离，使代码更加清晰简洁，提高代码的可维护性和可读性。

2. 编程式事务：利用 Spring 提供的 TransactionTemplate 类，在业务代码中通过编程的方式显式声明事务的开启、提交和回滚。在编程式事务中，开发人员需要在代码中显示地调用事务管理相关的 API。虽然能够直接控制事务的细节，但对于业务代码的可读性和可维护性影响较大，同时也容易出现遗漏或错误。

两者的区别在于，声明式事务是通过AOP实现的，在代码中明确指定切入点和切面，无需关注事务的具体实现。而编程式事务需要在代码中显式地声明，需要实现事务接口和事务处理类，并且需要深入地了解事务管理基础知识，这对于开发人员的技术要求相对较高。声明式事务更加简洁、灵活，将事务实现与业务逻辑解耦，适合于简单的事务场景；而编程式事务更加灵活、可控，对于复杂的事务场景更为适合。

9、Spring的常用接口有哪些

Spring 是一个非常强大和流行的开源 Java 框架，提供了各种模块和组件来简化 Java 开发，主要包括以下几个常用的接口：

1. BeanFactory：Spring 框架中应用对象的管理容器，提供对对象的实例化、配置和管理等功能。

2. ApplicationContext：是 BeanFactory 接口的子接口，除了提供 BeanFactory 的所有功能外，还提供了更多的企业级特性，比如国际化、事件传递、Bean 自动装配等。

3. AOP（Aspect-Oriented Programming）：面向切面编程，Spring 提供了多个接口和类来实现 AOP 的相关功能，如 Aspect、Advice、Join point、Pointcut 等。

4. JDBC（Java Database Connectivity）：Java 数据库连接，Spring 提供了 JdbcTemplate、NamedParameterJdbcTemplate、SimpleJdbcTemplate 等模板类简化 JDBC 的使用。

5. ORM（Object-Relational Mapping）：对象关系映射，Spring 提供了对多个 ORM 框架的整合支持，如 Hibernate、MyBatis、JPA 等。

6. Tx（Transaction Management）：事务管理，Spring 提供了多个接口和类来实现，支持声明式事务、编程式事务等多种方式。

7. Web（Web Support）：Web 应用开发支持，Spring 提供了多种 Web 模块，如 Web MVC、Web Flux、WebSocket、REST 等，以及与其他 Web 技术的整合，如 Struts、JSF、GWT 等。

除了以上常用接口，Spring 还有其他跨领域的模块，如 Security、Data、Messaging、Integration 等，提供了各种构建企业应用的组件和工具，非常适合于大型应用的开发和维护。

10、项目是如何处理异常的

项目处理异常的方式往往需要考虑具体业务场景和技术栈的情况。以下是处理异常的一般性思路：

1. 异常分类：根据实际业务需求和使用技术，对异常进行分类，分类的结果对不同异常采用不同的处理方式。例如，对于数据库异常，可以将其分类为连接异常、SQL异常和数据源异常等。

2. 日志记录：对于处理异常的过程中，尽量详细的记录异常信息，在日志中记录异常所在地、异常类型、异常信息、异常堆栈信息等有利于排除异常和分析问题。

3. 异常处理：对于已知异常，可以通过编写 try-catch 代码块的方式直接处理或抛出自定义异常返回给前端。要分类准确、全面、详细，每种异常通过不同的方式处理，以保证代码程序的健壮性。

4. 异常抛出：未能处理的异常，可以通过统一的异常处理器进行捕获并处理，异常处理器可以根据不同的异常类型，进行特定的后续处理并返回错误信息给前端，在开发过程中可以定义自己的公共异常处理器。

5. 信息反馈：对于异常，特别是代码错误等需要反馈给前端的错误，需要简明清晰的提示用户错误类型以及错误信息，反馈渠道除了前端还可以通过邮件等方式反馈给相关人员以及管理员，从而及时处理。

根据实际情况选择不同的异常处理方式，在代码的各个层面上设计良好的异常处理，使程序更加健壮、易于调试和维护。

11、你用过那些数据库连接池，不同的连接池有那些区别

Apache Commons DBCP：开源、成熟的连接池，支持连接和语句池化，可配置性高，可以控制最大连接数和最大活跃连接数，具有较好的性能和稳定性。不过该连接池在高并发下会有线程安全的问题。
C3P0：是一个稳定的免费数据库连接池，支持连接和语句池化，支持JMX、Hibernate以及JDBC驱动程序等，具有多种配置选项，可控制池大小和回收规则。与Tomcat/JBoss等服务器集成能力较好，不过性能稍逊于其他连接池。
HikariCP：是当前最快的 JDBC 连接池之一，速度快、功能全面，提供了线程池、连接池、可管理的底层连接驱动程序、自动连接超时和回收等强大的功能，并且支持异步查询API。但是，因为其在高并发情况下可能出现线程饥饿问题，因此在特定场景下需要小心如何配置。
Druid：是一个Java数据库连接池，具有实时监控和统计功能，支持连接和语句池化、可为不同的操作设置不同的连接数，能够最大程度降低连接的开销，集成了 JDBC、C3P0和 Commons-pool 特性。但是，相比较其他连接池而言，需要较大的内存和较高的CPU。

12、十个Linux常用命令，并进行说明

以下是十个常用的 Linux 命令，并进行简单的说明：

1. cd：切换当前目录。可以使用相对路径或绝对路径来指定目录。例如，`cd /usr/local/bin`会将当前目录切换到`/usr/local/bin`目录下。

2. ls：列出指定目录下的文件和子目录。可以通过各种选项按不同方式输出结果。例如，`ls -l`会列出文件和目录的详细信息（包括权限、所有者、大小、日期等等）。

3. pwd：显示当前工作目录的路径名。

4. cat：显示指定文件的内容。例如，`cat /etc/passwd`会显示`/etc/passwd`文件的内容。

5. grep：在文件或文本中查找包含指定关键词的行。例如，`grep "error" logfile.txt`会查找`logfile.txt`文件中包含字符串"error"的行。

6. mkdir：创建一个新目录。例如，`mkdir newdir`创建一个名为`newdir`的新目录。

7. rm：删除文件或目录。例如，`rm file.txt`会删除当前目录下的`file.txt`文件。如果删除的是一个目录，可以使用`rm -r`选项来递归删除整个目录。

8. mv：移动文件或目录，可以在不同的目录之间移动文件或者重命名文件。例如，`mv file.txt /tmp`将当前目录下的`file.txt`文件移动到`/tmp`目录下。

9. cp：复制文件或目录。例如，`cp file.txt /tmp`将当前目录下的`file.txt`文件复制到`/tmp`目录下。

10. ping：测试网络连接。例如，`ping google.com`会尝试从本地计算机向`google.com`发送数据包，并显示响应时间、传输丢失率等信息。

这些命令在 Linux 中非常常用，并且在命令行操作中非常重要，掌握它们可以让你更好的利用命令行进行工作。

13、Linux常见的几个版本，简述其区别

Linux 操作系统有非常多的版本和发行版，以下是几个常见的 Linux 版本及其区别：

1. Debian：Debian 是一个非常稳定和广泛使用的开源 Linux 操作系统，以稳定性和安全性为主要特点，广受企业和服务器领域的用户欢迎。Debian 特别适用于要求稳定可靠的服务器应用场景。

2. Ubuntu：Ubuntu 是一个基于 Debian 的开源操作系统，特点是易用性和流行性，因此非常适合桌面操作系统或小型服务器应用场景。Ubuntu 拥有广泛的软件库和易于安装配置的软件。

3. CentOS：CentOS 是源自 Red Hat Enterprise Linux 代码的开源 Linux 操作系统，特点是稳定、安全、易于维护和高度兼容性。CentOS 适用于企业级服务器应用，特别是 Web 服务器和数据库服务器等。

4. Fedora：Fedora 是基于 Red Hat 的开源 Linux 操作系统，以最新技术的支持、稳定性和可靠性并存而著称。Fedora 包含最新的软件和程序包，并且支持各种各样的桌面环境和工作流。

5. Arch Linux：Arch Linux 是一个极简主义的 Linux 操作系统，专注于最小化、简单化和可定制性，常用于高级用户和服务器应用，需要一定的 Linux 用户基础。

这些操作系统都有自己的特色和应用场景，在选择时需要考虑实际需求和技术水平，选择最适合自己的版本。

14、SpringBoot自动配置原理

Spring Boot 的自动配置是通过 Spring Framework 中的 `@Configuration` 和 `@EnableAutoConfiguration` 注解实现的。具体实现方式如下：

1. Spring Boot 在类路径下寻找包含 `META-INF/spring.factories` 的 Jar 包，这个文件包含了一系列 Spring Boot 自动配置的类路径。

2. 然后 Spring Boot 会根据这个类路径去扫描对应的 `@Configuration` 配置类。

3. Spring Boot 会根据已经配置好的触发条件来决定是否加载对应的自动配置类并自动配置到 Spring 容器中。

4. 最后，Spring Boot 将所有的自动配置类结合在一起，通过 `@Configuration` 注解暴露到 Spring 容器中，供应用使用。

自动配置的触发条件是通过 `@ConditionalOn...` 系列注解实现的，这些注解可以控制在什么条件下应用该自动配置类（例如：系统中包含某个类、配置了某个属性等），从而实现了按需加载自动配置的功能。

Spring Boot 自动配置的实现原理采用了模板方法模式，通过 `starter` 依赖和自定义的组件，可以快速和方便地实现一个基于 Spring Boot 的应用。自动配置的优势在于可以减少手动配置的工作量，简化了应用开发的流程，同时也增强了应用的可维护性和可扩展性。

15、@Coponent和@Configuration的区别

`@Component` 和 `@Configuration` 都是 Spring 框架中常用的注解，但是它们在作用上有所不同，主要表现在以下几个方面：

1. 用途不同：

- `@Component` 注解表明被注解的类是一个组件类，可以通过 Spring 的扫描机制自动发现并实例化，通过注入的方式可以在应用中使用。
- `@Configuration` 注解表明被注解的类是一个配置类，主要用来定义应用中的 Bean 和相关的配置属性，可以与 `@Bean`、`@Import`、`@Conditional`等注解一起使用。

2. 生效范围不同：

- `@Component` 注解主要是针对被注解的类本身，用来定义一个 Bean，一般情况下需要与其他注解如 `@Service`、`@Repository`等配合来表明这个 Bean 的作用。
- `@Configuration` 注解主要是针对被注解的类的成员方法，用来定义相应的 Bean 实例，需要配合 `@Bean` 注解使用来定义一个 Bean，因此配置类一般不需要使用其它的注解来补充说明这个 Bean 的作用。

3. Bean 注入方式不同：

- `@Component` 注解定义的 Bean 通过 `@Autowired`、`@Resource`等注解进行自动注入。
- `@Configuration` 注解定义的 Bean 需要显式调用其成员方法来获取实例，例如在方法中使用 `new` 运算符实例化 Bean 然后返回。

综上所述，`@Component` 注解主要用于定义普通的 Bean 组件，而 `@Configuration` 注解主要用于定义配置类和其成员方法所需的 Bean。在实际使用中，我们可以根据实际需要来选择使用不同的注解。

16、什么是正向代理、反向代理

正向代理和反向代理是代理服务器的两种不同应用方式。

正向代理通常是指代理客户端，对客户端进行代理访问外部网络，如在无法直接访问某些网站的情况下，可以通过配置浏览器的代理，将请求发送给正向代理服务器，由代理服务器代表客户端访问目标网站，并将结果返回给客户端。在这种情况下，目标网站无法知道请求的真实来源，而只能感受到来自正向代理服务器的请求。

反向代理通常是指代理服务器代理目标服务器，对外暴露的是代理服务器的地址和服务，客户端访问这个地址，实际上是由代理服务器代为访问后端的目标服务器。它可以提高服务器的安全性和灵活性，负载均衡等，比如可以根据客户端的 IP 地址或者请求头信息，将请求转发到不同的目标服务器上，实现负载均衡。

简单的说，正向代理隐藏了客户端的真实 IP 地址（如翻墙工具），而反向代理则隐藏了目标服务器的真实 IP 地址（如 Nginx 做负载均衡）。

代理服务器是一种中间服务器，用于转发请求和响应，起到保护应用服务器和隐藏客户端的作用，对于网络安全和加速加速访问有重要的意义。

17、项目中哪里用过Nginx，怎么用的

在项目中，通常可以通过 Nginx 来实现以下几方面的功能：

1. 反向代理服务器

在项目中使用 Nginx 做反向代理服务器，来承担负载均衡、缓存动态请求、隐藏真实服务器等功能，从而可以提高网站的性能和可用性。

2. 静态资源服务器

在项目中使用 Nginx 可以配置为静态资源服务器，用来托管一个或多个静态资源文件，如图片、CSS、JavaScript 等，以提高静态资源的访问速度和降低应用服务器的负载。

3. Web 应用服务器

在项目中使用 Nginx 可以配置为 Web 应用服务器，来托管 Web 应用或 Web 服务，从而能够提高 Web 应用的性能和可扩展性。

4. 安全加固

在项目中使用 Nginx 可以实现对网站安全方面的控制，如限制某些 IP 地址的访问、防止恶意访问、防范 DDos 攻击等。另外还可以使用 HTTPS 以及 SSL/TLS 协议来加密和保护通信数据，提升网站的可信度和安全性。

具体使用 Nginx 的方式需要参考具体场景和需求来定制配置，例如在每台 Nginx 服务器中配置反向代理、静态资源服务器、Web 应用服务器等，以提高服务可用性和性能。同时需要注意 Nginx 的安全配置和良好的运维习惯，避免出现安全漏洞和意外故障。

18、Nginx的集群配置

Nginx 集群配置一般可以通过反向代理和负载均衡实现。下面是一种简单的 Nginx 集群配置方法：

1. 安装 Nginx

首先需要安装 Nginx 软件包，并配置 Nginx 的基本设置，例如是否使用 SSL、Nginx 根路径、日志保存路径等。

2. 配置 Nginx 反向代理

在 Nginx 的配置文件中设置反向代理，配置反向代理主要是通过 `proxy_pass` 指令来实现，例如：

location / {
    proxy_pass http://backend_servers/;
}

其中 `backend_servers` 是后端服务器的名字或 IP 地址。另外需要根据具体需求设置其他的反向代理相关参数。

3. 配置 Nginx 负载均衡

Nginx 可以通过 `upstream` 指令来实现负载均衡策略。例：

upstream backend_servers {
    server 192.168.0.1;
    server 192.168.0.2;
    server 192.168.0.3;
}

其中，`backend_servers` 是后端服务器的名字，后面跟着一组逗号分隔的服务器地址和端口号。

4. 配置 Nginx 集群

在配置 Nginx 集群时，需要将多个 Nginx 服务器组合在一起，可以通过设置相同的负载均衡策略和反向代理服务来实现。例如：

```
upstream backend_servers {
    server 192.168.0.1;
    server 192.168.0.2;
}

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_pass http://backend_servers;
    }
}

server {
    listen 80;
    server_name www.example2.com;

    location / {
        proxy_pass http://backend_servers;
    }
}
```

运行这些 Nginx 实例，并进行相应的负载均衡配置即可实现 Nginx 集群的配置。

这是一个简单的 Nginx 集群配置示例，具体配置需要根据需求、网络情况和硬件资源等综合考虑。

19、上家公司用没有用过Redis，怎么用的

常见的 Redis 使用场景包括：

缓存数据

Redis 作为一个高速的内存数据库，可以用来缓存一些经常使用的数据，如页面数据、用户数据等。通过将这些数据存储在 Redis 中，可以加快访问速度，并减轻后端服务器的负担。另外，由于 Redis 支持过期时间，也可以很方便地实现缓存数据的过期机制，避免缓存数据的过期时间过长，影响数据的实时性。

分布式锁

Redis 的分布式锁应用非常广泛，主要是利用 Redis 原子性操作的特性，实现对共享资源的并发控制。例如，在分布式环境下，有时需要对某个共享资源进行互斥访问，则可以使用 Redis 的 SETNX 命令，设置某个键值的锁状态，来实现分布式锁。

计数器

Redis 的计数器也是其常见的应用之一，通过调用 Redis 的特殊命令，如 INCRBY 命令及计算文件或流的 MD5 值的特殊方法，实现计数器的相关功能。例如，在电商网站中，需要统计某个产品的浏览量、销量等，可以使用 Redis 的计数器来实现。

发布/订阅

Redis 的发布/订阅机制可以在多个客户端之间实现消息的传递和订阅。发送者可以向指定频道发送消息，订阅者则可以选择注册特定的频道，以接收相应的消息。例如，在一个电商网站中，实时推送商品促销信息、优惠券信息等，可以使用 Redis 的发布/订阅功能。

全局 ID 生成器

Redis 可以通过 INCR 命令来实现全局 ID 生成器，生成唯一且自增的 ID。对于需要保证唯一性且不重复的业务场景，如生成订单号、流水号等，可以使用 Redis 的自增 ID。

这些只是 Redis 常见的使用场景之一，而实际应用中，Redis 还具有很多其他的用法，如 GeoHash 空间索引、解决热点问题

20、Redis为什么设置成单线程

因为Redis是基于内存存储数据的，它在插入数据的时候不需要像关系型数据库那样进行磁盘IO操作。在使用到磁盘IO的情况下，因为IO会导致当前线程阻塞，单线程程序会因为IO而频繁阻塞，在这种情况下多线程模型效率会更高。但是Redis中并没有频繁的磁盘IO操作，引入多线程反而会因为线程调度切换（上下文切换）影响性能。此外单线程还能避免锁的问题。

此外Redis也不是完全没有多进程，在进行AOF日志文件重做或者进行RDB持久化时，因为这两个操作都涉及磁盘IO，会阻塞当前线程。所以Redis会调用系统的fork()函数创建一个新的子进程，以便在后台完成工作

21、实际开发过程中，用rdb还是aof

在实际开发过程中，选择使用 RDB 还是 AOF，取决于数据的可靠性和恢复数据的灵活性等多种因素。

RDB 以快照的形式存储 Redis 数据库中的数据，将 Redis 内存中的数据定期保存为一个 RDB 文件，可以用于备份和灾难恢复，并且 RDB 文件通常比 AOF 文件更小，占用更少的磁盘空间。因此，在需要备份和还原整个 Redis 数据库时，需要选择使用 RDB。

而 AOF 则是以类似日志的形式记录 Redis 的写操作，可以非常实时地记录 Redis 的更新操作，并可以选择 “appendonly on” 模式或 “everysec” 模式来保证数据不丢失。AOF 文件通常比 RDB 文件更大，但是由于可以按照 Redis 操作的时间顺序去重，因此也更容易恢复 Redis 数据库。因此，对于需要保证 Redis 数据不丢失、提供数据恢复功能的应用场景，应该选择使用 AOF。

因此，在选择使用 RDB 还是 AOF 时，需要考虑多方面的因素，如业务需求、数据量、数据安全等因素。如果需要保证 Redis 数据的安全性和可恢复性，建议同时使用 RDB 和 AOF，以提供最高级别的数据保护和恢复能力。

22、Redis基本数据类型，以及各类型之间的区别、应用场景

1、字符串(String)类型

字符串是最简单的数据类型，它可以包含任何数据类型的数据，包括数字、HTML代码、JSON等。在Redis中，字符串最大长度为512MB。字符串可以进行自增、自减等运算。应用场景：计数器、缓存、分布式锁等。

2、哈希(Hash)类型

哈希是键值对的集合，类似于Java中的Map。Redis的哈希可以将多个键值对存储到一个键值对中，更加节省空间。应用场景：存储对象、配置信息等。

3、列表(List)类型

列表是一个有序的字符串序列，可以在列表两端进行插入和删除操作。列表非常适合做队列和栈。应用场景：消息队列、最近浏览历史、粉丝列表等。

4、集合(Set)类型

集合是一个无序的字符串序列，集合中所有元素都是唯一的，可以进行并、交、差等集合运算。应用场景：已读/未读标记、点赞列表、社交网络中的好友列表等。

5、有序集合(ZSet)类型

有序集合是一个有序的字符串序列，每个元素都有对应的分值，分值可以是单调递增的浮点数。有序集合也是唯一的，但是可以根据分值对元素进行排序。应用场景：排行榜、带权重的队列等。

23、Redis有没有事务，如何应用

Redis 支持事务。在 Redis 中，事务是将多个命令打包在一起，作为一个单独的、不可中断的操作来执行。如果一组命令中的任何一个命令执行失败，那么整个事务都会回滚，使得事务的操作具有原子性。Redis 的事务主要有以下两个命令：

1. MULTI：将 Redis 的客户端设置为事务模式，接下来的所有命令均被缓存于队列中。
2. EXEC：提交所有缓存的命令，以原子的方式执行事务。

在 Redis 中执行事务操作需要以下步骤：

1. 调用 MULTI 命令，将 Redis 的客户端设置为事务模式。
2. 执行一系列 Redis 命令，这些命令会被存储在一个队列中等待执行。
3. 调用 EXEC 命令，将之前存储在队列里的一堆命令执行。如果在命令执行过程中出现错误，则整个事务都会回滚，并使得之前所有在事务队列中的命令都不会执行。

下面是一个使用 Redis 事务的示例：

MULTI
SET key1 value1
GET key1
SADD set1 member1
EXEC

以上示例中，MULTI 命令开启了一个事务，然后使用 SET 命令设置 key1 的值为 value1，使用 GET 命令获取 key1 的值，使用 SADD 命令将 member1 添加到 set1 集合中。最后，调用 EXEC 命令提交上述所有命令，确保这些命令作为一个原子事务被执行。

Redis 的事务操作应用场景非常广泛，例如提供事务订单，让订单中的多个逻辑同时执行，如果有任何一个逻辑执行出错，可以回滚整个事务，确保数据的一致性。此外，还可以使用 Redis 的事务操作进行锁机制，提高数据的并发访问性。

24、如何查询Redis中快过期的Key

可以使用 Redis 提供的 `SCAN` 命令结合 `TTL` 命令来查询 Redis 中快过期的 Key。`SCAN` 命令是一个基于游标的迭代器，可以遍历整个 Redis 的 Key 空间，该命令返回一个被扫描的 Key 以及一个新的游标，再利用 `TTL` 命令查询 Key 的剩余时间，从而得到快过期的 Key。具体步骤如下：

1. 确定要使用的数据库

首先，需要确认要查询的 Redis 数据库，可以使用 `SELECT` 命令进行切换。

```
SELECT <database number>
```

2. 使用 SCAN 命令扫描 Key 空间

使用 `SCAN` 命令扫描 Redis 数据库中的 Key 空间，同时获取 Key 的 TTL 值。

SCAN <cursor> [MATCH <pattern>] [COUNT <count>]

其中，`<cursor>` 表示游标起始位置，`<pattern>` 表示匹配的 Key 模式，`<count>` 表示每次扫描返回的 Key 的数量，可以根据实际需要进行调整。使用 `SCAN` 命令可以逐步扫描所有 Key，直到返回游标 `0` 为止。

3. 获取 Key 的 TTL 值

在扫描每个 Key 的过程中，使用 `TTL` 命令获取 Key 的 TTL 值。如果该 Key 的 TTL 值小于等于设定的阈值，那么这个 Key 就是快过期的 Key。

TTL <key>

4. 处理快过期的 Key

如果 Key 快过期，可以根据业务需要进行特殊处理或者删除。

综上所述，查询 Redis 中快过期的 Key 可以结合 `SCAN` 命令和 `TTL` 命令，可以使用编程语言或者 Redis 客户端进行操作。如果需要对 Redis 中快过期的 Key 进行自动化处理，可以采用定时任务或者 Redis 的发布订阅功能实现。

25、Redis雪崩、穿透、击穿如何预防

Redis 雪崩、穿透和击穿是 Redis 的常见问题，主要是因为 Redis 所有数据都存储在内存中，一旦大面积的缓存失败，可能会带来灾难性的后果。下面分别介绍雪崩、穿透和击穿以及相应的预防措施。

1. Redis 雪崩

Redis 雪崩是指缓存过期时间集中在同一个时间段内，导致大量的缓存同时失效，从而导致数据库请求都集中到某一时期。为了预防 Redis 雪崩，可以采取以下措施：

- 设置合理的缓存过期时间，适量分散缓存过期时间。

- 建立 Redis 高可用集群，减少整个集群的风险。

- 使用 Redis 哨兵（Sentinel）或者 Redis 集群等机制，进行数据备份和容错。

- 暂停一部分请求，释放资源，然后逐步释放剩余请求，避免缓存过期时间集中失效。

2. Redis 穿透

Redis 穿透是指尝试获取一个根本不存在的 Key，这会导致 Redis 尝试从数据库中获取数据，如果请求的请求数量大量增加，将引发数据库瘫痪。对于 Redis 穿透问题，可以采取如下措施：

- 使用缓存空对象（Null Object）或者布隆过滤器（Bloom Filter），可以过滤掉不存在的 Key 请求，从而降低数据库的访问压力。

- 在查询数据时，先判断 Key 是否合法，合法再进行查询。

3. Redis 击穿

Redis 击穿是指某个 Key 非常热门，由于缓存数据过期或者被删除，导致大量请求同时涌入数据库，造成宕机的问题。为了避免 Redis 击穿问题，可以采取如下措施：

- 对于热点数据，可以采用提前写入的方式进行缓存，比如将热点数据永久写入 Redis，或者使用定时刷新的方式保持数据新鲜。

- 可以使用互斥锁（Mutex Lock）进行并发调用的控制，当缓存失效的时候，可以使用分布式锁等机制，保证只有一个请求查询数据库，并将查询结果重新写入缓存。

- 对于多次查询结果相同的数据，可以采用结果缓存，避免频繁查询数据库。

综上所述，采取合适的措施可以有效预防 Redis 的雪崩、穿透和击穿问题，提高 Redis 的可用性和性能。

26、除了Redis还有那些缓存库？

除了 Redis 以外，常见的缓存库还有以下几种：

1. Memcached：用于分布式缓存，比 Redis 更加轻量级，适合高速访问和写入性能的场景。

2. Ehcache：Java 开发的一个基于内存的缓存库，支持缓存过期时间、缓存清理、事件驱动等功能。

3. Caffeine：用于本地缓存，基于 Java 8，支持对缓存进行压缩和移除操作，性能非常高。

4. Guava Cache：一个基于本地堆内存的缓存库，支持对象引用、过期时间和大小限制等策略。

5. Hazelcast：一个分布式缓存和计算平台，支持多种领域的内存数据存储，例如缓存、分布式数据网格、消息队列等。

6. Couchbase：基于 Memcached 和 CouchDB 开发的分布式缓存库，用于存储高负载量的数据。

27、redis 如何进行持久化

Redis可以通过两种方式进行持久化：RDB持久化和AOF持久化。

1. RDB持久化

RDB持久化是Redis默认的持久化方式，它是将Redis在内存中的数据快照(snapshot)写入磁盘，实现持久化的方式。快照可以手动触发，也可以在Redis配置文件中设置自动触发的频率。

RDB的主要优点是持久化后的文件较小，对性能的影响也较小，而且可以非常方便地进行备份和还原。但是，RDB持久化的缺点是数据的持久化周期比较长，最长可能达到几十分钟，如果此时Redis服务宕机，会导致在最后一次快照备份后的数据丢失。

2. AOF持久化

AOF持久化方式是将Redis的每次写操作以日志的形式记录到磁盘中，以保证数据的持久性。和RDB不同的是，AOF持久化可以较短的间隔时间进行一次备份，因此数据的安全性比RDB更高。同时，在出现灾难恢复时，AOF持久化也比RDB更快恢复数据。

AOF持久化的缺点是写入操作比较频繁，可能会对性能产生一定影响，而且AOF文件较大，恢复时也会比较消耗时间。

Vue

1、MVVM模型

MVVM模型是一种软件架构模式，常被用于前端开发中。它的全称是Model-View-ViewModel，分别代表了数据模型、视图和视图模型三个部分。

先来解释这三个概念：

- Model：数据模型，用于表示数据以及数据操作。
- View：视图，用于展示数据给用户。
- ViewModel：视图模型，协调与View的交互，并且将Model数据处理成View进行展示所需要的形式。

MVVM的思想是将数据、逻辑和界面分离。整个系统的工作流程如下：

- 用户交互操作View。
- View会通过绑定的ViewModel将操作信息反馈给ViewModel。
- ViewModel再使用其内部的Model，进行数据操作，并将操作后的数据反馈给View。
- View根据数据展示给用户。
- 如果需要修改数据，则重复从第二步开始。

通过这种方式，可以清晰的将数据处理逻辑从View中分离出来，降低耦合度，简化代码逻辑。同时也提高了代码的可维护性和可重用性，有助于加速开发和调试。

2、Vue2和Vue3有什么区别

Vue3和Vue2相比有以下主要区别：

1. 性能提升
Vue3在性能方面进行了大量优化，例如引入了更高效的虚拟DOM算法，提高了响应系统的性能，改进了编译器，减少了包的大小等。这些优化使得 Vue3 较 Vue2 更快。

2. Composition API
Vue3 引入了 Composition API，提供了一种新的代码组织方式，使得组件内部逻辑更加清晰、可复用性更高，与 Typescript 结合更友好，这是 Vue2 所没有的。

3. Setup函数
Vue3 中的新增了 Setup 函数，取代了 Options API 中的created、mounted等。在 Setup 函数中，可以定义子组件的属性（props）、生命周期钩子（lifecycle hooks），也可以引用数据、计算属性（computed）和方法，效果类似于 Vue2 中的 Mixins，但是更加强大，代码更加清晰。

4. Teleport
Vue3 中引入了 Teleport，可以方便地将一个组件移动到DOM树中的另一个节点上，实现更加灵活的组件布局。

5. 支持Typescript
Vue3 对 Typescript 的支持更加完善，例如更好的TypeScript类型推断机制，更为严格的TypeScript规范和更智能的TypeScript错误提示等。

总的来说，Vue3 相比 Vue2，在性能、逻辑组织和使用方面更加优秀，但是也需要花费一定的学习成本来适应新特性。

3、Vue的生命周期

在Vue应用中，每个组件实例在被创建、挂载到DOM、更新和销毁时都会触发一系列的生命周期函数。以下是Vue的生命周期函数：

1. beforeCreate：在实例初始化之后，数据观测（data observer）和初始化事件之前被调用。

2. created：在实例创建完成后被立即调用，这里的生命周期，已经完成了数据观测和属性，方法的运算，但是$el属性还没有被填充到html中去。

3. beforeMount：在挂载之前被调用，即将createElement函数编译成dom节点，将其渲染成html，填充到$el属性中去。

4. mounted：在实例挂载之后调用。这时，$el属性已经被对应的dom节点取代。

5. beforeUpdate：在数据更新之前被调用，发生在虚拟DOM重新渲染和打补丁之前。

6. updated：在由于数据更改导致的虚拟DOM重新渲染和打补丁之后调用。

7. beforeUnmount：在实例销毁之前调用，这里可以进行一些善后工作，如清理计时器和取消事件监听器等。

8. unmounted：在实例销毁后调用，这里所有的东西都已经解除绑定，可以做一些清理工作。

简单来说，Vue的生命周期就是按照创建、挂载、更新和销毁的顺序进行的，每个阶段都会调用相应的生命周期函数。这些生命周期函数可以用来控制应用的各个阶段的行为或作为钩子去定义各种插件和扩展。

Archie丶z

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
经典面试题

死信交换机（Dead Letter Exchanges，DLX）是一种用于处理无法被消费的消息的机制。当消息在消息队列中满足一定条件时，会被转发到死信交换机。这些条件包括消息被拒绝、消息过期或者消息的队列达到了最大长度。处理死信交换机中的消息，可以采取以下两种方式：重新投递：将死信消息重新投递到原有的队列或者交换机中，这样可以避免消息的丢失，同时可以让消费者重新处理该消息。移除消息：将死信消息从队列中删除，避免对消息的无限次重试。
复制链接

扫一扫