php redis做mysql的缓存,怎么异步redis同步到mysql数据库?

公司做抽奖或者红包活动,总有人恶意大访问量请求,查询mysql去做重复验证在大并发上限制不住,总会有重复插入,会造成多发奖品。
想用redis做mysql的缓存,但是现在遇到的问题是如何把redis的数据写回mysql,不可能每次校验的时候就写回mysql,那样的话根本没有解决问题。
现在的想法是能否利用php,或者其他什么技术,定时将redis中的数据写回mysql。程序只与redis交互。
希望能给出具体的逻辑或者解决方案,网上的回答都太笼统了,根本解决不了问题。

谢谢。

1月16日补充:
我问题描述的不太清晰。
我把遇到的问题详细的说一下吧,并不是发奖时候脏读的问题,而是判断这个人是否有机会抽奖。
有一个抽奖的表,如果这个人抽过奖了,就在表中插入一条记录。
目前的实现方式是:

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

正常情况下是没有问题的,
但是有人用恶意脚本进行刷奖,也就是同一个人发起大量请求,1秒可能一两百的请求甚至更多,而且不只一个人刷奖。
问题出在1这一步
举个例子,假设每人只能抽一次奖,因为请求太快,同一人的a,b两个请求几乎同时来,a走完抽奖逻辑了,并且在抽奖表中插入记录的过程时,因为mysql的性能的问题,b去走1这一步是读不到表中的记录的,因为a的插入根本没有完成。所以b请求会再走一次抽奖逻辑。造成同一人抽奖两次,然后再插入抽奖表。
我关心的是能否a插入抽奖表的瞬间,b就能判断出抽奖表有数据。
所以我觉得问题是mysql写入的不够快,读取的不够快,所以我要采用redis做一层快速缓存。
我们做的抽奖是单一奖品百分之百中奖,只限制奖品数量,所以必须保证每人只能抽一次,而且尽量在程序层面去解决。


1月20日补充
看了大家的回答很受启发,非常感谢。
至于有人提到并发没想象的那么大这件事,是这样的,我们的服务器是阿里云单台的ECS,配置4核8G 独享50m宽带,centos,只做对外活动。
12月24号上线的一个活动
这是12月24号上线的一个不到4小时活动的抽奖活动的浏览量。

TCP连接数监控
这是当时TCP连接数的监控

抽奖不同于网站访问,这些参与者基本绝大多数是同一时间段来访问服务器。我个人觉得在服务器配置不升级的情况下,软件层面的优化完全能扛住这些访问。我目前觉得瓶颈在mysql。

阅读 29.8k
25 个回答

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

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

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

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

综上,这些问题与redis有什么关系?

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

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

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

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

想用redismysql的缓存

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

redis的数据写回mysql

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

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

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

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

  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,那你的程序绝对有重大逻辑错误,只能灭了重写了。

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

抽奖记录表的用户名称即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的备份工作,要不断电了,就悲哀了呀!!

1.看一下数据,日均流量和峰值流量,不要有迫害妄想症,真是每次搞活动都被人搞的话,呵呵,恭喜了,你们是下一个阿里巴巴。
2.平时有没有反作弊、限流机制,策略是啥,对你解决这个问题有无帮助?
3.为啥用Redis不是memcache之类的?你要用Redis的队列?丰富的数据结构?还是备份?请忽略上面提到的crontab...
4.mysql写入、读取不够快...,你这个结论怎么得出的,预估的每秒读取、写入请求多少?

可以使用memcache的独占锁

简单点就加锁,虽然会损失点性能

我这边是用redis锁,加一个记录,生存时间5秒,同一用户5秒请求1次. 进来就检测,如果没到时间直接返回一个提示消息就行了.
redis可以保证操作是原子性的,memcache不能.既然已经用了redis,那正好用下去就行了.

我觉得读写都可以在 Redis 中进行,使用 Redis 来维护这个『抽奖记录』。后台使用定时程序(最好不要用 crontab,自己使用定时器更好,有异常也可以有记录、报警),定期将 Redis 的数据备份、存储。此时,要不要入 MySQL,看具体业务上的需要了。

如果对数据可靠性要求很高,或者单表数量非常高,也可以考虑直接使用 MongoDB 来存储这个『抽奖记录』。使用 MongoDB Sharding 的话,10亿条记录以下基本问题不大。而且数据是存储于磁盘的,相比 Redis,健壮性更好。不过,如果使用 sharding 环境(其实千万条记录左右,我以为 Repl 就足够了),最好注意一下唯一性索引的使用。详情可以参考 MongoDB 的官方文档。

ls的应该都说的很清楚了。
1.防攻击:redis枷锁类似防重复提交。
2.加版本号和用户id建唯一索引。不过数据量大数据库应该压力大,频发抛异常
3.将控制用户只抽一次 交给redis,这样还可以通过redis有效期控制抽奖周期。

用乐观锁控制写入mysql,同时写入redis。
为了应对大量的 “新抽奖” ,用队列抗一下。
查询记录首先从redis查询,redis没有再回源到mysql去查。
mysql读写分离。
另外简单的防刷还是要做的,比如用户、ip限制,验证码等等。
恩就这样。

mysql行级锁 不要全表锁

每秒几百个请求mysql就受不了了,我只能说要么机子配置实在是太差,要么代码写得太差

如果有用户ID可以这样做:
1、每人一个key:前缀:用户ID
2、抽奖时incr这个key,返回1则正常执行抽奖,否则中断

调用完redis后,用fastcgi_finish_request()这个函数,后面该怎么写mysql的处理就怎么写,执行完fastcgi_finish_request()后会返回响应的,进程不会结束,会把后面的程序处理完。

楼主应该充分利用redis的优势哦。
阅读完,我觉得楼主的第一步就错了,把是否抽奖放在mysql来读取,这个mysql是扛不住的。用redis的原子操作就轻松搞定了。因为第一步错了,所以后面不得不用很多其他措施来弥补。

要是我 我直接在 NGINX 成面上干掉大部分流量

insert 的时候 带上 ON DUPLICATE KEY UPDATE
在创建个组合索引

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题
宣传栏