这是一个创建于 882 天前的主题，其中的信息可能已经有所发展或是发生改变。
我现在有一个菜单 menu
有这么一种并发的操作情况：
- 用户 A 往 menu 中增加内容 content ，同时用户 B 在删除 menu ，如果 B 先成功，那么 A 新增的 content 就变成了孤儿。
我目前想到的解决办法有两种：
- 使用 redission 分布式锁锁住 menu ，但是这样同一个 menu 下的操作会变慢，另外：多人同时往菜单下增加内容的这种无冲突操作也受到影响了
- 使用乐观锁机制，往菜单表中加一个 version 字段，AB 两者每次操作都更新菜单的 version：update version=2 where version=1 ，但是这样其中一个人的操作会报错“数据已更新，请刷新页面”，刷新页面会让前端拿到新的 version ，但是对用户不友好
所以想请教大家一般是怎么处理这种菜单的并发问题呢？
 |
1
timethinker 2022-06-23 18:47:39 +08:00
没明白你说的对用户不友好是啥意思，往一个已经删除的关联数据增加新的数据，按理说应该失败并告知原因，例如不存在 menu ，除此之外还能怎么做呢？可以吞掉这个错误，就当请求没发生，或者正常插入脏数据？
数据已被删除是一个事实，优化的方案也可以当有用户编辑 menu 的时候不允许删除，这取决于想要的逻辑是什么。 回到正题，解决这个并发问题最简单的方法就是使用乐观锁，或者直接使用独占锁（ SELECT ... FOR UPDATE ）。如果是独占锁，当你在进行操作的时候（新增 content ），别人是没办法查询或者修改这个 menu 的。当完成操作，另一个试图删除 menu 的时候，走正常的删除逻辑。 |
 |
2
TWorldIsNButThis 2022-06-23 19:13:18 +08:00 via iPhone
我用的是 2
配合 retry |
 |
3
Saxton 2022-06-23 20:17:35 +08:00 via iPhone
数据库的事物+锁已经足够了
|
 |
4
renmu123 2022-06-23 23:54:30 +08:00 via Android
什么场景会有两个用户同时编辑一个菜单，就算有一般也是 b 端的吧。
又不是不能用.jpg 两人自己沟通去 |
 |
5
hidemyself 2022-06-24 08:07:40 +08:00
我也是用 2
|
 |
6
sujin190 2022-06-24 09:26:49 +08:00
其实是不是想太多了，且不说同一个 menu 能被几个人操作啊，就算真的多现实情况下同时操作又有多大概率，直接加锁顶多慢几百毫秒而已，这真的不算个啥，还是别过度设计啊，如果并发冲突直接加锁超过 20%慢超过 5 秒以上，我觉得还有价值用 2 乐观锁加自动重试就行，否则除了增加不稳定因素和复杂度真的毫无优化的必要
|
 |
7
night98 2022-06-24 10:19:45 +08:00
直接加锁，菜单操作是个低频率的操作，冲突概率极低
|
 |
8
gitdoit 2022-06-24 16:41:45 +08:00
不要过度设计，编辑菜单是低频操作，直接乐观锁就行了。就算发生你说的那种冲突，你觉得你在代码里能做什么呢
|
 |
9
cp19890714 2022-06-24 20:41:04 +08:00 via Android
基本就是这两种方案。根据功能的具体使用情况，来选择用哪个方案。区别的关键在于，用户对菜单删除的操作，和菜单下添加内容的操作，哪个更频繁。如果删除操作更频繁，就使用悲观锁，如果添加内容更频繁，就使用乐观锁。
|
 |
10
fov6363 2022-06-24 21:37:35 +08:00
类型读写锁的思路：增加拿锁 1 ，删除拿锁 2 ，锁 1 与锁 2 互斥，锁 1 可同时存在多个，锁 2 只允许存在一个
|
Select Language