分布式事物 - 基于RPC调用 - TCC模式

前提

• 前端业务(主服务)可以以同步或异步调用tcc框架,或者tcc框架本身就是同步异步兼备的.
• 假定tcc框架拥有断电后的自动恢复能力.同时,在下游业务出现无限失败的情况下,也会进行无限的重试,以达到最终一致

正式开始

正常流程

一切安好.
可以观察到,confirm操作完全交由tcc调用.在同步状态下,无论最终成功与失败,可能出现前端等待时间过长的问题.
个人认为,try阶段,也可以直接注册到tcc中,并完全交由tcc框架调用,客户端只访问其保留的接口.

预留失败

因下游业务或网络问题导致了预留失败.
与正常流程相同,不过此时调用了tcc的cancel操作

总结

• 实施tcc方案时,最好在立项伊始就要做好相应的数据库设计与接口定义方案.能在数据库中保存"预留"数据,同时相关代码提供"预留","确认","取消"方法的接口定义以用作实现.
• 整体来说,业务级人员减小了业务开发难度(虽然工作量变大了).同时将重心转移到了"tcc框架"的实现.它需要保证高可用,数据安全,幂等,甚至需要能处理代码迭代引起的版本差异的问题
• 因为设计到事物管理问题,其框架开发难度也变大了,可以使用开源框架如:
  1. easytransaction
  2. bytetcc
  3. ...