一只田田

2023-12-14 22:55 Java

关注

赛意信息-Java

赛意信息-Java

volatile关键字的作用

synchronized 和 Lock 有什么区别？

mycat怎么分片的

微服务异常如何考虑的

统一的异常处理：在微服务系统中，建议实现统一的异常处理机制。这可以通过定义自定义异常类、全局异常处理器或者集中的错误码管理等方式来实现。统一的异常处理可以提高代码的一致性，减少重复代码，并简化系统的维护和扩展。

良好的错误信息：异常信息应该包含足够的信息，以便于排查问题。错误信息可以包括异常类型、异常发生的服务、错误码、错误描述、时间戳等信息。这有助于开发人员快速定位问题，也有利于运维人员进行故障排查。

分布式追踪：在微服务架构中，异常处理不仅仅是在单个服务内部，还涉及到服务之间的协作。使用分布式追踪工具（如sleuth、zipkin等）可以帮助你跟踪和分析异常，了解整个系统的运行状况。

熔断和降级：为了提高系统的稳定性，可以在微服务中实现熔断和降级机制。熔断机制可以在某个服务出现异常或者超时时暂时关闭对该服务的调用，防止异常扩散。降级机制则是在服务不可用时，提供一些简化的备用方案，保证系统的基本功能仍然可用。

异步处理：对于一些不影响主流程的任务，可以考虑使用异步处理来隔离异常。例如，将消息推送到消息队列，由后台任务异步处理，避免异常直接影响到用户请求的响应时间。

异常回滚和事务管理：在微服务中，多个服务之间的操作可能涉及分布式事务。在异常发生时，要考虑异常回滚和事务的一致性，保证数据的完整性。

熔断原理，spring cloud 断路器原理？

31. 什么是断路器

当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应，当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）

断路器有三种状态

打开状态：一段时间内达到一定的次数无法调用并且多次监测没有恢复的迹象，断路器完全打开，那么下次请求就不会请求到该服务

半开状态：短时间内有恢复迹象，断路器会将部分请求发给该服务。正常调用时，断路器关闭

关闭状态：当服务一直处于正常状态，能正常调用

32. 什么是 Hystrix？

在分布式系统，我们一定会依赖各种服务，那么这些个体服务一定会出现失败的情况，就会导致雪崩，Hystrix就是这样的一个工具，防雪崩利器，它具有服务降级，服务熔断，服务隔离，监控

一些防止雪崩的技术。Hystrix有四种防雪崩方式:

1. 服务降级：接口调用失败就调用本地的方法返回一个空

2. 服务熔断：接口调用失败就会进入调用接口提前定义好的一个熔断的方法，返回错误信息

3. 服务隔离：隔离服务，服务相互不影响

4. 服务监控：在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。

aqs

AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的ReentrantLock。简单来说，AQS定义了一套框架，来实现同步类。

36. 谈谈服务降级、熔断、服务隔离

服务降级：当客户端请求服务器端的时候，防止客户端一直等待，不会处理业务逻辑代码，直接返回一个友好的提示给客户端。

服务熔断：在服务降级的基础上更直接的一种保护方式，当在一个统计时间范围内的请求失败数量达到设定值或当前的请求错误率达到设定的错误率阈值时开启断路，之后的请求直接走fallback方法，在设定时间后尝试恢复。

服务隔离：Hystrix为隔离的服务开启一个独立的线程池，这样在高并发的情况下不会影响其他服务。服务隔离有线程池和信号量两种实现方式，一般使用线程池方式。

37. 服务降级底层是如何实现的？

Hystrix实现服务降级的功能是通过重写HystrixCommand中的getFallback()方法，当Hystrix的run方法或construct执行发生错误时转而执行getFallback()方法。

哪个中间件用得多？RabbitMQ 的使用场景有哪些？

RabbitMQ 怎么保证不被重复消费？

幂等性处理原理

在RabbitMQ的消费端，我们可以通过Redis实现幂等性处理的原理如下：

1. 消息消费前，先判断Redis中是否存在该消息的消费记录。

2. 如果Redis中存在该消息的消费记录，则说明该消息正在被消费，可以跳过当前消息的消费，避免重复执行。

3. 如果Redis中不存在该消息的消费记录，则进行消费并将该消息的消费记录写入Redis。

4. 消息消费完成后，可以释放Redis中该消息的消费记录。

RabbitMQ怎么保证消息不丢失

微服务设计原则

数据库性能优化

1. 索引优化：（列索引）通过在表的列上创建索引，可以大大减少数据查询时的扫描量，从而提高查询性能。需要注意的是，不是所有的列都适合创建索引，索引的创建也需要考虑到查询频率、数据更新频率等因素。

2. SQL语句优化：优化SQL语句可以从多个方面入手，如减少查询字段、减少子查询、合理使用连接语句等。

3. 数据库服务器参数优化：调整数据库服务器的参数可以对SQL语句的性能产生影响。比如，调整数据库服务器的缓存大小、最大连接数、并发连接数等，都可以对SQL语句的性能产生影响。

4. 数据库结构优化：数据库结构的优化也可以对SQL语句的性能产生影响。比如，优化表的结构、调整表之间的关系等

Spring事务

Spring支持两种类型的事务管理：

编程式事务管理：通过编程的方式管理事务，极大的灵活性，但是难以维护。

声明式事务管理：可以将业务代码和事务管理分离，你只需用注解和XML配置来管理事务。

5.11 说一下Spring的事务传播行为

spring事务的传播行为说的是，当多个事务同时存在的时候，spring如何处理这些事务的行为。

① PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。

② PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。

③ PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。

④ PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。

⑤ PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

⑥ PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

⑦ PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则按REQUIRED属性执行。

5.14 你更倾向用那种事务管理类型？

大多数Spring框架的用户选择声明式事务管理，因为它对应用代码的影响最小，因此更符合一个无侵入的轻量级容器的思想。声明式事务管理要优于编程式事务管理，虽然比编程式事务管理（这种方式允许你通过代码控制事务）少了一点灵活性。唯一不足地方是，最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。

索引是怎么理解的？使用索引要注意什么？

事务的隔离级别

5.12 说一下 spring 的事务隔离？

spring 有五大隔离级别，默认值为 ISOLATION_DEFAULT（使用数据库的设置），其他四个隔离级别和数据库的隔离级别一致：

1. ISOLATION_DEFAULT：用底层数据库的设置隔离级别，数据库设置的是什么我就用什么；

2. ISOLATION_READ_UNCOMMITTED：读未提交，最低隔离级别、事务未提交前，就可被其他事务读取（会出现脏读、幻读、不可重复读）；

3. ISOLATION_READ_COMMITTED：读已提交，一个事务提交后才能被其他事务读取到（会造成幻读、不可重复读），SQL server 的默认级别；

4. ISOLATION_REPEATABLE_READ：可重复读，保证多次读取同一个数据时，其值都和事务开始时候的内容是一致，禁止读取到别的事务未提交的数据（会造成幻读），MySQL 的默认级别；

5. ISOLATION_SERIALIZABLE：序列化，代价最高最可靠的隔离级别，该隔离级别能防止脏读、幻读、不可重复读。

脏读：表示一个事务能够读取另一个事务中还未提交的数据。比如，某个事务尝试插入记录 A，此时该事务还未提交，然后另一个事务尝试读取到了记录 A。

幻读：指同一个事务内多次查询返回的结果集不一样。

不可重复读：是指在一个事务内，多次读同一个数据，结果不一样。

Spring事务使用场景

关系型数据库事务： Spring 的事务管理广泛用于关系型数据库操作。当需要在数据库上执行一系列的操作，并希望这些操作要么全部成功，要么全部失败时，可以使用 Spring 事务来确保一致性。

编程式事务管理：在某些情况下，需要通过编程方式管理事务。Spring 提供了 TransactionTemplate 和 PlatformTransactionManager 等工具，允许以编程方式控制事务的开始、提交和回滚。

声明式事务管理： Spring 支持通过注解或 XML 配置声明式事务。通过在方法上添加 @Transactional 注解，可以将方法标记为一个事务边界。

嵌套事务： Spring 支持嵌套事务，允许在一个事务内嵌套其他事务。当一个事务方法调用另一个带有 @Transactional 注解的方法时，它们可以在同一事务中运行，或者新启动一个子事务。

事务传播行为： Spring 允许通过 @Transactional 注解的 propagation 属性设置事务的传播行为，如 REQUIRED、REQUIRES_NEW、NESTED 等，以定义事务方法的调用方式。

事务回滚：当方法抛出运行时异常或指定的检查异常时，Spring 事务会自动回滚。也可以在方法中手动触发回滚，通过调用 setRollbackOnly() 或抛出 RuntimeException。

多数据源事务：在多数据源的环境中，可能需要确保多个数据源上的操作要么都成功，要么都失败。Spring 事务管理可以用于协调多个数据源上的事务操作。

你用过Springcloud哪些组件？

消息队列、redis中间件

流量削峰：

流量峰值时刻是一个非常恶性的问题，当一大批的用户同时访问应用程序时，可能会导致服务器崩溃和应用程序的严重延迟。这是因为在流量高峰期间，服务器无法同时服务于大量的请求，导致应用程序无法及时响应并提供服务。

1. 为了解决这个问题，我们可以借助Redis实现流量削峰，从而更加高效地处理并发请求访问。流量削峰的基本思路是将高峰期的请求存储在一个缓存队列中，然后逐步将请求从队列中取出并处理。通过这种方式，我们可以重点关注应用程序的承载能力，避免服务器的压力过大。基于Redis的流量削峰的实现相对简单，我们可以使用Redis的列表（List）结构来作为存储请求的队列。具体来说，我们可以使用一个Redis列表模拟队列，将所有的请求添加到队列的末尾。而当请求被一个工作线程取出并处理后，它会从队列的头部取出。

2. 通过MQ的方式，将订单存储到MQ队列中，消费端通过拉取的方式，并且拉取速度由消费端来控制，则就可以控制流量趋于平稳。这样对于结算系统来讲，就达到了削峰填谷的目的。或者说起到控流的目的

雪崩出现的原因

1. Redis 挂掉了，请求全部走数据库。

2. 对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。

缓存雪崩如果发生了，很可能就把我们的数据库搞垮，导致整个服务瘫痪！

解决方案

缓存挂了的情况

1. 事发前：实现 Redis 的高可用(主从架构+Sentinel 或者 Redis Cluster)，尽量避免 Redis 挂掉这种情况发生。

2. 事发中：万一 Redis 真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)

3. 事发后：redis 持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。

过期时间情况

在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。