关于抢京东券高并发的问题?
之前在一个微信公众号上做了一个抢京东券的功能, 50 张京东券,面额 50 、 100 不等,存在一张 card 表中,四个字段, id , number , money , is_taken 。
因为之前没有这种高并发处理的经验,所以使用了一种最传统的方式来实现:
方案一:来一个人我就从数据库中取一张京东券出来给他,并将该京东券标记为已使用(即更新 is_taken 字段),并将该用户插入到 winner 表中
这个方案最终导致的悲剧是,有一张京东券被两个人领取到了。
我所理解会出现这个问题的原因是获取未被占用的京东券数据( select )和更新该条京东券数据( update )是两个独立的操作,在这两个操作之间存在时间间隔,例如 A 用户刚得到了一张 100 元的京东券,还未来得及更新, B 用户涌入查询到这张京东券未被使用,所以 B 用户也获得了这张京东券。
问题一:我这个理解是正确的吗?还是有更深入的原因?
出了这个问题后,我在网上查找关于高并发相关的资料,几乎都提到了队列和锁。就我个人了解队列可以使用 redis 或者 memcacheq(这个没用过,不熟悉),所以自己想了第二种方案。
方案二:事先将京东券 id 数据压入到 redis 的 list 中,每过来一个有效的用户,就 pop 一个 id 给他(当 pop 出来的数据为空时说明京东券已经被抢光),并将用户 id 与京东券 id 的对应关系存储到 redis 的 set 当中去,然后根据这个 id 来查找京东券数据,显示给用户京东券的面额,并将 set 中的数据存储到数据库当中去。
个人觉得这种方案会比第一种方案要好的多。但是没有真正意义上去实践过,只是个人思考的一个结果。
问题二:第二种方案是否可行?是否还有更优方案?或者说方案二是否有可以优化的地方?
问题三:在高并发时很多文章中说到的锁是一个怎样的概念呢?我的理解是这个锁就像是数据库的一个大门,一次只放一个人进去,是这样吗?具体该如何设计和使用?
问题四:在应对大流量高并发的情况时,在服务器层面要做哪些工作?
问题五:我所举得这个例子与平常类似网上商城中的秒杀功能有哪些相同和相异之处呢?是否可以按照方案二的设计思路进行设计呢?
回复内容:
之前在一个微信公众号上做了一个抢京东券的功能, 50 张京东券,面额 50 、 100 不等,存在一张 card 表中,四个字段, id , number , money , is_taken 。
因为之前没有这种高并发处理的经验,所以使用了一种最传统的方式来实现:
方案一:来一个人我就从数据库中取一张京东券出来给他,并将该京东券标记为已使用(即更新 is_taken 字段),并将该用户插入到 winner 表中
这个方案最终导致的悲剧是,有一张京东券被两个人领取到了。
我所理解会出现这个问题的原因是获取未被占用的京东券数据( select )和更新该条京东券数据( update )是两个独立的操作,在这两个操作之间存在时间间隔,例如 A 用户刚得到了一张 100 元的京东券,还未来得及更新, B 用户涌入查询到这张京东券未被使用,所以 B 用户也获得了这张京东券。
问题一:我这个理解是正确的吗?还是有更深入的原因?
出了这个问题后,我在网上查找关于高并发相关的资料,几乎都提到了队列和锁。就我个人了解队列可以使用 redis 或者 memcacheq(这个没用过,不熟悉),所以自己想了第二种方案。
方案二:事先将京东券 id 数据压入到 redis 的 list 中,每过来一个有效的用户,就 pop 一个 id 给他(当 pop 出来的数据为空时说明京东券已经被抢光),并将用户 id 与京东券 id 的对应关系存储到 redis 的 set 当中去,然后根据这个 id 来查找京东券数据,显示给用户京东券的面额,并将 set 中的数据存储到数据库当中去。
个人觉得这种方案会比第一种方案要好的多。但是没有真正意义上去实践过,只是个人思考的一个结果。
问题二:第二种方案是否可行?是否还有更优方案?或者说方案二是否有可以优化的地方?
问题三:在高并发时很多文章中说到的锁是一个怎样的概念呢?我的理解是这个锁就像是数据库的一个大门,一次只放一个人进去,是这样吗?具体该如何设计和使用?
问题四:在应对大流量高并发的情况时,在服务器层面要做哪些工作?
问题五:我所举得这个例子与平常类似网上商城中的秒杀功能有哪些相同和相异之处呢?是否可以按照方案二的设计思路进行设计呢?
我估计你的方案一是这样子的
<code>select * from card where is_token=0 limit 1; //有结果时,继续执行以下语句 update card set is_token=1 where id=xx; insert into winner ...</code>
改进
<code>select * from card where is_token=0 limit 1; //有结果时,继续执行以下语句 update card set is_token=1 where id=xx and is_token=0; //获取影响行数,为0则失败,否则执行 insert into winner ...</code>
方案二
可行。
因为你的业务逻辑比较简单,也可以使用redis的计数器
即当计数器
问题三 锁
悲观锁(Pessimistic Lock)
顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
<code>begin; select * from card where is_token=0 limit 1 for update; </code>
乐观锁
顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。参考改进后的方案一。
乐观锁用的比较多,使用redis的watch

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











PHP 8.4는 상당한 양의 기능 중단 및 제거를 통해 몇 가지 새로운 기능, 보안 개선 및 성능 개선을 제공합니다. 이 가이드에서는 Ubuntu, Debian 또는 해당 파생 제품에서 PHP 8.4를 설치하거나 PHP 8.4로 업그레이드하는 방법을 설명합니다.

CakePHP는 PHP용 오픈 소스 프레임워크입니다. 이는 애플리케이션을 훨씬 쉽게 개발, 배포 및 유지 관리할 수 있도록 하기 위한 것입니다. CakePHP는 강력하고 이해하기 쉬운 MVC와 유사한 아키텍처를 기반으로 합니다. 모델, 뷰 및 컨트롤러 gu

CakePHP에 로그인하는 것은 매우 쉬운 작업입니다. 한 가지 기능만 사용하면 됩니다. cronjob과 같은 백그라운드 프로세스에 대해 오류, 예외, 사용자 활동, 사용자가 취한 조치를 기록할 수 있습니다. CakePHP에 데이터를 기록하는 것은 쉽습니다. log() 함수는 다음과 같습니다.

VS Code라고도 알려진 Visual Studio Code는 모든 주요 운영 체제에서 사용할 수 있는 무료 소스 코드 편집기 또는 통합 개발 환경(IDE)입니다. 다양한 프로그래밍 언어에 대한 대규모 확장 모음을 통해 VS Code는

CakePHP는 오픈 소스 MVC 프레임워크입니다. 이를 통해 애플리케이션 개발, 배포 및 유지 관리가 훨씬 쉬워집니다. CakePHP에는 가장 일반적인 작업의 과부하를 줄이기 위한 여러 라이브러리가 있습니다.
