写回答
-
建议参考阿里云的TXC 现在叫GTS https://www.aliyun.com/aliware/txc?spm=a2c4e.11153987.0.0.59f37ce7jx6jp5
2019-07-17 23:30:28赞同 展开评论 打赏 -
基本思路：
在发起方发起一个分布式事物，通过拦截器记录下游的参与者信息(比如rpc的泛化接口信息)，分2个阶段，一阶段上下游执行正常的业务逻辑，下游一般完成一些流水的落DB。 在发起方本地事物提交时，通过spring事物提交回调，感知到发起方的事物是提交还是回滚，根据发起方拦截器记录的下游参与者信息，来调用下游的PRC的commit或rollback2019-07-17 23:30:27赞同 展开评论 打赏 -
可以使用阿里云的gts哦，具体地址：https://www.aliyun.com/aliware/txc?spm=a2c4e.11153940.blogcont542020.22.5890446aJY0XwQ
2019-07-17 23:30:27赞同 展开评论 打赏 -
阿里高级开发工程师 长期招聘 Java 高级开发工程师/技术专家。欢迎赐简历：chongyue.jxy@alibaba-inc.com事务消息+最终一致性
2019-07-17 23:30:27赞同 展开评论 打赏 -
-
-
-
数据库层面，通常可以利用db本身的一些分布式能力，如果db不具备或者不方便使用，可以选用一些具备分布式能力的datasource类产品，比如阿里云的Druid，利用sring的xa等；
如果是通信层面的，通常使用redis等中间件做二段式或者三段式提交，这个网上有很多参考。
但无论是哪样，关键是要看业务上的具体诉求，是能容忍短暂的不一致，需要高吞吐，还是类似金融场景，极强的一致性，可以牺牲吞吐（最好的例子就是比特币交易）2019-07-17 23:30:27赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
