你们会用乐观锁来防止并发冲突吗

127 天前
 ljzxloaf
并发冲突似乎是个大家都在谈,但是很少有人真的去当回事的东西。

典型的如 innodb 的 mvcc 就是用乐观锁的方式去处理并发冲突,你可以通过设置不同的隔离级别让 innodb 在检测到并发修改的时候选择不同的处理方式。

在业务开发中,当用户并发修改某条数据的时候,我们也可以通过类似的方式去防止或协调冲突。
那么问题来了,在实际工作你们真的去这么做了吗?如果没有这样实践的话是啥原因呢?就我个人的经验而言,好像很少有人真的这么干。
3322 次点击
所在节点    程序员
28 条回复
wangxin3
127 天前
个人愚见:
并发修改在 i++时会有问题,所以要考虑并发;
日常开发大多都是 i=?的问题吧,不存在冲突,后者覆盖 i 就行。
CEBBCAT
127 天前
有的不 ACID 要亏钱,也有的只是制造了一些小小的业务漏洞。看时间充裕与否吧。如果要我当下给出回答,我的解是:

从整体方案上减小冲突可能性,从扩展性上支持未来升级,从数据安全角度可回溯
emSaVya
127 天前
写业务的人不会牺牲自己服务的吞吐量 去考虑下游数据环节的问题。下游的问题交给下游 我不会在自己服务的主流程上加任何锁。
chippai
127 天前
从实际工作来讲还是很常用的,比如版本防并发修改、库存防超发等
samtofor
127 天前
一般在开发的时候不怎么用锁,需要用锁的时候也都是悲观锁,乐观锁基本没用过
ninjashixuan
127 天前
和钱相关的业务才会开始就考虑,其他的基本不会。
samtofor
127 天前
@samtofor 防喷,因为我接触的业务规模都不大,那么点用户量是不需要考虑乐观锁这种事情的
cheng6563
127 天前
加啊,开发框架集成,一个配置搞定,无形中避免了并发冲突,为何不加
byehair
127 天前
我的实际工作中,只要可能存在并发冲突的时候,在数据库层面我几乎都会使用乐观锁处理,但几乎很少使用悲观锁。
但是,但是,但是,
在数据库操作之前,我一般会使用其他手段,前置处理并发,比如使用 redis 做分布式锁、比如使用消息队列消费再写数据库等。

数据库层面使用乐观所或者悲观锁是我的最后一道防线,前置的分布式、内存锁、队列等都是为了从宏观上更高效的防止并发冲突。

一个不恰当的例子:
宇宙飞船是密封的,但是更保险的是穿上宇航服,因为有可能宇宙飞船被撞出一个洞,也可能宇航员要出仓执行任务,虽然有各种外层防御措施,但宇航服是最后一道防线。
NoobNoob030
127 天前
加,遇到有并发的要求的需求,顺手加一个很快
elonlee
127 天前
如果是分布式程序用 redis 同步锁,单体程序用可重入锁实现,数据库锁太重了,影响写入性能.
samtofor
127 天前
@helloluckydamon 赞同,大部分开发时候我都是避免使用数据库锁的,处理金钱相关的基本都是用 mq 的分区顺序来处理的,直接避免使用锁,实际用悲观锁的场景其实是在管理端,是用来防止几个人同时操作才写的,这种场景下悲观锁对于我的来说成本更低
Aruforce
127 天前
那么乐观锁前提下 是否需要重试以及 怎么对数据库的隔离级别有啥要求?
ljzxloaf
127 天前
@cheng6563 #8 啥框架?
diagnostics
127 天前
@samtofor #5 OP 说的乐观锁是应该是依赖数据库避免并发冲突的
ljzxloaf
127 天前
@samtofor #7 同一用户开两个客户端( app 、pc )就能触发了
zjsxwc
127 天前
多人操作、有版本差异需求的都要
watzds
127 天前
有些严格的会控制的,保证页面修改是基于最新内容,防止 A 把页面改了,B 基于 A 修改前的再修改,会把 A 的修改覆盖掉
lovelylain
127 天前
大部分都会,对于楼上说的保证页面基于最新内容防止覆盖,还会考虑实际成功但前端超时等原因误判后重试。
csys
127 天前
乐观锁是个很尴尬的东西,高并发高资源竞争下会放大压力
我觉得要么直接在上层用分布式锁,要么优化成无锁的设计

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1058045

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX