十点太晚了，比 996 还累，而且 go 没经验

这么多人，人效估计挺低，恐怕分不到钱吧

@xmh51 嗯，如果除了扣除数据，还要记录扣款前后数量的话

阿里落后的面试流程，方式

这也是个行业啊，虽然我鄙视这个行业，也鄙视你

@lhx2008 #17
嗯，查了一下 commit 成功，但是返回给客户端失败的情况，应该没有标准处理，不过也极少发生，oracle 倒是有一些机制 Transaction Guard
https://dba.stackexchange.com/questions/215579/what-happens-if-the-database-nodes-network-fails-just-after-commit-and-before-r?newreg=e21a89d0f6e3489b85a0a4e99ba08c6b

@bowie #21 是的，只保证不会被扣负，不过什么余额、库存业务场景，不被扣负还不够呢？这个经验不多，能举些实际例子吗
只扣个余额， 要是用 select for update 或者乐观锁，是否 overkill

@tianshilei1992 佩服

@iffi #16 如果是 for update 这种悲观锁，性能影响应该是挺大的，不过这种扣减方式性能和乐观锁会有差别吗？

UPDATE stock SET amount = amount - $diff WHERE id=$id AND amount>$diff;

@lhx2008 #12 这个 sql 并没有并发问题，是能保证正确的，因为 UPDATE 是当前读，会加行数

UPDATE stock SET amount = amount - $diff WHERE id=$id AND amount>$diff;

@lhx2008 #11 这个我有一点疑问，如果是 commit 发往 数据库，数据库收到了也提交了事务，但是应用没收到网络响应，连接断了，不知应用是怎么处理的，是会超时异常，还是重新建立连接后再次向数据库查询事务是否提交？

@xuanbg #5 哦，那你是觉得一般应该用 UPDATE stock SET amount = amount - $diff WHERE id=$id AND amount>$diff; 而不是乐观锁是吗？其实我是这么觉得，只是看网上书上都说乐观锁方式比较多

@xmh51 #8 假如需要拿到余额，做一下相关操作之后，再扣款，那乐观锁其实是替换了 for update 倒是有意义的
比如要求余额是素数才能扣款，那只能 for update 或者乐观锁了

不过一般余额足够就行，我没想到那样的业务场景

所谓乐观锁是这种方式：UPDATE t_yue SET money=38, version=$version_new WHERE uid=$uid AND version=$version_old

@xuanbg #1 所谓乐观锁方式和下面这种不都会有行锁吗，索引正确情况
UPDATE stock SET amount = amount - $diff WHERE id=$id AND amount>$diff;

大二就懂这么多啊，就做项目还赶着，像是工作压力一样，

我 C++学了多年，还是找了 java 工作
你不如多学学 Go 和相关生态，不好吗

不难，我单机一个 for 循环也能亿级流量