2. V2EX
  3. 请教大家一个后端菜单功能的实现问题

请教大家一个后端菜单功能的实现问题

dumbbell5kg3天前0

我现在有一个菜单 menu

有这么一种并发的操作情况：

用户 A 往 menu 中增加内容 content ，同时用户 B 在删除 menu ，如果 B 先成功，那么 A 新增的 content 就变成了孤儿。

我目前想到的解决办法有两种：

使用 redission 分布式锁锁住 menu ，但是这样同一个 menu 下的操作会变慢，另外：多人同时往菜单下增加内容的这种无冲突操作也受到影响了使用乐观锁机制，往菜单表中加一个 version 字段，AB 两者每次操作都更新菜单的 version：update version=2 where version=1 ，但是这样其中一个人的操作会报错“数据已更新，请刷新页面”，刷新页面会让前端拿到新的 version ，但是对用户不友好

所以想请教大家一般是怎么处理这种菜单的并发问题呢？


上一篇：咨询下各位网友，网卡代码 48 了如何恢复？
下一篇：看到无敌的变量命名，还有超越的吗？
最新回复 (7)
  • 引用2楼
    没明白你说的对用户不友好是啥意思，往一个已经删除的关联数据增加新的数据，按理说应该失败并告知原因，例如不存在 menu ，除此之外还能怎么做呢？可以吞掉这个错误，就当请求没发生，或者正常插入脏数据？
    数据已被删除是一个事实，优化的方案也可以当有用户编辑 menu 的时候不允许删除，这取决于想要的逻辑是什么。
    回到正题，解决这个并发问题最简单的方法就是使用乐观锁，或者直接使用独占锁（ SELECT ... FOR UPDATE ）。如果是独占锁，当你在进行操作的时候（新增 content ），别人是没办法查询或者修改这个 menu 的。当完成操作，另一个试图删除 menu 的时候，走正常的删除逻辑。
  • 引用3楼
    我用的是 2
    配合 retry
  • Saxton3天前
    引用4楼
    数据库的事物+锁已经足够了
  • renmu1233天前
    引用5楼
    什么场景会有两个用户同时编辑一个菜单，就算有一般也是 b 端的吧。
    又不是不能用.jpg 两人自己沟通去
  • hidemyself2天前
    引用6楼
    我也是用 2
  • sujin1902天前
    引用7楼
    其实是不是想太多了，且不说同一个 menu 能被几个人操作啊，就算真的多现实情况下同时操作又有多大概率，直接加锁顶多慢几百毫秒而已，这真的不算个啥，还是别过度设计啊，如果并发冲突直接加锁超过 20%慢超过 5 秒以上，我觉得还有价值用 2 乐观锁加自动重试就行，否则除了增加不稳定因素和复杂度真的毫无优化的必要
  • night982天前
    引用8楼
    直接加锁，菜单操作是个低频率的操作，冲突概率极低
  • 游客
    9楼
返回
发新帖
精彩推荐