日常学习小结,不计内容、不计形式。
分布式事务实现
rabbitmq实现
对于不要求强一致性场景,基于base理论,允许过程中的软状态,结果的最终一致性。注意:rabbitmq的消费确认,实现闭环。
XA协议
基于2pc提交,实现强一致性。资源管理器往往由数据库实现,事务管理器(TM)作为协调者,负责本地资源管理回滚与提交。
缺点:事务管理器会等待资源管理器的回复,如果一直不回复会一直等待,阻塞进程。
<!-- atomikos事务管理器 -->
<bean id="atomikosTransactionManager" class="com.atomikos.icatch.jta.UserTransactionManager"
init-method="init" destroy-method="close">
<property name="forceShutdown">
<value>true</value>
</property>
</bean>
<bean id="atomikosUserTransaction" class="com.atomikos.icatch.jta.UserTransactionImp">
<property name="transactionTimeout" value="300" />
</bean>
<!--db0.t_order表-->
<bean id="jdbcTemplateOrder" class="org.springframework.jdbc.core.JdbcTemplate">
<constructor-arg ref="dataSourceOrder" />
</bean>
<!--db1.t_product表-->
<bean id="jdbcTemplateStock" class="org.springframework.jdbc.core.JdbcTemplate">
<constructor-arg ref="dataSourceStock" />
</bean>
<!-- spring 事务管理器 -->
<bean id="transactionManager"
class="org.springframework.transaction.jta.JtaTransactionManager">
<property name="transactionManager">
<ref bean="atomikosTransactionManager" />
</property>
<property name="userTransaction">
<ref bean="atomikosUserTransaction" />
</property>
</bean>
TCC
TCC也基于2pc提交,提供了一个编程框架,将整个业务逻辑分为三块:Try、Confirm和Cancel三个操作。Try阶段会去锁定资源,Confirm阶段则是提交,若提交失败,Cancel阶段回滚,释放资源。总之,TCC就是通过代码人为实现了两阶段提交,不同的业务场景所写的代码都不一样,复杂度也不一样,因此,这种模式并不能很好地被复用。