因为要做流水, 所以得先查询余额再做加减
语言 golang, 数据库框架 GORM
语言 golang, 数据库框架 GORM
This topic created in 1786 days ago, the information mentioned may be changed or developed.
 |
thinkershareDec 13, 2021
1
开启事务, 按照需求选择乐观或者悲观并发策略. 或者考虑 EventSourcing
|
 |
YoockDec 13, 2021
2
并发量是多大？
|
 |
niubee1Dec 13, 2021
3
那要看你是在单节点实现高并发还是多节点实现高并发，如果都交给数据库那就开事务，用数据库去解决一致性问题，但是性能不容乐观，如果要多节点实现高并发，那么分布式事务的 CAP 问题，要么用现成的分布式事务方案，要么自己实现 2 阶段提交（ 2PC ）或者 3 阶段提交（ 3PC ），或者更近一步实现 Paxos 算法。这个问题很多现成方案，真没有必要自己再想当然的搞一套了，因为 CAP 三个问题你只能搞定其中两个，别自出机杼了
|
 |
7
我没用事务也是直接 Golang 互斥锁，因为我们业务关系所以一直都是 3k 人左右具体看学校新生多不多.....然后我没人分配了一把锁....好处是他不用二次刷卡，不用返回错误，就相当于加个高级点的行锁.....而且基本也就等个 100-200ms 就好了，内存之前单独写了个 main 测试过好像整体占用就 17M 左右...坏处是没有骚操作，在其他人面前没得吹......但是稳就行....另可慢几百毫秒也不可错一分
|
1 |
dayeye2006199Dec 14, 2021
8
最简单就是交给数据库去处理事务
数据库事务设计出来就是处理这样的业务场景的，为啥大家第一反应想不到用它呢？ |
 |
10
加上版本号，读出来后带上金额一起更新。如果 miss 就是有新版本，再次读。那还可以把这个版本号写入日志。
update account set money += 5, version = 2 where id=1 and version = 1 |
 |
xuanbgDec 14, 2021
11
如果在代码逻辑中先读出余额再加减，那么数据库事务的隔离级别就很关键，而且可能需要分布式锁。如果直接在 sql 更新语句中加减，那就不需要事务。
|
 |
securityCodingDec 14, 2021 via Android
12
有 redis 集群吗？ 用 lua 来做，数据库异步落地
|
 |
dooonabeDec 14, 2021
13
update table set price = price - #{x} where price >= #{x}
|
 |
chenzheyuDec 14, 2021
14
对待钱的问题，宁肯慢也要保证不错
|
 |
timethinkerDec 14, 2021
15
|
 |
justRuaDec 14, 2021
16
版本号实现乐观锁，自旋一定次数（比如 10 次），超过十次未更新成功就是失败
|
 |
BigMountainDec 14, 2021
17
涉及金额的强一致不应该用 Redis 来保证的
|
 |
Joker123456789Dec 14, 2021
18
并发问题就是加锁，没别的
|
 |
back0893Dec 14, 2021
19
加锁..最简单
|
 |
pengtdydDec 14, 2021
20
分布式锁
|
 |
MoYi123Dec 14, 2021
21
update money_table set money = money + 100 where id = 1 returning money - 100;
用 PostgreSQL 的 returning,可以一句 sql 完成查询和修改 Mysql 也有类似功能,不过比较麻烦. |
 |
akriafly01Jan 16, 2022
22
乐观锁 ➕ 自旋重试
|
Select Language