警告
交易一致问题是目前分布式环境下的最主要的矛盾之一,也是最容易出问题的地方.这个问题横跨所有的框架,技术栈,编程语言.
引发这个问题的根源,是之前所有的计算机科学的理论和现在分布式的玩法之间的矛盾.我们不可能在不清楚原理的情况下,找到答案.
什么是交易一致
我们在平常的IT建设中,难免会开发到比较核心的业务场景,这种核心的业务场景要求一般都比较苛刻,提供的服务又比较关键.
2021/10/30大约 9 分钟
本项目用于对qilu-state的示例,给出一个示例的多订单多状态的模拟处理流程,在任意停机,任意关闭服务的情况下,结合qilu-task实现在5分钟内,所有的订单状态都会保持一致.
项目启动
- 执行数据库脚本,sql/ddl.sql 这个sql是mysql语法,如果要其他数据库的,需要转换
- 配置数据源,分别在MockRunner.java和StateSampleRunner.java中,自行修改数据源的连接
- 配置MQ,项目中支付通知和发货通知都是使用MQ进行,配置文件在mock/main/resources/config/conf.properties和state/main/resources/config/conf.properties中
- 部分依赖base的jar包,请关注项目中的settings-hw.xml文件,配置好里面的profile部分,如果还是不行,请看编译
2021/10/30大约 5 分钟
背景
详细的交易一致性问题,请看<交易一致的由来>.
交易一致性的问题,解决的思路只有一个,那就是本地事务和远程调用的分离.虽然spring帮我们实现了在任意代码里面可以使用事务,但是一旦事务中包含远程调用,上述文章的内容就无法避免.
有的公司也使用"流程引擎"来解决,但是很不幸,如果引入"流程引擎",因为涉及到状态补单,"流程引擎"还有自己的保存事务,业务的订单也有自己的保存事务,引入"流程引擎"会因为额外的事务引入,会让情况变的更加复杂.qilu-state被设计成没有存储的最主要原因.
2021/10/30大约 12 分钟