DreamStar

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

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

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

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

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

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

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

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

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

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

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