在数据库中采用乐观锁方式，从取出数据到写入数据中间有可能被改写，这种概率在高并发下应该不小吧，这种情况大家是怎么处理的。有没有更好的办法
乐观锁本质不是锁,而是Check And Set(检查,如果没有修改过,则写入).
比如基于数据库的会话存储系统:
UPDATE session SET content = 'serialize|json'
WHERE sessid = 1024 AND md5 = '0e5a8daed59d156faa3988e7ddb24e81';`乐观锁在不容易发生冲突的场合才高效,而高并发下冲突是很难避免的.
如果频繁发生冲突,导致操作失败,那处理一次请求的资源就白白浪费了.
其实操作失败也无所谓,给用户个提示就好了.
因为就算是传统的事务,也存在失败回滚的情况.
用户1支付50元购买了商品2:
SET AUTOCOMMIT=0
START TRANSACTION
UPDATE user SET coin=coin-50 WHERE id=1 AND coin>=50
UPDATE goods SET num=num-1 WHERE id=2 AND num>1
if( all_success ) { COMMIT } else { ROLLBACK }
SET AUTOCOMMIT=1如果商品库存不够,或者用户余额不够,这次购买的事务都会失败ROLLBACK.
这里的all_success表示两条UPDATE成功,各自受影响的行(affected_rows/rowCount)都是1行.
这种我用的独占锁。比如说秒杀抢购之类的。
你这种情况只可能出现在READ UNCOMMITTED的事务隔离级别,READ COMMITTED 就不会有这种问题
可以不使用数据库中的乐观锁或者悲观锁控制，使用程序实现。地址