今天在用Redis时遇到一个奇怪的问题，虽然很快就定位到了问题，但是在开发时确实忽略了，还是意识不到位，这里记录一下问题的来龙去脉让自己铭记。

背景

首先介绍一下背景，在一个类似抢票的项目中，其中有一步是需要把奖品数据存放在Redis的一个集合（Set）中，中奖时通过SPOP命名从集合中取出一个奖品。这个奖品集合的数据在开始抢票之前生成，放在了一个脚本中去做，问题就出现在了这个脚本。

奖品数据生成脚本

上面我们说的脚本要做的工作无非就是：

1. 读出全部的奖品

2. 分批把奖品存入Redis的一个Set中（考虑奖品过多，没有一次把全部存入，做了分批处理）

这么看脚本很简单，没有什么复杂的逻辑，但是需要确保全部奖品都写入Redis成功，不能只写入部分奖品。如果有失败，需要进行重试或者报警。

下面直接看下代码，代码用世界上最好的PHP语言，Redis客户端用的phpredis。

function setPrize($arrPrizes) {    try {        // 真实的奖品是由上面的参数$arrPrizes传入，数据格式如下：        // $arrPrizes = array(        //     array('code' => 'A0001', 'name' => 'iPhone'),        //     array('code' => 'A0002', 'name' => 'iPhone'),        // );        foreach ($arrPrizes as $intIndex => $arrPrize) {            $arrPrizes[$intIndex] = json_encode($arrPrize);        }

        // 获取Redis实例        $objRedis       = RedisUtil::getInstance();        $strRedisKey    = 'www.daemoncoder.com';        $arrPrizePages  = array_chunk($arrPrizes, 100);        foreach ($arrPrizePages as $arrPrizePage) {            // 分批写入redis中            $intAddResult = $objRedis->sAddArray($strRedisKey, $arrPrizePage);            echo sprintf("AddResult: %s\n", var_export($intAddResult, true));        }

        // 判断写入的集合最终大小是否和传入的数组大小一致        // 不一致则中间有数据没有成功写入，需要返回给上层重试或者报警        $intScardResult = $objRedis->sCard($strRedisKey);        echo sprintf("ScardResult: %s\n", var_export($intScardResult, true));        if ($intScardResult == count($arrPrizes)) {            return true;        }    } catch (Exception $e) {        var_dump($e);    }    return false;}

代码中 RedisUtil::getInstance() 是一个封装过的Redis工具类，里面封装了获取redis连接、自动选择主从库等操作。$objRedis->sAddArray() 把奖品数据分批写入，最后通过$objRedis->sCard()来判断是否全部成功写入，有失败的话需要返回给上层调用的地方，进行重试或者报警处理。

问题的表现

上面的代码实在太简单，一顿操作就把代码写完了，然后开心地去测试，没问题。不过为了稳妥，还是设置了重试一定次数，依然执行失败就邮件报警，万事具备，不可能再有问题了，上线！然后，就翻车了！喜获报警邮件一份！

经过多次在测试发现不稳定，大多数情况可能成功执行，但是有很小的概率会失败。问题是失败的情况下，并不是因为写Redis失败。从输出的数据看，失败的时候也成功执行了写入操作，而且sCard()操作也成功执行，就是得到的数据不对。

问题的定位

手动清除原有数据，重新执行脚本，问题复现之后，查看输出，一切正常，只有sCard()返回的数据不对，还手动查了下当时集合中写入的数据，确实成功写入了，所以问题就锁定在了sCard()方法。

查了下Redis SCARD命令的官方文档：https://redis.io/commands/scard，先确认自己的没有用错。命令功能很简单，没有什么特别的地方，就是返回集合中的元素数量，如果key不存在，返回0。

难不成redis的scard命令有bug不成？兴奋之际，再单独执行了一下sCard()，这次结果竟然对了，这么看，问题不在sCard()，大概可以猜到问题的原因是出在了数据延时的问题。就是说之前通过sAddArray()写入集合的数据，有部分还没有生效。Redis本身用单线程处理请求，理论不应该存在出现这种延时，但是线上环境的Redis往往都是主从结构的，主库到从库同步数据是会有延时的，这也是出现这个问题的真实的原因。

上述代码中用RedisUtil::getInstance()来获取redis示例，前面也有介绍，这个是我们自己封装的Redis工具类，会根据不同的redis命令做读写分离。sAddArray()是一个写请求，会自动选择主库连接执行，而sCard()是一个读请求，默认会选择从库去执行。所以会出现用sCard()读取不到集合真实的大小，因为从库此时可能还没有同步到最新的数据。

解决方案

调整代码，强制让sCard()方法选择主库（每个人连接的Redis工具类不同，这里不再贴代码，大概的方式就是连接时指定主库的IP）。这样经过多次反复测试，没有再出现这个问题。

一些反思

为什么上线前测试的时候没有发现这个问题？

部分原因是问题出现的概率比较小，还有更重要的一个原因，是我们线下测试环境的Redis就只有一个库！没有那么多资源去给测试环境做个主从，最根本的原因可能还是因为穷(囧)。我想应该有不少公司和我们一样的，所以希望这个问题对你也有帮助。

不仅仅是主从延时的问题不易发现，如果线上Redis有多台机器，选择机器连接出错的问题也不易发现。

用一个比较常见的场景为例，存储用户的数据时，往往根据用户的ID做哈希，分布存储在多台机器上，如果代码有bug计算哈希值时用错了值，就有可能选择错误的机器。如果恰好你和我们一样，测试环境只有可怜的一台机器，那么测试阶段可能发现不了这个问题，细思极恐有木有。

为什么开发时没有考虑到会有主从延时的问题？

这个确实要从自己找原因了，还要把提高自己的主从意识。不仅仅是这种场景要考虑主从，从Redis中读任何数据时，都要第一时间想到读到可能不是最新数据。也不仅仅是Redis，MySQL等其他主从结构数据库，也都要第一时间想到主从延时。

转载请注明出处，本文原始链接：https://www.daemoncoder.com/a/%E8%AE%B0%E4%B8%80%E6%AC%A1Redis%20scard%E8%AF%BB%E5%8F%96%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%9C%E4%B8%8D%E5%AF%B9%E7%9A%84%E9%97%AE%E9%A2%98/4d54673d

点击下方阅读原文，或访问 daemoncoder.com 发现更多优质内容。

扫码关注公共号，第一时间收到优质内容