今天跟大家讲讲数据库子数据库子表后如何解决事务问题。很多人可能不太了解。为了让大家更好的了解，边肖为大家总结了以下内容，希望大家能从这篇文章中有所收获。
一、概述
随着时间和业务的发展，数据库中表的数据量会越来越大，相应的，数据操作、增加、删除、修改的成本也会越来越大。因此，一些大型表被分割成多个数据库中的多个表。
本文基于非事务消息的异步保证来完成子数据库和子表中的事务问题。
二、需要解决问题
2.1 原有事务
由于新表位于子数据库和子数据库之后的另一个数据库中，如何保证主数据库和子数据库的事务性是必须解决的问题。
解决方案：通过在主库中创建日志表，将操作数据库的逻辑映射到日志记录。当整个大事务完成后(管道插入到管道表中)，通过其他方式执行管道，保证最终的一致性。
2.2 流水
所谓流水，可以理解为交易信息。
通过在数据库中创建管道表，管道记录被用来表示业务处理逻辑。因此，最终必须正确执行管道。因此，从管道中提取业务代码时，必须考虑：
延迟流水线。流水线不是实时处理的，而是使用流水线执行器异步执行的。因此，在原有逻辑中，需要特别注意后续流程是否对流水线有实时依赖(比如后续业务逻辑中会用流水线结果做一些计算等)。).
处理流水的紊乱。即使先执行后生成的管道，也不会有问题。
流水的最终成功。对于每个插入的流水，必须保证流水成功执行。
因此，在抽取自来水时，
水处理越简单越好。
对流失的依赖越少越好。
提取的管道在这个业务逻辑中没有实时依赖性。
2.3流水处理完成
由于流表放在原数据库中，流处理完成后，操作子数据库。如果完成子数据库操作来更新旧表的流消息，那么这是一个夸库事务。如何保证流状态和子数据库的更新也在一个事务中？
解决方法是在子库中创建一个流量表，并将其插入到子库中的流量表中，而不是在损失处理完成后更新旧表的状态。
这样做的优点：
一般来说，管道会被唯一索引，所以如果管道被多次重复执行，整个事务会因为唯一索引检测在插入分支管道表时失败而回滚(当然，幂等判断应该在处理管道之前进行)。
这样，可以通过判断主库的管道是否在子库中来判断管道是否已经完成。
三、流水处理器基本框架
流水线处理器实际上不包含任何业务相关的处理逻辑，其核心功能是：
告知服务接入方何时处理何种自来水。
检查管道执行是否成功。
注意：管道执行器不知道管道代表什么逻辑，但是需要业务系统识别，然后执行相应的业务逻辑。
3.1 流水执行任务
流水线处理调度任务是扫描要处理的流水线，然后通知业务系统执行哪个流水线。
示意图如下：
3.2 流水校验任务
管道验证的任务是比较主库和子库中的管道记录，对失败的管道通知业务系统进行重新处理，如果重复重试失败，则发出警报。
示意流程图：
四、为什么不用事务消息
因为是现有项目(互联网金融，绝对不能容忍任何消息丢失或消息处理失败)，所以不使用交易消息是有原因的。
需要引入额外的消息队列来增加系统的复杂性，并且在消息队列通信失败时也需要额外的逻辑保证和处理。
事实上，1不是主要原因，而是因为事务消息需要手动提交和回滚(使用数据库时不需要)。那么问题来了。spring中的事务是可传递的，何时提交我们的事务消息是一个大问题。例如，A.A .()原本是一个事务，但是另一个事务B.B .()调用A.A .()，事务消息提交放在a中。
看完以上内容，你对数据库子数据库子表后如何解决事务问题有了更好的理解吗？如果您想了解更多知识或相关内容，请关注行业资讯频道，感谢您的支持。
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/129603.html