从一个典型例子入手讲下分布式事务。
分布式事务的典型例子:
跨行转账
银行A的账号 Bob
银行B的账号 Smith
银行A的模块,库A
Bob向Smith转账100元
两阶段
两阶段提交
prepare(Bob - 100) 节点A
prepare(Smith + 100) 节点B
commit(Bob)
commit(Smith)
事务完成
两阶段提交的核心,就是在两个prepare阶段,都对Bob、Smith加锁,阻止外部对这两个数据的访问,
1. Tm本身需要记录事务进行的过程,log要保证安全和可信,性能非常低。
2. 锁的利用率和并行性较低。
3. 网络开销较大
4. 可见性要求实际上就等于让快的操作等慢的。
所以从性能角度来说,这类需求不多也不常见。
其实,从实际上来看,并不需要对Bob和Smith同时这么强的一致性,只需要对Bob强一致性,需要判断他有足够的钱才能转账;
而对Smith来说,不需要加锁判断他的钱是否足够,只需往他账号加钱,所以对Smith是最终一致性。
下面看看另一方案。
最终一致性
begin transaction
1.Bob账号有足够的钱,则减钱;钱不够则交易停止。
2.生成一交易记录log到库A,生成一个交易id,orderId(也可以叫transactionId,只为唯一标识该次交易)。
end transa
分布式事务的典型例子:
跨行转账
银行A的账号 Bob
银行B的账号 Smith
银行A的模块,库A
Bob向Smith转账100元
两阶段
两阶段提交
prepare(Bob - 100) 节点A
prepare(Smith + 100) 节点B
commit(Bob)
commit(Smith)
事务完成
两阶段提交的核心,就是在两个prepare阶段,都对Bob、Smith加锁,阻止外部对这两个数据的访问,
1. Tm本身需要记录事务进行的过程,log要保证安全和可信,性能非常低。
2. 锁的利用率和并行性较低。
3. 网络开销较大
4. 可见性要求实际上就等于让快的操作等慢的。
所以从性能角度来说,这类需求不多也不常见。
其实,从实际上来看,并不需要对Bob和Smith同时这么强的一致性,只需要对Bob强一致性,需要判断他有足够的钱才能转账;
而对Smith来说,不需要加锁判断他的钱是否足够,只需往他账号加钱,所以对Smith是最终一致性。
下面看看另一方案。
最终一致性
begin transaction
1.Bob账号有足够的钱,则减钱;钱不够则交易停止。
2.生成一交易记录log到库A,生成一个交易id,orderId(也可以叫transactionId,只为唯一标识该次交易)。
end transa