一个高并发架构问题，求指点

[Jinnrry]

目前我们在做一个审核后台，每天早上运营需要领取任务。领任务逻辑大致这样

// 1、先取数据
select * from data where status = xxx limit 50


// 2、写入任务表
insert into task .......



// 3、修改数据状态

update data set status = xxx where xxxx

但是！这样有个缺陷，如果多个人同时点领取，那么可能导致多个人领到同一条任务。目前想到的解决办法： 1、把这个操作写成一个事务，然后使用 serializable 隔离级别，保证每次只执行一个 2、把分任务的操作单独出来做出一个服务，使用单线程实现，保证每次只处理一个人的领取

但是这 2 种方法好像都有点影响性能，虽然我们后台没什么关系，但是本着对技术的追求，想来问问各位大佬，有没有什么更好的解决方案？

[yufeng0681]

方案 1：一楼时候的队列，消息队列，MQ，谁取出来，谁消费； 统一生产（将需要处理的任务放进 MQ ）
方案 2：第一步先进行 update，将运营 xxx 要处理的数据更新为 xxx 占用了；第二步查询的时候，多带一个角色的字段去查询 ，xxx 要处理的工作， 第四步更新时，将 xxx 也清除掉，表示任务完成。

[vindurriel]

处理高并发的思路在改串行 用单线程或锁都可以 推荐单线程因为开销少 锁的引入还可能需要额外的依赖 比如 redis

非要加锁的话 高并发写的情况推荐悲观锁 提前碰撞

如果串行的吞吐量不够 需要加并行 对数据分区 比如多条消息队列 多个 topic 最土的办法是 mysql id mod N

[helloSpringBoot]

2、3 放到事务里面，3update 的时候加个 status 作为 where 的条件
update count = 1：成功，提交事务
update count = 0：失败，回滚

[mnssbe]

你这个是并发问题， 不是高并发问题

[hxtheone]

看并发量吧, 并发量小单数据库直接乐观锁搞定, 多库量大就分布式锁或队列