V2EX › dongfuye1 的所有回复 › 第 2 页 / 共 5 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 2 3 4 5

❮

❯

2022 年 4 月 25 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@1018ji 2 只能是本地事务，可以是 redis sql mongodb 。如果是服务的话，那么就变成普通的 msg 或者 saga 了

2022 年 4 月 19 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@kongkongyzt 是的，go-zero 是微服务框架，dtm 则解决单体事务拆分后无法保持 acid 的问题

2022 年 4 月 9 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@z960112559 这种简写含义已经很明显了，缩写不会造成歧义。在没有大的歧义的情况下，那么采用缩写或者不缩写，就只是不同语言，不同开发者的风格喜好不同了，并无好坏之分

2022 年 4 月 8 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@brust 感谢支持！

2022 年 4 月 7 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@z960112559 是否有具体一些的意见？ Go 里面的命名一般都比 Java 短

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@cassyfar 没看出来这个是要默认 100%，而我更认为达到了 99.99958 ％的平均可用性，那么用户已经不需要关心可用性问题了。
对于重试这个场景，都会有一个策略，一般都会延迟重试，并且有限流，去避免重试导致的负载问题。应用当然希望没有宕机，但是在分布式应用中，宕机是不可避免的，因此微服务框架、K8S 云原生都会有相应的策略，处理这样的情况。

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@yzbythesea 这个惊群问题是一个经典问题，跟重试并不是同一个问题，而是 epoll 相关的一个问题，已经有解决方案了。

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@yzbythesea 难道服务都不重试的吗？也没听说过哪个厂的服务挂了 1s 成为新闻的。无论是 lvs 这类高可用设施，还是现代的分布式共识算法，在出现机器宕机后，摘除正在使用故障机器，都不是 1s 完成的，通常都在 3s 以上

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@yzbythesea 谷歌分布式锁 Chubby 的公开数据显示，集群能提供 99.99958 ％的平均可用性，一年也就 130s 的运行中断。还没有听说哪个厂以 6 个 9 作为标准了，一年只允许 13s 以内的不可用？

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@Chinsung 通知下游微服务 2 的时候，如果中间出错，会进行重试，保证最终一致性。
解耦方面，如果又要给用户加积分，那么可以定义好了新的加积分服务之后，未来只需要在 dtm 的管理后台里面，针对这个消息类型，添加上新服务的配置就行，类似于新服务去消费支付成功的消息。
广播式的事务这种，对于正常未出错的请求，dtm 的性能消耗是非常低的，就是正常的记录全局事务进度。而对于出错需要重试的请求，代价也不高，就是批量查询出超时的全局事务，然后进行处理即可。
dtm 针对解决分布式事务中的问题，在这方面已比较完善。但定位不一样，不会把消息中间件的所有功能都支持

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@yzbythesea 文中没有说 prepare-submit 是二阶段消息的创新点，也说明了这种方式是受到了 RocketMQ 事务消息的启发。二阶段消息带来的主要变化是，大幅度简化了使用者的工作量，使用者完全只需要使用 api 的方式，不需要任何消息队列，就能够解决消息最终一致性的问题，大幅度减少代码量，大幅降低使用门槛。原理上，二阶段消息做了自动回查，这个是首创，还申请了专利。
现在 redis/mysql 都已经有主从复制，能够保证稳定性了，对于绝大多数的应用已经足够了哈

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@stop9125 普通的应用一般都会把数据保存在共享的存储，例如 mysql 中，云厂商基本都提供了支持高可用的数据库服务，如果需要容灾，云厂商也会有相关的方案。
你说的这个资源锁定，我还不清楚具体指什么，如果说扣库存的场景，那么在数据库中扣库存，那么单个商品的并发上限并不高，但假如不是争抢一个商品项，那么 dtm 的性能测试中，普通配置可以达到 900+tps ，如果要更好的并发，可以选择 redis 存储，单个 redis 可以做到 1w+tps 。
如果您需要 mysql 存储更高的性能，当前可以部署多组，未来 dtm 可能会开发集群版，或者自定义的存储，支持更高的性能。

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@swulling 腾讯的微信支付当然没有使用 dtm 哈，dtm 开源还不到一年的时间。

dtm 合并了六七位腾讯同学提过来 PR ，这个是确定的哈。至于具体什么业务什么部门用了 dtm ，未经过对方允许，我也不能够公开往外说

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@swulling dtm 在腾讯内部已经使用很广泛，承担的负载也比较高，有多个事业部在使用。给 dtm 提 PR 的腾讯同学，已经有了六七位了。
自己实现分布式事务的难度一点都不小哈，了解过字节百度他们内部也有分布式事务项目，他们是有专门的小组负责，在一定的范围内适用。
即使大厂自己实现的分布式事务，也不一定比开源做得更好。许多对分布式事务有过研究的大厂同学同事，对 dtm 的认可度非常高

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@Chinsung 文中有介绍跟 RocketMQ 的事务消息的区别。从时序图上面看，两者比较接近，文中也说了这个方案受到事务消息的启发。不同点在于：1. 自动回查的处理，RocketMQ 的消息回查方案，全网搜到的，都是有问题的，而 dtm 解决了这个问题，还申请了专利； 2. dtm 暴露给用户的，全部是 api 式的接口，与消息队列无关，用户无需掌握消息队列的知识，也无需维护一个高可用的消息队列，最终代码也大幅度简化，因此开发维护成本大幅降低

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@zagfai 我不年轻了哈，是不是大事情，可以从文章从项目中判断出来哈

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@metrue 测试覆盖率已恢复正常，现在是 97%

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@metrue 不好意思，测试覆盖率一直是在 95%+，参见 https://app.codecov.io/gh/dtm-labs/dtm ，这几天可能 codecov 有变更导致一下子变成了 17%，预计今天会修复这个问题

正在使用的企业已经包括了腾讯，字节，可以放心使用的

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@stop9125 DTM 本身是无状态的，会将全局事务的进度保存在数据库或者 Redis 中。这种架构可以直接部署多实例，提供高可用的服务。

2022 年 4 月 6 日

回复了 dongfuye1 创建的主题 › 分享创造 › 消息最终一致性的架构革命

@putaozhenhaochi 新的架构可以完美替代本地消息表和事务消息

1 2 3 4 5

❮

❯