在高并发下,怎样能给每个请求返回 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 条,尽可能多就行)

8910 次点击
所在节点    MySQL
37 条回复
yidinghe
2017-01-06 00:40:42 +08:00
我觉得这等同于 10 万条记录每次取一条,不重复。
Miy4mori
2017-01-06 02:11:57 +08:00
@kimwang 你觉得你的程序可以不通过 SQL 直接查询数据库的数据吗,包装一层 API 再用生成 SQL 查询效率高还是直接使用手动优化过的 SQL 效率高?当然都没有存储过程效率高。
Miy4mori
2017-01-06 02:17:32 +08:00
都在考虑即时的方案,我来给你讲个非主流的,在插入数据的时候预先分组或者定期对没有分组的数据分组,然后查询的时候直接通过分组表和你的数据表关联查询,标记业务完成状态也标记分组表。简单粗暴,就是实时性不高,不过你这种定期统计类似的需求貌似也不需要太高的实时性。还有一个问题就是事务控制要稍微麻烦点。
shiny
2017-01-06 02:55:16 +08:00
楼上分组的思路好。预先分组,每次查询自增一个分组 ID ,性能绝对好。
cnwtex
2017-01-06 03:01:27 +08:00
MySQL 有 select random ( 100 )
chuhemiao
2017-01-06 10:22:28 +08:00
@cnwtex 不是说用函数效率会很低?
hdlove
2017-01-06 10:39:17 +08:00
使用 redis 分布式锁,先取出 100 条,进行循环 ,设置传入单独标示,单独的 key,加 数据库一个不重复的值,再设置过期时间,可以上网上搜下类似相关的文档,一套你就明白了
xpresslink
2017-01-06 11:17:31 +08:00
这个明显要用 producer 和 consumer 模式,一个线程专门做 producer 从数据库里取数据,每次批量一 100 条放到队列里。其它开 N 个 consumer 线程分别从队列里取每次取 100 条云处理。
jianzhiyao020
2017-01-06 11:18:46 +08:00
1.ID 分组,调起不同线程的时候,确定线程负责的 ID 范围
2.利用生成者生成 ID 范围的队列,消费者直接根据获得的 ID 范围自己撸
realpg
2017-01-06 12:13:04 +08:00
@dolee
你 18 楼这个 UPDATE 就是我说的中间值法的变种
用 redis 啥的徒增一层逻辑没必要
sbugzu
2017-01-06 14:52:48 +08:00
如果 ID 是自增的或者有序的,直接通过 ID range 对每 100 个分组从数据库取数( a 可以用一个集中的分组程序或者 Redis 一类来实现分布式锁。 b 再简单点按线程数不同线程使用不同的步长),上面直接 limit 的同学数据量大了必然出现深翻页的性能问题。
dolee
2017-01-09 02:45:21 +08:00
@realpg
用这个方法测试了两天,效率提高了很多,但是还是不够……
并发量太大, MYSQL 压力还是很大,很容易挂掉……

另外数据量不是固定 1000W 的,每天还会增加 100W 左右
如果用 Redis 效率应该会更高吧^_^
dolee
2017-01-09 02:46:15 +08:00
感谢大家的热心解答~
现在已经有解决的思路,谢谢大家
dolee
2017-01-09 02:48:11 +08:00
@cnwtex 之前也用了随机数,但性能很不好呢,高并发下查询一次基本要数十秒,后面就舍弃了
realpg
2017-01-09 09:58:00 +08:00
@dolee
主要是你们 DBA 的问题
查询没有统一规划吧
锁问题,内存问题都没有统一协调

我说一下我的场景
一个巨大的票务系统,每一个座位就是一条记录,峰值时候一天增加 300GB 新席位数据(不是同一个表,分表)同时删除 300GB 过期数据(热查询数据库删除,备份数据不删除)

当你在网站上订 N 张票时候,随机将 N 个符合筛选条件的席位的 state 从 0 改为 1[占用]( update 至中间变量获取占用数,因为有可能要 3 张票只有 2 张需要获取数量,然后再修改 state 为 1 )

在我这个规模的数据下,单纯使用特殊布置的四 MYSQL 负载均衡系统, MYSQL 并不会造成挂掉(很庞大的在线用户量的大系统)
beny
2017-01-09 11:42:27 +08:00
@akira 你这样把机器搞挂了
akira
2017-01-09 21:18:45 +08:00
@beny 怎么说

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

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

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

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

© 2021 V2EX