前提
- 前端业务(主服务)可以以同步或异步调用TCC框架,或者TCC框架本身就是同步异步兼备的.
- 假定TCC框架拥有断电后的自动恢复能力.同时,在下游业务出现无限失败的情况下,也会进行无限的重试,以达到最终一致
正式开始
正常流程
一切安好.
可以观察到,confirm操作完全交由TCC调用.在同步状态下,无论最终成功与失败,可能出现前端等待时间过长的问题.
个人认为,try阶段,也可以直接注册到TCC中,并完全交由TCC框架调用,客户端只访问其保留的接口.
预留失败
因下游业务或网络问题导致了预留失败.
与正常流程相同,不过此时调用了TCC的cancel操作
总结
- 实施TCC方案时,最好在立项伊始就要做好相应的数据库设计与接口定义方案.能在数据库中保存"预留"数据,同时相关代码提供"预留","确认","取消"方法的接口定义以用作实现.
- 整体来说,业务级人员减小了业务开发难度(虽然工作量变大了).同时将重心转移到了"TCC框架"的实现.它需要保证高可用,数据安全,幂等,甚至需要能处理代码迭代引起的版本差异的问题
- 因为设计到事物管理问题,其框架开发难度也变大了,可以使用开源框架如: