又要搬家咯

7.2号就得搬家了，东西还没收拾，等到了周末再说吧，反正也就只剩下一天了。

今天晚上不知道咋了，很兴奋。一个箭步蹿到沙发上，爪子抓了大姐的头，结果被逮住一顿“毒打”，打完之后就这样了。思考猫生，谁都不让摸。

lua是个好东西，今天看老钱关于lua脚本在Redis中可以被原子性执行的介绍后，特意去看了看文档。

Redis uses the same Lua interpreter to run all the commands. Also Redis guarantees that a script is executed in an atomic way: no other script or Redis command will be executed while a script is being executed. This semantic is similar to the one of MULTI / EXEC. From the point of view of all the other clients the effects of a script are either still not visible or already completed.

所以lua脚本被Redis内嵌的lua引擎执行的时候，不会出现并发问题，也就保证了lua脚本本身作为原子性执行的环境。联想到之前我设计的那个红包Timeline清理，突然想到了不错的拓展方法。可以避免现在为了达到一个事件有且仅能被执行一次而设计的单个消费者模型。如果借助lua脚本，内部封装zrevrange+zrem。搞成类似zpop这种的，就可以同时运行多个消费者，这样即便是今后用户多了，红包清理也不会受到影响。

<?php
$redis = new Redis();
$redis->pconnect("localhost", 44444);

$luascript = <<<SCRIPT
    local item = '';
    item = redis.call("zrevrange", KEYS[1], ARGV[1], ARGV[2], ARGV[3])
    redis.call("zrem", KEYS[1], item[1])
    return item[2]
SCRIPT;
$ret = $redis->eval($luascript, ["zset", "1", "1", "withscores"], 1);
var_dump($ret);

哈哈，还真的蛮好使。

从这个角度看LUA在这块潜力很大诶，有个念头，找时间好好学学这个脚本语言。回头可以的话，对公司现有的phpredis包装一下，lua脚本，就可以应对更多的场景了。。

此属于更上层的行为，交给底层redis-server去执行，所以移植性肯定也还行。