这是一个创建于 1586 天前的主题，其中的信息可能已经有所发展或是发生改变。
好像引战贴 /狗头
 |
1
tiedan 2020-08-21 16:24:14 +08:00
看具体业务
|
 |
2
john22eclipse 2020-08-21 16:24:37 +08:00  18
面试时用到
|
 |
3
realpg 2020-08-21 16:24:48 +08:00
一个人的小破玩具项目，正在迁移支持分布式事务的数据库平台
|
 |
4
kidlj 2020-08-21 16:29:42 +08:00
一个人的小破玩具项目，打算用 CockroachDB 。部署在 K8S 上太方便了，一行命令。
|
 |
5
nozer 2020-08-21 16:31:31 +08:00
重试、补偿。
|
 |
6
Jooooooooo 2020-08-21 16:32:38 +08:00 1
不用
最终一致是王道 |
 |
7
skypyb 2020-08-21 17:57:14 +08:00 via Android
一个人写想怎么用怎么用
|
 |
8
defage 2020-08-21 18:10:43 +08:00
要嘛 db 层直接解决了。要嘛就 BASE，最终一致性。
程序内折腾分布式事务是个大坑，别看阿里开源了各种 tcc，tcc plus 。真实情况没几个用的，玩死团队会。 |
 |
9
Cbdy 2020-08-21 18:27:24 +08:00 via Android
分布式事务可以交给分布式数据库实现，大小厂都可以用这种数据库吧
|
 |
10
shm7 2020-08-21 19:21:00 +08:00 via iPhone
12306 春节抢票那种
|
 |
11
xuanbg 2020-08-21 19:24:06 +08:00 2
多大厂也不会全面使用分布式事务。不是被逼得没办法，谁会去做坑死人的分布式事务。
|
 |
12
limboMu 2020-08-21 19:26:54 +08:00
ddia 中说过了，分布式事务是个有意思的研究，不过要运用到实际的开发，还需要研究更高效的协议，目前的分布式事务解决方案，运维开销有点大，不如老老实实设计好表结构避免分布式事务
|
 |
13
littlewing 2020-08-21 19:30:28 +08:00
楼上正解
某国内大厂员工表示核心业务并没有使用分布式事物，原因是多方面的吧：做好很难，并不是强需求，并不是高优需求，性能问题（最终业务可能还是会尽可能避免使用） |
|
14
littlewing 2020-08-21 19:32:43 +08:00
@defage 正是因为 mysql 分库分表之后，在 DB/Proxy 上实现分布式事物很难，所以阿里才有了各种在程序内实现的补偿事物，但不管怎样，分布式事物就是个大坑
|
 |
15
chihiro2014 2020-08-21 20:44:36 +08:00
真正能用好的没几个。基本都不会去大范围使用
|
 |
16
cinlen 2020-08-22 01:21:29 +08:00 3
蹲一下大厂的朋友回复。我司用的是肉偿法听说过没有，就是人肉补偿事务。
|
 |
17
maigebaoer 2020-08-22 01:23:58 +08:00 via Android
@cinlen 讲道理，这很实用
|
 |
18
TypeError 2020-08-22 02:02:43 +08:00 via Android
某中厂，涉及钱的核心业务也是 mq 重拾补偿
|
 |
19
cassyfar 2020-08-22 03:51:21 +08:00 1
multi-phase commit 用到了很多。
另外我觉得 nosql DB 的 transaction 都得尊重这个来实现。我记得 DynamoDB transaction 是把所有 event 先记录进 log，然后一条条执行，出错就倒着回滚。 不过 TCC 我确实没见过。 |
 |
20
594duck 2020-08-22 09:04:16 +08:00
对大部份业务来说与其说多大厂，还不如说有多作，对就是有多作。
你真要说分布式事务适合哪个厂，还不如说适合哪个业务，比如微博这种，纯文字信息流，没时实要求，天生适合 KV 的就适合。还有就是比如广告统计业务。Social 业务适合，那是可以的。 你要说物流系统，工业生产系统，ERP，CRM，OA，财务系统，电商系统，金融系统 etc... 这些适合不适合。 要作，那也能上。CAP 原则 里看扔掉哪二个呗。 所以这也是为什么到 2020 年了，Microsoft SQLSERVER 和 Oracle 这种公司活的美滋滋的原因。 也就中国 13 亿人口基数折腾的动，放其它国家 TCO 一算，全部走商业数据库了。 我有句名言，天下苦 MYSQL 久矣。 |
 |
21
kusya 2020-08-22 09:22:40 +08:00 via Android
问下各位，如果实际场景中，业务分布在不同的数据库，又需要保证事务一致性，应该怎么办，比如账务系统。
另外，对于多流程的复杂业务场景，怎么避免分布式事务 |
|
23
xuanbg 2020-08-22 10:07:38 +08:00
@kusya 如果你的肉偿能力不被击穿，就和保证新冠肺炎保证不会击穿医疗能力一样（这就和英国搞全面免疫一个意思），就不需要由系统来保证一致性。
简单地说，就是只要人工处理不一致的能力有富余，你就让他不一致呗。 |
 |
24
PopRain 2020-08-22 10:08:15 +08:00
@594duck 最近想把系统迁移到 postgresql，发现 SQL server 和 oracle 比，花里胡哨的功能很多，真正“商用”(不是互联网应用）的功能，有些地方还是欠缺不少。。。。
|
 |
28
passerbytiny 2020-08-22 10:43:18 +08:00 via Android
@kusya 大多数情况下只需要保证最终一致性即可，不需要保证事务一致性。你举例的账务系统是个典型的只需要最终一致性的系统：一个月就出账那一天需要一致性。
最终一致性大多用补偿机制来处理，比如发现重复扣费了就加个原路退款处理。不要相信那个肉偿的，肉偿也要成本的，冲突率极小的系统中，才能用肉偿替代系统自动补偿。 |
 |
29
azureus 2020-08-22 11:27:12 +08:00
一般做业务不直接用分布式事务。分布式事务是分布式关系型数据库的基本能力，要由关系型数据库来保证事务一致性。
因为分布式数据库领域很冷门，所以才觉得用的少，实际上已经用的相当广泛。 大厂基本上都有这样的产品，只不过赚钱能力比不上业务，所以很低调罢了。至于小厂，直接用就可以了。 |
 |
30
bitholic 2020-08-22 14:07:03 +08:00 via iPhone
满足 BASE 就行了
|
|
31
PopRain 2020-08-22 15:22:00 +08:00
@594duck 我常用的这 3 个功能不支持，我又不想去改 ORM 的底层，也不想让程序只能对应一个数据库
1. 不支持大小写不敏感的查询(citext 在参数化查询需要加强制类型转换提示,ORM 不方便，用不确定 collation 也有问题，譬如不支持 like ） 2.不支持事务嵌套（需要用 SavePoints 模拟，没有办法用通用的 ORM ） 3.不支持跨数据库、跨服务器的视图、引用。（用 dblink 效率比较低，ORM 也不方便用） |
 |
32
janus77 2020-08-22 15:41:07 +08:00
如果你爱折腾，多小的项目都能用
|
|
33
594duck 2020-08-22 16:46:36 +08:00
@PopRain
就第 2 个事务嵌套，postgres 的实现就是私有实现，和你的原则 不改 ORM 底层，不让程序只对应一个数据库的原则 是冲突的。 事务嵌套在任何数据库里都是不大推荐的做法，所以各家实现都有各家实现的不一样的细节方法。 |
 |
34
icerwinter 2020-08-22 23:13:44 +08:00
@594duck 这意思是说我国人口基数大，一批人耐不住不用产品了 终还是有另一波人使用？
哈哈 |
|
35
594duck 2020-08-23 08:47:56 +08:00 via iPhone
@icerwinter 人口基数大，所以试错成本低
|
 |
36
CantSee 2020-08-25 09:11:55 +08:00
只是用了最大努力通知的一个概念,没有用分布式事务!
|
 |
37
ksice 2020-09-01 15:36:33 +08:00
看业务场景而不是公司大小吧，有些场景可能必须要分布式事务
|
 |
39
dongfuye1 2021-11-12 21:32:21 +08:00
一般情况下的选择是：
设计上避免分布式事务>分布式数据库>分布式事务>定时任务补偿>人肉补偿 前三种方案要看你的业务和公司环境，在这三种当中选择一种合适的。最后两种开发成本、人工成本过高，而且特别容易出错，不建议采用 分布式事务也有很好用的框架，里面有很多文章，把相关的内容讲得很透彻，有兴趣可以看看 https://github.com/yedf/dtm |
 |
40
DreamStar 2023-04-25 10:42:07 +08:00
单表数据过多导致分库表产生的分布式事务->分布式数据库解决
业务上跨服务调用产生的分布式事务->最终一致性解决 总结来说, 分布式数据库要解决的分布式事务问题不等于全部分布式事务问题 |
Select Language