业务场景描述:把图片根据标签搜索的结果给客户端,但是很多图片的标签用户打得不太对,所以我们的小编们在后台就手动给一些标签匹配了非常精准的图片,那么当用户请求这个接口的时候,就把小编准备的数据放在最前面,后面才是用户上传的图片。而这个结果集是存放在一个zset数据类型的变量里面。所以需要分两步。第一步、把小编的图放入该key,而且权重都是加了100000这样后面的图片就不会排到前面来了;第二步、把用户上传的图片加入该key,把其他用户对该图片的点赞数目作为其权重值。
这样问题就出来了,因为小编推荐的图也是从用户上传的图片中选出来的,从而导致了第二步再插入的时候就把第一步插入的权重值给替换了。所以需要排重。需要注意的是在批量操作(phpredis开启事务模式的时候不管进行如何操作都是返回redis对象)。简化代码如下:
$kye = 'tag:3379:pic';
//第一步
if (!empty($picIds1) && is_array($picIds1)){
$r->multi(Redis::PIPELINE);
foreach ($picIds1 as $picId){
$r->zAdd($key, $picId['favNum'], $picId['id']);
}
$r->exec();
}
//第二步
if (!empty($picIds2) && is_array($picIds2)){
$r->multi(Redis::PIPELINE);
foreach ($picIds2 as $picId){
$_tmpScore = $r->zScore($key,$picId['id']);
//var_dump($_tmpScore);
if(is_numeric($_tmpScore) && $_tmpScore > 100000){}else{
$r->zAdd($key, $picId['favNum'], $picId['id']);
}
}
$r->exec();
}
打开上面的var_dump的注释就会发现打印出来的都是一个redis的对象:
object(Redis)#5 (1) {
["socket"]=>
resource(72) of type (Redis Socket Buffer)
}
最初怀疑服务器上的redis版本过老,而不支持该命令。在服务器上执行ZSCORE key value完全OK,查看官方文档才明白:multi() returns the Redis instance and enters multi-mode. Once in multi-mode, all subsequent method calls return the same object until exec() is called.
这样就就先过滤数据,再批量处理吧:
$kye = 'tag:3379:pic';
//第一步
if (!empty($picIds1) && is_array($picIds1)){
$r->multi(Redis::PIPELINE);
foreach ($picIds1 as $picId){
$r->zAdd($key, $picId['favNum'], $picId['id']);
}
$r->exec();
}
//第二步
if (!empty($picIds2) && is_array($picIds2)){
//先过滤
foreach ($picIds2 as $k => $picId){
$_tmpScore = $r->zScore($key,$picId['id']);
if(is_numeric($_tmpScore) && $_tmpScore > 100000){
unset($picIds2[$k]);
}
}
//再批量处理
$r->multi(Redis::PIPELINE);
foreach ($picIds2 as $picId){
$r->zAdd($key, $picId['favNum'], $picId['id']);
}
$r->exec();
}
顺便也困惑下:
Redis::PIPELINE : 让(多条)执行命令简单的更加快速的发送给服务器,但是没有任何原子性的保证.
a Redis::PIPELINE block is simply transmitted faster to the server, but without any guarantee of atomicity.
是不是应该把Redis::PIPELINE换成Redis::MULTI,以确保精准?