你还想控制三方服务回滚, 属实想多了.
自己业务执行完提交后, 在请求三方, 失败可以重试.
如果业务调三方有返回值依赖, 业务添加中间状态, 前置业务完成, 可重试的请求三方直到成功, 继续后置业务.

就是最终一致性, 多从业务流程层面解决吧.

单表数据过多导致分库表产生的分布式事务->分布式数据库解决
业务上跨服务调用产生的分布式事务->最终一致性解决
总结来说, 分布式数据库要解决的分布式事务问题不等于全部分布式事务问题

这也是反爬手段的一种, 非常恶心和刁钻

先从业务上调整, 能整合的整合, 能合并的合并.
其次同步转异步, 事件驱动用消息队列+本地事件表,根据具体的消费能力调整并发即可.
你这个量用单进程多线程做稳定性太差,吞吐量太低,没啥可观测性.

非空, 非负, 长度啥的在应用服务就搞定.
email 之类的实体数据, 用值对象解决, 构造的时候就判断了, 不可能有非法的.
唯一类验证交给 repo 服务做 exist 判断, 并发创建唯一交给数据库唯一索引就行

ctrl + p 一次可以看到方法签名 两次可以显示参数名 临时的

编辑器->嵌入提示->形参名称->Java
Editor->Inlay hints->Parameter names->Java
关于形参名称有好几个设置

升级一下 Java 版本, 用协程就不用搞这么多魔法操作了

数据库层面
数据库上唯一限制, 并发更新上乐观锁字段.

代码层面
做个过滤器, 出个幂等接口返一个 token, 同 token 只有一次能成功, 多次就是重复请求
redis 锁

首先是代码写的不要职责太多, 一棵树从不同角度学科看能刨析出众多属性来, 抽象要合理, 限制在你的实际问题内.
其次是复杂度是恒定的, 没有任何一种方式能规避复杂度, 他只会从你看的到的地方转移到你看不到的地方.

序列化方面不多赘述, jdk8 时间类库足以

```java
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
Instant now = Instant.now();
System.out.printf(
"中国: %s%n 泰国: %s",
formatter.format(now.atZone(ZoneId.of("Asia/Shanghai"))),
formatter.format(now.atZone(ZoneId.of("Asia/Bangkok")))
);
```

写了不少, 写累了. 转成一段话.
用 OOP 的范式参考 DDD 战术策略 把 与领域(业务)专家沟通的专业知识和专用词语构建成的统一语言模型 转换 为近似自然语言的用例和代码即可.
领域事件是帮你模拟自然的, 有助于解耦和拆解大事务.(其实最终一致性才是大多数, 真正必须的强一致还是少的)
CQRS 是帮你解决写核心业务时强行兼容查询模型带来的冲突.
写领域模型时不要考虑表结构, 要优先考虑模型结构, 在最后持久化时实在调和不了的按需调整模型.
跟领域专家不要提技术相关词语, 用跟领域专家能听懂的模型语言沟通, DDD 最核心的在于技术跟业务同用一套模型语言沟通与交流.
----
在上下文中将所有实体组合成的超级聚合的最顶级实体就是聚合根, 你的所有业务方法都以聚合根为入口.
例如参赛者(选手)报名参赛, 将其分配到竞赛第一赛程的某一个竞赛组中.你将通过竞赛对象上的一个添加参赛者的方法把这个选手通过内部赛程,竞赛组的相关方法记录进去.

这个超级聚合是不可取的, 因为聚合要保证一致性, 会有剧烈的并发冲突. 加载时也要全部加载, 浪费资源.
要根据实际情况的生命周期和最小一致性来拆分.
例如竞赛和赛程在超级聚合中是组合关系, 现在拆成聚合关系, 即仅记录所有赛程的 id(当然也可以记录部分摘要信息, 也可以只记录当前赛程的 id), 看业务而定. 如果记录摘要, 当赛程更新是发出事件, 竞赛监听赛程更改事件更新摘要, 而不是在更新赛程的事务中同时更新摘要!

每次事务只更改一个聚合, 跨聚合更改用事件来做最终一致性.
当然一定要跟领域(业务)专家沟通好.

YLF8HK 已用