通常意义上我们说读后写是指针对同一个数据的先读后写,且写入的值依赖于读取的值。

关于这个定义要拆成两部分来看,一:同一个数据;二:写依赖于读。(记住这个拆分,后续会用到,记为定义一、定义二)只有当这两部分都成立时,读后写的问题才会出现。

在项目中,当面对较多的并发时,使用redis进行读后写操作,是非常容易出问题的,常常使得程序不具备鲁棒性,bug很难稳定复现(得到的值往往跟并发数有关)。
举个栗子:
存在A、B两个进程,同时操作下面这段代码:

$objRedis = new Redis();
//获取key
$intNum = $objRedis->get('key');
if ($intNum == 1) {
//如果key的值为1,则给key加1
$bolRet = $objRedis->incr('key');

//do something...
}
1
2
3
4
5
6
7
8
9
如果A进程先get到了key,而此时key的值为1;
同时,B进程此时也get到了key,同样key值为1;
B进程运行的快,先进行了if判断,发现满足条件,于是对key进行了累加操作,此时key变成了2;
A进程对B进程修改了key这个操作茫然无知,所以当它继续运行走到if判断条件时,由于它get的key是1,因此也满足条件,于是A进程也会对key进行累加操作,但是由于key已经被B进行累加过一次(key的值已经是2),因此当A再累加,key最终就变成了3。
实际上,代码的本意是希望key为1时执行一些操作,但当出现并发的时候,这段代码很难满足期望!
如果这样的代码出现在抽奖、秒杀等活动中,那就只能期望公司不会让个人承担损失了(汗)。
以上就是一个比较简单的读后写的问题。

对于这段代码其实很好解决,尤其是如果key的值本身没有意义的时候:

$objRedis = new Redis();
//获取key
$intNum = $objRedis->incr('key');
if ($intNum == 1) {
//do something...
}
1
2
3
4
5
6
以上代码使用了incr原子型操作,限制了并发(相当于加锁),就不会出现上述问题了。

但是,如果这个key如果是有意义的呢,那就不能随意改变,这种情况我们该怎么办?

详细说明
下面我举一个更具体的例子,然后从这个例子出发来抛几块砖(个人想的解决办法),希望引出更多的玉。

例子如下:
有一个活动,需要根据用户连续参与天数进行发奖,规则如下:

连续参与1-3天,每天额外奖励10金币;
连续参加4-7天,每天额外奖励50金币;
连续参加8-15天,每天额外奖励100金币;
连续参加15天以上,每天额外奖励200金币;
简单思路(使用读后写):

对每个用户使用一个hash存储,其中一个字段表示连续天数(‘sequence’),另一个字段存储最近参与日期(‘lastdate’)。
精简版代码如下:

$objRedis = new Redis();
//根据用户ID,生成redis的key
$strRedisKey = 'activity_' . $intUid;
//从Hash中获取最近参与时间
$mixDate = $objRedis->HGET($strRedisKey, 'lastdate');

$intLastDate = intval($mixDate);
$intYesterDay = intval(date("Ymd", strtotime("-1 day")));
$intCurrDate = intval(date('Ymd'));
$intNum = 0;//连续天数
if ($intCurrDate == $intLastDate) {
//今天已经参与过,直接跳过
return;
} elseif ($intLastDate == $intYesterDay) {
//日期连续,增加连续天数
$intNum = $objRedis->HINCRBY($strRedisKey, 'sequence', 1);
if ($intNum > 0) {
//将最近参与时间设置为当天
$objRedis->HSET($strRedisKey, 'lastdate', $intCurrDate);
}
} else {
//日期不连续,设置连续天数为1,最近参与时间为当天
$intNum = 1;
$objRedis->HMSET($strRedisKey, 'sequence', $intNum, 'lastdate', $intCurrDate);
}

//do something(根据$intNum发放金币等操作)...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
很明显,这也是一个读后写的方法——先获取最近参与日期,再根据条件修改最近参与日期(定义一二都被满足了),这个方法在高并发的时候很有可能会导致连续天数的错误累加。

那么,这个例子如何避免读后写呢?
方法其实有很多,这里先举两个:

方法1:

通过使定义一或二不成立,从而使得读后写的问题不存在。

按日期进行存储——将redis的key按日期进行划分,比如用户ID为123的key从redis_123变为redis_123_20171225。这样的话,其实相当于避免了读写同一份数据。
代码如下:

$objRedis = new Redis();
//根据用户ID,生成redis的key
$strCurrRedisKey = 'activity_' . $intUid . '_' . date('Ymd');
//从Hash中获取最近参与时间
$mixNum = $objRedis->GET($strCurrRedisKey);

$intNum = 0;//连续天数
if (is_null($mixNum)) {
//当天还没被处理过,查找前一天的记录
$strLastRedisKey = 'activity_' . $intUid . '_' . intval(date("Ymd", strtotime("-1 day")));
$mixLastNum = $objRedis->GET($strLastRedisKey);
//计算连续天数
$intNum = intval($mixLastNum) + 1;
//设置当天的连续天数,并给这个key一周的过期时间
$objRedis->SETEX($strCurrRedisKey, 604800, $intNum);
} else {
//今天已经操作了,直接返回
return;
}

//do something(根据$intNum发放金币等操作)...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
这个思路是通过读昨天的数据后修改今天的数据,来达到避免对同一份数据读后写的目的的(使得定义一不成立,从而消除读后写的问题)。
这里虽然在最开始的时候也读取了今天的数据,但由于最后对今天的数据的修改只依赖于昨天的数据(今天的数据=昨天数据+1),而不依赖于读到的今天的数据,所以也就没有读后写的问题了(所以也可以看作是使定义二不成立)。

方法二:

限制并发。

方法一是使定义一或二不成立,从而解决读后写的问题。这里就不再在定义一或二上做文章了,下面换一个思路。
读后写归根结底其实还是并发下才会出现问题。因此这里介绍一个釜底抽薪的方法,限制并发!
一说到限制并发,可能第一反应就是加锁,自己在代码中加锁当然是一种办法,但是相对来说成本还是高一些(如何加锁可以参考我之前的一篇博文《用redis实现悲观锁》),这里就不再赘述。
其实读后写,最基本也是最简单的拆分方式是——读和写,那么釜底抽薪的办法就是能不能不读,只写!
实现思路就是只用一个key来存储连续天数+当前日期,然后使用原子型操作来写。一说到原子型操作,在redis中第一反应就是incr。那么顺着这个思路,我们怎么利用incr来操作呢?
其实关键是设计一个存储方式,满足既能存放连续天数,又能存放当前日期,还能使得这个值多次incr而不影响本身数据。这里说下我的设计方法:将一个12位的整数值看作是一个分段有意义的值,连续天数用最高的2位表示(因业务自定义),中间8位代表日期(如20171225),最后2位用于计数(无实际意义),比如:

将012017122523拆分成:
01|20171225|23
分别代表:连续天数|最近参与日期|计数

其中计数,这个字段是为了在利用incr时限制并发的。
示意代码如下:

$objRedis = new Redis();
//根据用户ID,生成redis的key
$strRedisKey = 'activity_' . $intUid;
//从Hash中获取最近参与时间
$intVal = intval($objRedis->INCR($strRedisKey));
$intCnt = $intVal % 100;//获取计数
$intLastDate = ($intVal - $intCnt) % 100000000;//获取最近参与日期
$intNum = intval($intVal / 10000000000);//连续天数
$intYesterDay = intval(date("Ymd", strtotime("-1 day")));//昨天的日期
$intCurrDate = intval(date('Ymd'));//今天的日期

if ($intCurrDate == $intLastDate) {
//今天已经操作了
if ($intCnt > 90) {
//重置计数,防止超过给定范围(最大99)
$objRedis->SET($strRedisKey, $intNum * 10000000000 + $intCurrDate * 100 + 1);
}
return;
} elseif ($intYesterDay == $intLastDate) {
//日期连续,计算连续天数
$intNum += 1;
} else {
//日期不连续,重置连续天数
$intNum = 1;
}
//更新连续天数及当前日期
$objRedis->SET($strRedisKey, $intNum * 10000000000 + $intCurrDate * 100 + 1);

//do something(根据$intNum发放金币等操作)...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
只要涉及到数据读、写,就会有数据一致性问题,mysql中可以通过事务、锁(FOR UPDATE)等来保证一致性,而redis也可以根据业务需求设计不同的读写方式来实现(redis的事务真心不太好用)。这里抛出两种redis克服读后写问题的思路,希望能起到引玉的作用!

水平有限,欢迎指正~
如需转发,请注明出处,thx~
---------------------
作者:grey256
来源:CSDN
原文:https://blog.csdn.net/u011832039/article/details/78924418
版权声明:本文为博主原创文章,转载请附上博文链接!

高并发下Redis如何保持数据一致性(避免读后写)的更多相关文章

  1. [Redis] - 高并发下Redis缓存穿透解决

    高并发情况下,可能都要访问数据库,因为同时访问的方法,这时需要加入同步锁,当其中一个缓存获取后,其它的就要通过缓存获取数据. 方法一: 在方法上加上同步锁 synchronized //加同步锁,解决 ...

  2. 高并发下redis

    1.================================================================================================== ...

  3. 高并发下redis缓存穿透问题解决方案

    一.使用场景 我们在日常的开发中,经常会遇到查询数据列表的问题,有些数据是不经常变化的,如果想做一下优化,在提高查询的速度的同时减轻数据库的压力,那么redis缓存绝对是一个好的解决方案. 二.需求 ...

  4. php结合redis实现高并发下的抢购、秒杀功能

    抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个:1 高并发对数据库产生的压力2 竞争状态下如何解决库存的正确减少("超卖"问题)对于第一个问题,已经很容易想到用缓存 ...

  5. (高级篇)php结合redis实现高并发下的抢购、秒杀功能

    抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个:1 高并发对数据库产生的压力2 竞争状态下如何解决库存的正确减少("超卖"问题)对于第一个问题,已经很容易想到用缓存 ...

  6. php结合redis实现高并发下的抢购、秒杀功能 (转载)

    抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个: 1 高并发对数据库产生的压力 2 竞争状态下如何解决库存的正确减少("超卖"问题) 对于第一个问题,已经很容易想到 ...

  7. redis实现高并发下的抢购/秒杀功能

    之前写过一篇文章,高并发的解决思路(点此进入查看),今天再次抽空整理下实际场景中的具体代码逻辑实现吧:抢购/秒杀是如今很常见的一个应用场景,那么高并发竞争下如何解决超抢(或超卖库存不足为负数的问题)呢 ...

  8. PHP和Redis实现在高并发下的抢购及秒杀功能示例详解

    抢购.秒杀是平常很常见的场景,面试的时候面试官也经常会问到,比如问你淘宝中的抢购秒杀是怎么实现的等等. 抢购.秒杀实现很简单,但是有些问题需要解决,主要针对两个问题: 一.高并发对数据库产生的压力二. ...

  9. 【转】php结合redis实现高并发下的抢购、秒杀功能

    抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个:1 高并发对数据库产生的压力2 竞争状态下如何解决库存的正确减少("超卖"问题)对于第一个问题,已经很容易想到用缓存 ...

随机推荐

  1. arm64的适配问题,这次真醉了

    写过tableView的童鞋都知道,有必须的两个代理方法要实现,还有几个选择实现的. 必须实现的代理方法: ~设置行数 - (NSInteger)tableView:(UITableView *)ta ...

  2. 01_Hadoop学习笔记内容说明

    Hadoop学习笔记内容说明_00 1.  观看云帆大数据梦琪老师的<企业级 Hadoop 1.x 应用开发基础课程>2014年4月左右版本. 2.  博客是在梦琪老师的随堂笔记上改动的, ...

  3. 大数据架构之:Flume

    1. Flume是一个分布式.可靠.和高可用的海量日志聚合的系统,支持在系统中定制各类数据发送方,用于收集数据:同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力. 2.一个 ...

  4. Sublime text3装入插件Anaconda

    好多人在学习编写代码的时候,会有不同的编辑器,大神们建议我使sublime,但是我在里面写代码,没有一点提示,我的天,不得烧坏我的脑子啊.学Python我用的Ananconda,但是这个spyder有 ...

  5. requests.post处理Content-Type: multipart/form-data的请求

    前几天遇到一个需求,要调用一个接口发送请求,抓包之后得到的数据是这样的 上网看了一些资料得知,原来这个接口的数据是通过multipart/form-data格式传过去的,multipart/form- ...

  6. windows环境下安装部署并启用zkui的web图形界面

    在此之前的工作:不是本机部署的三个服务器最为伪集群的zookeeper环境,并将三个为服务启动起来. 然后才有了下面的工作. 1. 首先,zkui项目地址:https://github.com/Dee ...

  7. Linux vi 编辑器 常用命令行

    1.vi 模式   a) 一般模式: vi 处理文件时,一进入该文件,就是一般模式了.   b) 编辑模式:在一般模式下可以进行删除,复制,粘贴等操作,却无法进行编辑操作.等按下'i,I,o,O,a, ...

  8. YARN作业提交流程剖析

    YARN(MapReduce2) Yet Another Resource Negotiator / YARN Application Resource Negotiator对于节点数超出4000的大 ...

  9. Apache Phoenix的序列

    序列作为标准SQL特性,允许生成递增的序列并应用在典型的ID中.为了创建一个序列,可以使用: 0:jdbc:phoenix:SZB-L0023780:2181:/hbase114> CREATE ...

  10. php+JS进度条

    <?phpini_set('max_execution_time','0');//设置本页面加载时间无限制 echo "<div style='border: 1px solid ...