之前在一个微信公众号上做了一个抢京东券的功能， 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 中的数据存储到数据库当中去。
个人觉得这种方案会比第一种方案要好的多。但是没有真正意义上去实践过，只是个人思考的一个结果。
问题二：第二种方案是否可行？是否还有更优方案？或者说方案二是否有可以优化的地方？
问题三：在高并发时很多文章中说到的锁是一个怎样的概念呢？我的理解是这个锁就像是数据库的一个大门，一次只放一个人进去，是这样吗？具体该如何设计和使用？
问题四：在应对大流量高并发的情况时，在服务器层面要做哪些工作？
问题五：我所举得这个例子与平常类似网上商城中的秒杀功能有哪些相同和相异之处呢？是否可以按照方案二的设计思路进行设计呢？
我估计你的方案一是这样子的
select * from card where is_token=0 limit 1;
//有结果时，继续执行以下语句
update card set is_token=1 where id=xx;
insert into winner ...改进
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 ...方案二
可行。
因为你的业务逻辑比较简单，也可以使用redis的计数器
即当计数器 <=50 时按顺序一人领一张，通过计数器来过滤
问题三 锁
悲观锁(Pessimistic Lock)
顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
begin;
select * from card where is_token=0 limit 1 for update;
乐观锁
顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。参考改进后的方案一。
乐观锁用的比较多，使用redis的watch