在高并发下,怎样能给每个请求返回 100 条不重复的记录呢?

2017-01-05 21:03:21 +08:00
 dolee

mysql 初学者,有个问题请教各位老师

现在有个表里有 1000 万条记录,需要全部读取出来执行业务一遍。

(每次读取 100 条,每条记录只能被读取一次,查询过的记录修改 State 为 1 )

================

现在我用的是乐观锁,先用 php 从 mysql 读取出没执行过的最后 100 条记录

SELECT * FROM list WHERE State = '0' LIMIT 100

然后一条一条修改 State 改成 1 ,修改成功的,则是有效可用的,否则就是被其他线程抢先修改了

UPDATE list SET State = '1' WHERE Id='1' AND State = '0'

这样子,在并发低的情况下是挺好有的,但是在高并发下就不行了

因为同一时间查询的线程都是读取到的记录都是相同的,

通过乐观锁过滤掉重复的记录后,最后每个线程剩下的可用记录就少得可怜……

================

请问各位老师,怎样能在高并发访问的情况下,怎样能给每个请求返回 100 条不重复的记录呢?

(不一定能全返回 100 条,尽可能多就行)

8909 次点击
所在节点    MySQL
37 条回复
mifly
2017-01-05 21:13:02 +08:00
表增加一个字段 seq,每个线程先获取一个全局唯一序列,用这个序列,先 update seq 值为序列,然后再用这个序列作为条件查询

update 语句是行锁,能够防并发


或者你根据总记录,然后根据 id 大小分段给各个线程
akira
2017-01-05 21:16:31 +08:00
先吧 State = '0' 的对应 id 全部读取出来,然后自己程序分配到多个线程里面去处理?
est
2017-01-05 21:26:03 +08:00
改从 db pull 的模式为 db 主动向请求给 push 。
dolee
2017-01-05 21:27:57 +08:00
@akira 每次处理需要的时间很多,而且总记录数量还会增加,有没有办法在 读取记录的方法 上实现?
winnie2012
2017-01-05 21:29:17 +08:00
队列经典场景
dolee
2017-01-05 21:33:49 +08:00
@winnie2012 求大神指导
fyibmsd
2017-01-05 21:37:14 +08:00
redis 分布式锁
dolee
2017-01-05 21:37:28 +08:00
@mifly 总记录的数量还会增加,而且线程数量也不固定。
InnoDB 能不能锁定查询到的 100 条记录,不给后面的再查询到这 100 条记录呢?
gouchaoer
2017-01-05 21:50:08 +08:00
这个太简单了。。。 redis 里一个主键 int 初始值为 0 ,所有 php 进程 incr 那个 redis 的 int 值,拿这个值去数据库找到主键相等的记录处理,处理完了下一个。。。。不太建议用多线程, php-cli 下开多进程方法很多, linux 下最简单 pcntl , windows 下异步开 proc_open 吧
gouchaoer
2017-01-05 21:52:01 +08:00
这么说吧,遇到并发数据竞争第一个想到的应该是 redis ,因为 redis 天生单线程无竞争
stabc
2017-01-05 22:11:42 +08:00
可以考虑每次提取数据时用 limit 100 offset $offset, 这里的$offset 从 0-1000 随机。 1000 这个数值可以根据测试结果调整。
ddou
2017-01-05 22:27:30 +08:00
把业务场景讲讲清楚吧 大家看有没有更合理的解决方案
shibingsw
2017-01-05 22:47:33 +08:00
用悲观锁呢?比如先查询
select * from list where state = 0 for update limit 100;

然后再把 state 更新为 1.

如果同时有两个 process 同时查的话,只能有有个一人先返回,因为有锁。接下来先返回的人更新完,提交事物,由于那一百条的 state 已经变了,刚才等待的 process 就能拿到下面的 100 条。
realpg
2017-01-05 22:51:43 +08:00
SELECT FOR UPDATE

先 UPDATE 至中间值

方法多了去了

楼主的 MYSQL 根本没达到入门水平
Lax
2017-01-05 22:55:56 +08:00
改下 sql ,貌似不需要多线程:
update table set state = 1 where stat = 0
性能跟表结构还有关系,而这里看不到你的索引情况。

或者继续用多线程: 1000w 条记录, N 个线程,把数据分成 N 个区,每个分区给且只给一个线程去处理。
Lax
2017-01-05 22:59:35 +08:00
理解有误。继续多线程按 id 分区吧。
kimwang
2017-01-05 23:07:14 +08:00
搭车问一下,直接 SELECT 会不会效率低?好像很多框架或者案例都是把增查改删语句实例化,然后再查询?
我也是学习 PHP+MYSQL 中。
dolee
2017-01-05 23:29:11 +08:00
谢谢大家!
看到大家的热心解答,受益良多!

现在正在学 redis ,打算用 redis 解决,比较长远又效率

在 segmentfault 也收获另一个不错的解决方案,具体如下:
加个字段 pid , UPDATE 的时候,顺便把这 100 条数据打上进程的标记:
'UPDATE `list` SET `State` = '1', `pid` = ' . getmypid() . ' WHERE `State` = '0' LIMIT 100;'
锁定了之后,再:
'SELECT * FROM `list` WHERE `pid` = ' . getmypid() . ' LIMIT 100'
来拿到这 100 条数据
ihuotui
2017-01-05 23:36:28 +08:00
其实思考方向先分区在处理,在多线程情况下分区执行才是效率最高的,像 currenthashmap 那样,没有冲突的多线程编程才是性能最好的,而且分区后就不用处理 sql 冲突问题, sql 执行冲突解决这么麻烦。在单机情况下可以用原子类或者 volitaion 类同步信息的,然后分布式情况下就是控制每台机器的段,达到每台机器都是平均段落, A , 0 到 4999 , B , 5000 到 9999 ,依次这样达到并发最大效率。把复杂问题简单化,而且达到切到好处。
ETiV
2017-01-06 00:28:31 +08:00
每条数据只输出一次,那就提前把 1000 万条数据分好组(每组 100 条),然后每组对应一个自增 id 。

请求进来后,先去 redis 拿一个自增的编号,再去数据库拿跟编号对应的分组 id 的那组。

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

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

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

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

© 2021 V2EX