记录@Transactional注解和多数据源相遇引发的一些问题

项目背景是将excel多条数据导入，生成本地log然后对其他项目做业务逻辑。目前用的是druid连接池来做这件事。下面简单讲述一下技术背景和遇到的问题：

@Transactional详解

@Transactional是Spring Framework提供的用于管理事务的注解。使用@Transactional注解，可以将一个方法设定为一个事务处理方法。

该注解可以加在方法上或者类上，加在方法上表示该方法执行期间开启事务，加在类上表示类中的所有方法都是事务性的。

作用：

1. 开启事务

将@Transactional注解加在方法上，程序会在方法执行前开启一个事务，执行后根据方法的执行情况决定事务的提交或回滚。

2. 处理事务

使用@Transactional注解后，Spring框架会自动为带有该注解的方法开启一个事务。一旦方法抛出异常，那么事务会自动回滚，撤销原有操作。如果没有异常，事务会自动提交，保存原有操作。

3. 简化代码

使用注解@Transactional可以省去手动开启和提交事务的过程，简化了代码的编写，提高了程序的可读性和可维护性。

Druid连接池

连接池：
连接池是指使用一些预先创建好的连接，在数据库操作结束后并不断开连接，而是将这些连接放入一个池中，等待下次操作时重复使用，从而减少连接建立和断开产生的性能耗费。Druid连接池通过复用连接和连接管理机制，提高了应用程序的性能和可靠性。
druid连接池:
为Java应用程序提供的高性能、高可靠、功能丰富的连接池。它是阿里巴巴公司开发的一款开源产品，由阿里巴巴Java技术团队维护和支持。
作用主要体现在以下几个方面：

1.节约资源开销：数据库连接是非常稀缺宝贵的资源，使用连接池可以避免频繁创建和销毁连接，从而避免资源浪费。

2.提升数据库访问性能：连接池会对连接进行管理，避免了频繁的连接建立和关闭操作，通过复用连接，可以有效地提升数据库访问性能。

3.提高应用程序的可用性和可靠性：通过连接池管理连接，可以避免资源过度消耗和连接泄露等问题，提高应用程序的可用性和可靠性。

4.提高连接可监控性：Druid连接池内置了多种监控指标，可以对连接的情况进行实时监控和分析，帮助开发人员快速定位和解决连接问题。

问题描述与调查

在完成逻辑编写后，测试时遇到了如下问题：

### Error updating database.  Cause: java.sql.SQLIntegrityConstraintViolationException: Duplicate entry '1234' for key 'mobile'
### The error may exist in file [D:\shop\target\classes\mybatis\mapper\UserMapper.xml]
### The error may involve com.hu.shop.mapper.UserMapper.save-Inline
### The error occurred while setting parameters
### SQL: insert into user(loginName,userName,password,gender,identityCode,email,mobile) values(?,?,?,?,?,?,?)
### Cause: java.sql.SQLIntegrityConstraintViolationException: Duplicate entry '1234' for key 'mobile'

从报错可以看出来，是mobile这个字段的值重复了，也就是说当前插入的数据，跟数据库中某个字段的数据冲突了。但是数据库并不存在这条数据，还有一种情况是提示某张表中不存在xxx字段，实际上该字段也是存在的。所以上述种种问题显而易见，数据异常了。
后来经过多次测试发现去掉@Transactional注解可以避免出现这种问题，数据之间并没有出现格式错误或异常。
那么为什么会出现这种情况？
调查发现是因为master库的逻辑在处理完成后，事物并没有提交然后切换为多个slave库
进行后续处理而导致出现数据异常。
出现问题的主要原因有以下两种，刚才的情况为第一种：
1. 数据源的连接池问题：频繁的切换数据源，就会导致连接池中的连接不同步，从而可能出现某些连接被重复利用或者没有被及时释放的情况，最终导致数据库出现连接池溢出、性能下降、甚至崩溃等问题。
2. 数据源的事务问题：在多数据源环境下，如果频繁的切换数据源，就会导致事务上下文的混乱。比如，如果一个事务需要访问多个数据源，如果在两个不同的数据源中分别开启事务，那么可能出现一个数据源的事务提交成功，而另外一个数据源的事务提交失败的情况，这样就会导致数据的不一致性。

解决方式

最后采用手动方式添加异常处理流程来达到正确处理。
遇到相同情况的小伙伴如何业务复杂也可以考虑以下几种办法：
1. 多级缓存：多级缓存可以缓存数据源连接，减少数据源的切换次数。比如，使用本地缓存、中心缓存或者分布式缓存等技术，将连接池缓存到内存中、缓存服务器上或者集群中，然后在需要时直接从缓存中获取即可。

2. 数据连接池连接共享机制：对于多数据源的情况，可以采用连接共享机制，即多个数据源共享一个连接池，从而避免了频繁切换带来的连接池管理问题。通过合理的管理连接池，较好地利用连接，不但不会过多地消耗内存空间，而且可以避免重复打开连接的影响，增加了系统的并发能力。

3. 事务消息机制：使用分布式事务管理系统来解决多数据源中的事务问题，以达到数据一致性的目的。也可以使用消息代理和相关的事务管理工具，将不同数据源的操作封装成一个消息事件，确保所有事件处理成功或失败。

4. 分布式数据库：分布式数据库可以实现数据的分布式存储和处理，从而避免数据源频繁切换。可以使用分布式数据库，根据需求将数据分散在不同的节点中，不仅可以降低单个数据库的压力，提高了数据库的扩展性、可用性，还可以减少数据源的切换次数，使得多数据源之间的数据交互变得更加简单。
反正尽可能减少数据源的切换次数，或者使用一些同步机制共享的连接池，或者使用分布式事务等，解决办法还是很多的，目的都是保证数据的一致性和稳定性。具体根据实际情况来做选择即可。

以上就是今天记录的一些小日常，欢迎大家多多分享和交流。