V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
brucefu
V2EX  ›  Java

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

  •  
  •   brucefu · 2020-08-21 16:18:47 +08:00 · 7454 次点击
    这是一个创建于 1315 天前的主题,其中的信息可能已经有所发展或是发生改变。

    好像引战贴 /狗头

    40 条回复    2023-04-25 10:42:07 +08:00
    tiedan
        1
    tiedan  
       2020-08-21 16:24:14 +08:00
    看具体业务
    john22eclipse
        2
    john22eclipse  
       2020-08-21 16:24:37 +08:00   ❤️ 18
    面试时用到
    realpg
        3
    realpg  
       2020-08-21 16:24:48 +08:00
    一个人的小破玩具项目,正在迁移支持分布式事务的数据库平台
    kidlj
        4
    kidlj  
       2020-08-21 16:29:42 +08:00
    一个人的小破玩具项目,打算用 CockroachDB 。部署在 K8S 上太方便了,一行命令。
    nozer
        5
    nozer  
       2020-08-21 16:31:31 +08:00
    重试、补偿。
    Jooooooooo
        6
    Jooooooooo  
       2020-08-21 16:32:38 +08:00   ❤️ 1
    不用

    最终一致是王道
    skypyb
        7
    skypyb  
       2020-08-21 17:57:14 +08:00 via Android
    一个人写想怎么用怎么用
    defage
        8
    defage  
       2020-08-21 18:10:43 +08:00
    要嘛 db 层直接解决了。要嘛就 BASE,最终一致性。

    程序内折腾分布式事务是个大坑,别看阿里开源了各种 tcc,tcc plus 。真实情况没几个用的,玩死团队会。
    Cbdy
        9
    Cbdy  
       2020-08-21 18:27:24 +08:00 via Android
    分布式事务可以交给分布式数据库实现,大小厂都可以用这种数据库吧
    shm7
        10
    shm7  
       2020-08-21 19:21:00 +08:00 via iPhone
    12306 春节抢票那种
    xuanbg
        11
    xuanbg  
       2020-08-21 19:24:06 +08:00   ❤️ 2
    多大厂也不会全面使用分布式事务。不是被逼得没办法,谁会去做坑死人的分布式事务。
    limboMu
        12
    limboMu  
       2020-08-21 19:26:54 +08:00
    ddia 中说过了,分布式事务是个有意思的研究,不过要运用到实际的开发,还需要研究更高效的协议,目前的分布式事务解决方案,运维开销有点大,不如老老实实设计好表结构避免分布式事务
    littlewing
        13
    littlewing  
       2020-08-21 19:30:28 +08:00
    楼上正解
    某国内大厂员工表示核心业务并没有使用分布式事物,原因是多方面的吧:做好很难,并不是强需求,并不是高优需求,性能问题(最终业务可能还是会尽可能避免使用)
    littlewing
        14
    littlewing  
       2020-08-21 19:32:43 +08:00
    @defage 正是因为 mysql 分库分表之后,在 DB/Proxy 上实现分布式事物很难,所以阿里才有了各种在程序内实现的补偿事物,但不管怎样,分布式事物就是个大坑
    chihiro2014
        15
    chihiro2014  
       2020-08-21 20:44:36 +08:00
    真正能用好的没几个。基本都不会去大范围使用
    cinlen
        16
    cinlen  
       2020-08-22 01:21:29 +08:00   ❤️ 3
    蹲一下大厂的朋友回复。我司用的是肉偿法听说过没有,就是人肉补偿事务。
    maigebaoer
        17
    maigebaoer  
       2020-08-22 01:23:58 +08:00 via Android
    @cinlen 讲道理,这很实用
    TypeError
        18
    TypeError  
       2020-08-22 02:02:43 +08:00 via Android
    某中厂,涉及钱的核心业务也是 mq 重拾补偿
    cassyfar
        19
    cassyfar  
       2020-08-22 03:51:21 +08:00   ❤️ 1
    multi-phase commit 用到了很多。

    另外我觉得 nosql DB 的 transaction 都得尊重这个来实现。我记得 DynamoDB transaction 是把所有 event 先记录进 log,然后一条条执行,出错就倒着回滚。

    不过 TCC 我确实没见过。
    594duck
        20
    594duck  
       2020-08-22 09:04:16 +08:00
    对大部份业务来说与其说多大厂,还不如说有多作,对就是有多作。

    你真要说分布式事务适合哪个厂,还不如说适合哪个业务,比如微博这种,纯文字信息流,没时实要求,天生适合 KV 的就适合。还有就是比如广告统计业务。Social 业务适合,那是可以的。

    你要说物流系统,工业生产系统,ERP,CRM,OA,财务系统,电商系统,金融系统 etc... 这些适合不适合。 要作,那也能上。CAP 原则 里看扔掉哪二个呗。

    所以这也是为什么到 2020 年了,Microsoft SQLSERVER 和 Oracle 这种公司活的美滋滋的原因。

    也就中国 13 亿人口基数折腾的动,放其它国家 TCO 一算,全部走商业数据库了。

    我有句名言,天下苦 MYSQL 久矣。
    kusya
        21
    kusya  
       2020-08-22 09:22:40 +08:00 via Android
    问下各位,如果实际场景中,业务分布在不同的数据库,又需要保证事务一致性,应该怎么办,比如账务系统。
    另外,对于多流程的复杂业务场景,怎么避免分布式事务
    xuanbg
        22
    xuanbg  
       2020-08-22 10:01:57 +08:00
    @cinlen 最终还是要靠肉偿的……只有这个才是终极可靠的兜底方案。
    xuanbg
        23
    xuanbg  
       2020-08-22 10:07:38 +08:00
    @kusya 如果你的肉偿能力不被击穿,就和保证新冠肺炎保证不会击穿医疗能力一样(这就和英国搞全面免疫一个意思),就不需要由系统来保证一致性。

    简单地说,就是只要人工处理不一致的能力有富余,你就让他不一致呗。
    PopRain
        24
    PopRain  
       2020-08-22 10:08:15 +08:00
    @594duck 最近想把系统迁移到 postgresql,发现 SQL server 和 oracle 比,花里胡哨的功能很多,真正“商用”(不是互联网应用)的功能,有些地方还是欠缺不少。。。。
    Yano
        25
    Yano  
       2020-08-22 10:12:36 +08:00
    @cinlen 好评,我认识一个小厂就是人肉补偿法,其实做好日志、行为记录,补偿还是很简单的,或者定时任务补偿法
    snappyone
        26
    snappyone  
       2020-08-22 10:29:07 +08:00
    @Cbdy 分布式事务跟分布式数据库不是一码事
    594duck
        27
    594duck  
       2020-08-22 10:41:18 +08:00 via iPhone
    @PopRain 举个欠缺的例子呢
    passerbytiny
        28
    passerbytiny  
       2020-08-22 10:43:18 +08:00 via Android
    @kusya 大多数情况下只需要保证最终一致性即可,不需要保证事务一致性。你举例的账务系统是个典型的只需要最终一致性的系统:一个月就出账那一天需要一致性。

    最终一致性大多用补偿机制来处理,比如发现重复扣费了就加个原路退款处理。不要相信那个肉偿的,肉偿也要成本的,冲突率极小的系统中,才能用肉偿替代系统自动补偿。
    azureus
        29
    azureus  
       2020-08-22 11:27:12 +08:00
    一般做业务不直接用分布式事务。分布式事务是分布式关系型数据库的基本能力,要由关系型数据库来保证事务一致性。

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

    大厂基本上都有这样的产品,只不过赚钱能力比不上业务,所以很低调罢了。至于小厂,直接用就可以了。
    bitholic
        30
    bitholic  
       2020-08-22 14:07:03 +08:00 via iPhone
    满足 BASE 就行了
    PopRain
        31
    PopRain  
       2020-08-22 15:22:00 +08:00
    @594duck 我常用的这 3 个功能不支持,我又不想去改 ORM 的底层,也不想让程序只能对应一个数据库
    1. 不支持大小写不敏感的查询(citext 在参数化查询需要加强制类型转换提示,ORM 不方便,用不确定 collation 也有问题,譬如不支持 like )
    2.不支持事务嵌套(需要用 SavePoints 模拟,没有办法用通用的 ORM )
    3.不支持跨数据库、跨服务器的视图、引用。(用 dblink 效率比较低,ORM 也不方便用)
    janus77
        32
    janus77  
       2020-08-22 15:41:07 +08:00
    如果你爱折腾,多小的项目都能用
    594duck
        33
    594duck  
       2020-08-22 16:46:36 +08:00
    @PopRain

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

    事务嵌套在任何数据库里都是不大推荐的做法,所以各家实现都有各家实现的不一样的细节方法。
    icerwinter
        34
    icerwinter  
       2020-08-22 23:13:44 +08:00
    @594duck 这意思是说我国人口基数大,一批人耐不住不用产品了 终还是有另一波人使用?
    哈哈
    594duck
        35
    594duck  
       2020-08-23 08:47:56 +08:00 via iPhone
    @icerwinter 人口基数大,所以试错成本低
    CantSee
        36
    CantSee  
       2020-08-25 09:11:55 +08:00
    只是用了最大努力通知的一个概念,没有用分布式事务!
    ksice
        37
    ksice  
       2020-09-01 15:36:33 +08:00
    看业务场景而不是公司大小吧,有些场景可能必须要分布式事务
    facelezz
        38
    facelezz  
       2020-09-08 19:34:16 +08:00
    @cinlen 人肉补偿属于“高阶最终灵活可能不太一致的一致性”
    dongfuye1
        39
    dongfuye1  
       2021-11-12 21:32:21 +08:00
    一般情况下的选择是:
    设计上避免分布式事务>分布式数据库>分布式事务>定时任务补偿>人肉补偿
    前三种方案要看你的业务和公司环境,在这三种当中选择一种合适的。最后两种开发成本、人工成本过高,而且特别容易出错,不建议采用
    分布式事务也有很好用的框架,里面有很多文章,把相关的内容讲得很透彻,有兴趣可以看看 https://github.com/yedf/dtm
    DreamStar
        40
    DreamStar  
       338 天前
    单表数据过多导致分库表产生的分布式事务->分布式数据库解决
    业务上跨服务调用产生的分布式事务->最终一致性解决
    总结来说, 分布式数据库要解决的分布式事务问题不等于全部分布式事务问题
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   941 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 20:51 · PVG 04:51 · LAX 13:51 · JFK 16:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.