DreamStar 最近回复了
你还想控制三方服务回滚, 属实想多了.
自己业务执行完提交后, 在请求三方, 失败可以重试.
如果业务调三方有返回值依赖, 业务添加中间状态, 前置业务完成, 可重试的请求三方直到成功, 继续后置业务.
就是最终一致性, 多从业务流程层面解决吧.
单表数据过多导致分库表产生的分布式事务->分布式数据库解决
业务上跨服务调用产生的分布式事务->最终一致性解决
总结来说, 分布式数据库要解决的分布式事务问题不等于全部分布式事务问题
先从业务上调整, 能整合的整合, 能合并的合并.
其次同步转异步, 事件驱动用消息队列+本地事件表,根据具体的消费能力调整并发即可.
你这个量用单进程多线程做稳定性太差,吞吐量太低,没啥可观测性.
非空, 非负, 长度啥的在应用服务就搞定.
email 之类的实体数据, 用值对象解决, 构造的时候就判断了, 不可能有非法的.
唯一类验证交给 repo 服务做 exist 判断, 并发创建唯一交给数据库唯一索引就行
ctrl + p 一次可以看到方法签名 两次可以显示参数名 临时的
编辑器->嵌入提示->形参名称->Java
Editor->Inlay hints->Parameter names->Java
关于形参名称有好几个设置
升级一下 Java 版本, 用协程就不用搞这么多魔法操作了
数据库层面
数据库上唯一限制, 并发更新上乐观锁字段.
代码层面
做个过滤器, 出个幂等接口返一个 token, 同 token 只有一次能成功, 多次就是重复请求
redis 锁
首先是代码写的不要职责太多, 一棵树从不同角度学科看能刨析出众多属性来, 抽象要合理, 限制在你的实际问题内.
其次是复杂度是恒定的, 没有任何一种方式能规避复杂度, 他只会从你看的到的地方转移到你看不到的地方.