多大厂才能用到分布式事务

[brucefu]

好像引战贴 /狗头

[kusya]

问下各位，如果实际场景中，业务分布在不同的数据库，又需要保证事务一致性，应该怎么办，比如账务系统。
另外，对于多流程的复杂业务场景，怎么避免分布式事务

[xuanbg]

@cinlen 最终还是要靠肉偿的……只有这个才是终极可靠的兜底方案。

[xuanbg]

@kusya 如果你的肉偿能力不被击穿，就和保证新冠肺炎保证不会击穿医疗能力一样（这就和英国搞全面免疫一个意思），就不需要由系统来保证一致性。

简单地说，就是只要人工处理不一致的能力有富余，你就让他不一致呗。

[PopRain]

@594duck 最近想把系统迁移到 postgresql，发现 SQL server 和 oracle 比，花里胡哨的功能很多，真正“商用”(不是互联网应用）的功能，有些地方还是欠缺不少。。。。

[Yano]

@cinlen 好评，我认识一个小厂就是人肉补偿法，其实做好日志、行为记录，补偿还是很简单的，或者定时任务补偿法

[snappyone]

@Cbdy 分布式事务跟分布式数据库不是一码事

[594duck]

@PopRain 举个欠缺的例子呢

[passerbytiny]

@kusya 大多数情况下只需要保证最终一致性即可，不需要保证事务一致性。你举例的账务系统是个典型的只需要最终一致性的系统：一个月就出账那一天需要一致性。

最终一致性大多用补偿机制来处理，比如发现重复扣费了就加个原路退款处理。不要相信那个肉偿的，肉偿也要成本的，冲突率极小的系统中，才能用肉偿替代系统自动补偿。

[azureus]

一般做业务不直接用分布式事务。分布式事务是分布式关系型数据库的基本能力，要由关系型数据库来保证事务一致性。

因为分布式数据库领域很冷门，所以才觉得用的少，实际上已经用的相当广泛。

大厂基本上都有这样的产品，只不过赚钱能力比不上业务，所以很低调罢了。至于小厂，直接用就可以了。

[bitholic]

满足 BASE 就行了

[PopRain]

@594duck 我常用的这 3 个功能不支持，我又不想去改 ORM 的底层，也不想让程序只能对应一个数据库
1. 不支持大小写不敏感的查询(citext 在参数化查询需要加强制类型转换提示,ORM 不方便，用不确定 collation 也有问题，譬如不支持 like ）
2.不支持事务嵌套（需要用 SavePoints 模拟，没有办法用通用的 ORM ）
3.不支持跨数据库、跨服务器的视图、引用。（用 dblink 效率比较低，ORM 也不方便用）

[janus77]

如果你爱折腾，多小的项目都能用

[594duck]

@PopRain

就第 2 个事务嵌套，postgres 的实现就是私有实现，和你的原则 不改 ORM 底层，不让程序只对应一个数据库的原则 是冲突的。

事务嵌套在任何数据库里都是不大推荐的做法，所以各家实现都有各家实现的不一样的细节方法。

[icerwinter]

@594duck 这意思是说我国人口基数大，一批人耐不住不用产品了 终还是有另一波人使用？
哈哈

[594duck]

@icerwinter 人口基数大，所以试错成本低

[CantSee]

只是用了最大努力通知的一个概念,没有用分布式事务!

[ksice]

看业务场景而不是公司大小吧，有些场景可能必须要分布式事务

[facelezz]

@cinlen 人肉补偿属于“高阶最终灵活可能不太一致的一致性”

[dongfuye1]

一般情况下的选择是：
设计上避免分布式事务>分布式数据库>分布式事务>定时任务补偿>人肉补偿
前三种方案要看你的业务和公司环境，在这三种当中选择一种合适的。最后两种开发成本、人工成本过高，而且特别容易出错，不建议采用
分布式事务也有很好用的框架，里面有很多文章，把相关的内容讲得很透彻，有兴趣可以看看 https://github.com/yedf/dtm

[DreamStar]

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