我现在事先拥有1万个激活码，要求用户请求(能拿到用户id)时，从这1万个激活码抽出一个给用户，每个用户最多只能拿到1个。
我现在的设计是这样的：
用redis存储这个1万个激活码的id（主键自增，从1到1万），当用户请求时，从redis中拿出一个id。利用redis的原子性，可以保每个请求拿到的都是不同的激活码。
然后根据id到mysql里查到这个激活码，状态置为“已发放”，同时在记录表里添加“用户id，激活码id”的记录，再把激活码实际内容返回给用户。这样用户每次请求，先查下记录表有没有这个用户记录，有的话就表示抽过了返回提示信息，没有的话就抽取激活码返回给用户。
本来我以为没问题的，却发现实际上记录表出现了1个用户拿到2个激活码的情况，这2条记录都是同一秒生成的。我猜测可能是这样的：某个用户发出了2次请求，这2次请求的时间间隔非常小，所以导致第2次请求检测记录表记录时，第一次请求的“插入记录表操作”还没完成，导致2次请求都通过了。
请问是这个原因么？要保证一个用户最多只能拿到一个该怎么做呢？
用户操作加锁就可以:)
在对db等进行操作前. 根据用户信息例如 account 生成md5 key 查询在memcache中是否有值 不存在key 则set 完成db插入等操作 del掉key
为什么不先把"用户id，激活码id"的记录也先存在redis呢?
使用一定的算法，根据用户ID生成对应的激活码，然后入库。
保证唯一，而且不会重复。
这样怎么样
客户端提交一次后在收到返回值之前不可操作。
一定要callback才解锁
如果是不小心被点击了两次的话，那为什么不用JS限制只可以点击一次呢？或者是在提交的时候生成一个唯一的 token 呢？
这不是可以解决了吗？
直接在redis中存邀请码的消耗情况不行么?
在插入mysql的时候再做一次验证