问题记录-Java后端

news2024/11/28 12:28:50

问题记录

1.多数据源使用事务注意事项？

问题：在springBoot项目中多表处理数据时使用@Transaction注解处理事务会导致连不上指定的库，访问失败。
原因：配置动态多数据源导致事务处理不知道走哪一个TransactionManager
解决方案：
1.在配置多数据源文件中，统一在事务管理器上也指定。

2.找到使用事务的地方，在Transactional注解内加入 transactionManager = “xxxTransactionManager” ,指向对应的事务就可以了。

2.mybatis执行MySQL的存储过程？

问题：在执行存储过程使用stateMentType = ”STATEMENT“ 参数时报错
原因：
STATEMENT是非预编译的直接执行sql,不能使用#{},使用${}。
PREPARED:预处理,参数,进行预编译,获取数据：#—–PreparedStatement:默认
CALLABLE:执行存储过程———CallableStatement
解决方案：更改statementType类型，或者改变动态入参方式。如果没有参数形式用哪种类型都可以。

3.springBoot加载不到nacos配置中心的配置问题

问题：首先报错信息打印是can not find primary datasource，
cloud版本：2021.0.5.0 对应 nacos：2.2.0以上版本太低会出现兼容问题。
原因：一开始分析找不到主数据源是因为没有设置primary:master，设置后还是出现问题。再分析可能没加载到配置文件，接下来通过nacos加载一步步分析。
- 首先在NacosPropertySourceBuilder下的loadNacosData方法中打上断点发现this.configService.getConfig返回的data为空, 侧面证明了确实没有读取到nacos中的配置信息
- 然后再进去getConfig一步步看哪个地方获取失败，进入NacosConfigService的getConfigInner方法里面，就是具体的拉取配置的实现,nacos首先是通过LocalConfigInfoProcessor.getFailover的方法获取本地的配置, 当本地配置返回空时才会去获取nacos客户端的配置,而this.worker.getServerConfig这个方法,就是进行获取远端的配置信息, 通过断点发现response的返回也是空的,那么我继续下进入getServerConfig中
- 进入到queryConfig方法时发现了问题,通过ConfigQueryRequest.build方法生成的ConfigQueryRequest请求, 在返回时竟然返回ErrorCode:300, message 为 config data not exist, 这就是表示我传递三个参数, dataId, group, tenant 出现了问题
- 再回去nacos中反复检查发现命名空间有多个，bootstarp配置文件并没有指定所以加入namespace标签解决问题。

4.服务器产生大量close_wait情况

问题：运营人员突然找我说系统进不去了，我看项目正常并没有错误日志打印，没有其它日志打印，只有xxl-job还在执行有日志打印。第一反应项目不正常出现假死情况。
原因：
①利用jstack查看线程，再用top查看系统负载和cpu占用情况一切都正常。
②排除了业务代码的问题，需要跳出业务代码去查问题，既然没有请求，那就先从网络开始查起，使用netstat -aonp命令查看发现大量close_wait产生，查阅相关资料，因为linux中一切皆为文件，一直产生导致tcp队列溢出。查看tcp队列是否溢出命令：netstat -s | egrep “listen|LISTEN”
③查看tcp队列当前情况：ss -lnt 会出现两个值Recv-Q和Send-Q
Recv-Q代表当前全连接队列的大小，也就是三次握手完成，目前在全连接队列中等待被应用程序accept的socket个数。
Send-Q代表全连接队列的最大值，应用程序可以在创建ServerSocket的时候指定，tomcat有默认大小，这时Recv-Q会远远大于Send-Q。
解决方案：
设置超时时间
```
server:
	port: 8988
	tomcat:
		uri-encoding: UTF-8
		connection-timeout: 20000   # 默认值20s 设置http超时时间(即keep-alive超时时间),没有任何活动则tomcat关闭连接
		protocol-header: HTTP/1.1
	servlet:
		session:
  		timeout: 120s   # 会话超时时间，默认为30min  与客户端http断开
```
另一种情况：近期项目在做信创改造时切换数据源，连接MySQL失败，导致项目产生大量close_wait。原因是同事开发时没有考虑连接报错时数据库怎么关闭连接导致产生大量close_wait，这种代码层面考虑不全不做过多概述，用try-catch-finally包住并在finally下关闭连接。