题主你之所以会出现这么多问题，是因为你思路混乱，根本没搞清楚这些问题到底是怎么回事，并且得病后还自己乱下药。

1.【总有人恶意大访问量请求】，这是系统安全问题，你需要做的是防攻击。

2.【查询mysql去做重复验证在大并发上限制不住】：这是功能缺失。既然有缺失，就立即做新功能研发。

3.【总会有重复插入，会造成多发奖品】：这是已有系统的Bug，需要通过调试来修正问题。

综上，这些问题与redis有什么关系？

可以考虑crontab跑定时任务 执行php脚本去写入 或者跑守护进程去写

先简单的意淫一下题主的问题。

查询mysql去做重复验证在大并发上限制不住，总会有重复插入

我想题主这个原因主要是因为,需要把某些信息从数据库查出来,然后再比较,最后插入数据库吧?所以这里有可能出现脏读的问题。所以题主是否可以考虑一下实现方式,通过数据库的乐观锁来控制呢？

想用redis做mysql的缓存

题主用redis的原因,是因为有数据的重复插入,所以我想题主是想使用redis的原子操作吧?我觉得这个出发点不是很正确,不能因为直接使用数据库有重复数据,就使用redis。因为这个因果关系看上去有点蛋疼,我觉得首先得解决的是为什么会有重复数据插入。至于什么时候要用redis,应该是业务量(QPS)太大导致数据库撑不住才考虑使用缓存。

把redis的数据写回mysql

题主想隔断时间把redis的数据更新回mysql,利用@BUBBAK 的方法确实是可行的,通过一个定时任务,定时的把数据刷回数据库。但是假设,仅仅是假设,如果redis挂掉了,恰好数据没有刷回数据库,这就会造成数据丢失(这里并先不考虑redis的持久化)。
还有一种方式就是,直接修改缓存的数据,然后起一个单独的线程去修改数据库的数据,这样的好处就是如果缓存挂掉,数据库的数据还是可靠的,但是这样的缺点是,如果并发量很高,就会起很多子线程把缓存刷回数据库,这样对系统是有开销的而且会造成CPU的负载变高。

最后题主可以参考
如何设计高并发下的抽奖？下我的回答。
如果有什么其它的想法,大家可以一起再讨论讨论。

我感觉就是读脏数据的问题，楼主希望判断是否抽奖，抽奖逻辑，写抽奖表，这个过程中不能有第二相同用户来抽奖，实际上这个过程中，抽奖逻辑肯定要占大部分时间，至少要执行一次生成随机数的操作吧，在这个过程中，还没写表，所以其他请求读取数据库显示自己还没抽奖能够走抽奖逻辑。我的想法是第一步执行后加一个行锁，第三步执行后再释放这个锁，防止在这个过程中再有请求读取数据。本人愚见，若有错漏，望指点

redis中有个setnx()，这个操作是原子性的。首先可以通过在redis记录每个ip的请求时间，去判断该ip是否请求过快（这种形式又可能误伤，可能某个公司是同一个出口ip）。其次判断每个人是否抽过奖可以存在redis中啊，如果在redis中查不到该用户抽奖的标志就说明没有抽过奖，然后将该用户在redis中标记已经抽过奖了，然后在将该记录插入数据中即可。再说楼主这个只是在公司内部用，这种形式完全撑的住。

我有过类似的问题。我的解决办法是：

1. 用redis存储当前用户的session，包括ip,账号,电邮地址

2. 在表单里面, 根据当前用户的session，生成一个form的验证码(有时间戳),以type='hidden'的形式存在。

3. 在用户提交表单后:

   a) 先验证提交的隐藏验证码是否属于当前用户(不需要连接后台，根据已知的session来判定)
   b) 然后先搜索当前用户的session是否存在抽奖动作(不需要连接后台，根据已知的session来判定)
   c) 如果当前用户通过 a) 的验证后, 在 b)里面没有抽奖动作就证明该用户之前没有抽奖过,那么就添加一个抽奖动作为true. 如果当前用户通过 a) 的验证后,在 b) 里面有发现抽奖动作为true。就返回以抽奖页面。 也就是说c)跟b)是互相定义, 互相监督的。
   

4. 在通过3的验证后，再开始抽奖程序。

5. 在抽奖之后可以验证奖品存货量。（这一步可以在开始做，或者不做，看具体情况）

注意：

1. 个人来说不赞成锁定数据库，这样会让程序变慢，对大多数用户来说不友好。毕竟会有情况真的是大量真实的抽奖请求出现，锁定数据库会让效能大大降低。

2. 通过1，2，3的设置，可以屏蔽单IP短时间重复抽奖的问题。当然如果对方牛逼到能短时间内换IP+重复更换登陆用户+刷新页面生成不同的session,那你的程序绝对有重大逻辑错误,只能灭了重写了。

抽奖记录表的用户名称即openid和抽奖版本字段做一个uniqu唯一索引不就行了

1.读取抽奖表判断这个人是否抽过奖
2.如果表中有记录，那就是抽过了，直接告诉没机会
3.如果表中没有记录，走抽奖逻辑，然后插入抽奖表

你这里逻辑错了，应该是先执行向抽奖表的插入操作，抽奖表通过唯一索引限制每用户唯一，创建成功在执行实际的发奖动作，失败表示已经抽过奖了，直接返回已抽奖完事。

加 redis 缓存的话可以在 redis 里面增加用户是否已抽奖的标记，实际抽奖流程是：
1.检查 redis 是否有用户已抽奖的标志
2.在 redis 设置用户已抽奖标志
3.插入抽奖记录(通过唯一索引限制每用户唯一)，奖项为空
4.插入失败表示已抽过奖，插入成功表示可以抽奖
5.进行抽奖，写入中间结果，发奖

就用redis就行，在redis中存

KEY（用户唯一标识) ----> VALUE（0/1)
0： 未抽奖，1：以抽奖

只要

1. 判断KEY（用户唯一标识）的VALUE是0还是1

2. 是0返回，未抽奖，并赋值VALUE为1

3. 其他返回，以抽奖

以上3步是事务操作/原子操作，管你并发量破亿还是百亿，我们都吼得住。

假使有一个人同时发起了1000个请求1，2，3，...m...，999，1000。其中请求m略快一些被服务器先处理，m在执行上述3步时，其他999个只能眼巴巴的看着，因为是原子操作 等m被处理完了，其他999各只能看到1，即已抽过奖了

那么问题来了，在redis中如何实现上述3步的原子操作那？

答案是：redis的lua脚步，redis规定：redis的lua脚本的执行是原子性的

假使初始化时，所有用户的唯一标示对应的value都是0，下面给一个lua脚本实例

local uid = KEYS[1]
local res = 1
local isDraw = redis.call('get', uid)
if isDraw == 0 then
    res = 0
    redis.call('set', uid, 1)
end
return res

这里只是一个不成熟的简单例子，可以参考 http://www.redis.cn/commands/eval.html 这里看看具体该如何写，思路就是这样

PS：一定记得做好redis的备份工作，要不断电了，就悲哀了呀！！

https://segmentfault.com/a/1190000004136250

利用php redis简单抗高并发。另外，这种情况建议参考我的另一篇文章，防单ip恶意提交攻击，这个可以做个单ip限制。