关于方法事务性的记录

    写在开篇，接下去说的和“实际的使用方式”以及“具体解决方案”均无关系，只是自己的吐槽

    在日常工作中，“方法事务”是逃不掉的一个坎，也是比较难处理的一个问题，因为它会随着你编码水平的提高而变的更加复杂。

    1.简单事务

    不知道大家还记不记得在职业生涯的开端，当第一次听到“事务”这个词的时候是怎么样的一番心情？我当时是觉得这个东西好像蛮厉害的，竟然能够这么做。然后就是接触到Spring的事务管理，觉得特别方便，自己都不用考虑什么，它就帮我都做好了。那个时候的印象就是:事务就是保持整个方法（请求）内的数据库数据一致性。当时也就觉得整个事情也就这样了，自己肯定是不世之材，才这么一会儿工夫就搞懂了，前途可期

    2.分布式事务

    初出茅庐之后的一阶段，自信心持续膨胀，直到遇到第一次的分布式开发。从业时间比较早，已经是5年前了，前几个接手的项目是单纯的web项目，也没有涉及到分布式开发的模式（其实当时已经蛮普及了），第一次接触到这样的开发模式，总的来说当时还是觉得蛮新奇的，模块间的协作是当时理解的难题，并没有弄懂他们是如何交互的。现在的话是普遍dubbo了，那个时候http方式，webservice方式，自定义socket协议都有存在。当时很多东西理解起来比较吃力，遇到的最大的问题就是分布式事务问题，模块间相互调用，方法间相互嵌套，把一个模块看成一个package，不同模块只是同一个项目的不同package，这样当一个调用环节“出错”需要回滚时，其他环节按理也是需要回滚的，但这个时候的回滚操作，单单的Spring好像是做不了的，注解@transactional怎么使用都解决不了问题，当时也不懂各个模块间交互的本质，不了解各种方式的代码具体实现原理，也不明白事务管理的实现，无法以当时的能力来解决这个问题（-.-当时并不是项目负责人，只是个小兵，但毕竟是不世之材，总觉得自己能弄懂，然后解决千古难题，后来发现，自己好像懂得还太少，还是交给大佬解决吧）。

    简单的分布式事务的难点还是各个模块间事务的统一管控，于本质来讲，模块间的调用和单纯的方法相互调用是类似的，当调用方法栈进行出入栈操作时，是一个比较好的控制时机，可以类比代理模式的处理（只是类比，并不是完全相似，现实框架例如：Spring）。当一个事务最外层的方法完成时再对事务进行操作（捕捉错误同理），在分布式中，主要需要解决的是这个完成信号的传递和事务提交的统一管理，前者在实际实现时的方式方法很多，所有交互方式都可以使用，后者的管理，需要自己对事务有一定的理解，如果是使用spring的话，也需要对spring 的事务管理方式有一定的理解。目前是没有一站式的公用框架，虽然网上确实有很多这样标题的框架，但使用的话因为项目的差异性会存在一定的不适性。如果项目时间和能力允许的话，更加推荐自己研发这个解决方案，也算是对于自己的提高和验证。

    3.各种混合数据源的事务

    时间线再往后移，自己负责项目的复杂度也会不断上升，项目整体架构的复杂度上升，也会导致某个方法的事务复杂度提升到另一个水平。有时候可能会出现一个完整的方法内出现多种不同数据源，而且还会对这些数据源进行不同的操作，如果这个时候再考虑数据的一致性，情况就会变得更加复杂了。存在无事务的数据源，存在各种异构数据源，什么时候改变哪个数据源的数据，或者在不能避免的情况下该如何去做补偿处理，都比较头疼。而且还会涉及到 各种事务的隔离性，可能有时候不会再是统一的隔离级别，各个方法都应该有不同的事务设定，具体情况需要具体分析，这个时候需要比较全面的知识储备，情况考虑不全或者不能及时发现并纠正错误的话，会造成比较大的问题，这个时候自己也是个“伪大佬”了，更多的时候需要去为团队承担起这些。现在经常对自己说的话已经变成了“我这可真蠢，这都没又发现”。。。吃饭吃饭