关于抢京东券高并发的问题

之前在一个微信公众号上做了一个抢京东券的功能， 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 中的数据存储到数据库当中去。

个人觉得这种方案会比第一种方案要好的多。但是没有真正意义上去实践过，只是个人思考的一个结果。

问题二：第二种方案是否可行？是否还有更优方案？或者说方案二是否有可以优化的地方？

问题三：在高并发时很多文章中说到的锁是一个怎样的概念呢？我的理解是这个锁就像是数据库的一个大门，一次只放一个人进去，是这样吗？具体该如何设计和使用？

问题四：在应对大流量高并发的情况时，在服务器层面要做哪些工作？

问题五：我所举得这个例子与平常类似网上商城中的秒杀功能有哪些相同和相异之处呢？是否可以按照方案二的设计思路进行设计呢？