原生PHP用 Redis ZSet 实现一个实时排行榜，用 Lua 脚本实现一个简单的分布式锁的庖丁解牛

在原生 PHP无 Laravel/Hyperf 框架依赖环境下直接操作 Redis 是理解底层机制的最佳途径。“实时排行榜”利用了 RedisZSet (Sorted Set)的天生优势自动排序、去重、范围查询。“分布式锁”则利用了 Redis 的原子性和Lua 脚本解决了并发场景下的资源竞争问题。理解这两个场景就是理解如何利用 Redis 的数据结构特性解决业务难题以及如何用 Lua 保证复杂操作的原子性。一、核心原理为什么是它们1. 实时排行榜ZSet 的数学之美数据结构ZSet Member (成员) Score (分数)。底层实现跳表 (Skip List)字典 (Dict)。跳表保证元素有序插入/删除/查找复杂度为O(log⁡N)O(\log N)O(logN)。字典保证 Member 唯一查找复杂度O(1)O(1)O(1)。优势无需每次查询都ORDER BYRedis 内部永远维持有序状态读取极快。2. 分布式锁Lua 的原子之力痛点SETNXEXPIRE分两步执行非原子。若第一步成功第二步失败宕机导致死锁。解决方案Lua 脚本。Redis 执行 Lua 脚本时是单线程原子的。将“检查锁”、“设置锁”、“设过期时间”、“释放锁验证”打包成一个脚本要么全成功要么全失败。 核心洞察ZSet 是用空间换时间的排序大师Lua 是用脚本换原子性的并发卫士。二、实战实现原生 PHP 代码解剖假设环境PHP 7.4安装了phpredis扩展。1. 实时排行榜 (Real-time Leaderboard)场景定义Key:leaderboard:game_1001Member:user_id(字符串)Score:score(整数/浮点数)核心代码?php$redisnewRedis();$redis-connect(127.0.0.1,6379);$keyleaderboard:game_1001;// 1. 更新分数 (增加或修改)// ZADD 会自动处理若存在则更新分数并重新排序若不存在则插入$userIduser_888;$score2500;$redis-zAdd($key,$score,$userId);// 2. 获取 Top 10 (从高到低)// ZREVRANGE: 0 到 9WITHSCORES 返回分数$top10$redis-zRevRange($key,0,9,true);// 返回格式[user_999 3000, user_888 2500, ...]// 3. 获取某用户的排名 (从 1 开始)// ZREVRANK: 返回索引 (0-based)所以 1$rank$redis-zRevRank($key,$userId);$realRank$rank!false?$rank1:0;// 4. 获取用户周围排名 (前后各 2 名共 5 名)// 先获知自己的 rank再计算区间if($rank!false){$startmax(0,$rank-2);$end$rank2;$around$redis-zRevRange($key,$start,$end,true);}echoUser{$userId}Rank:{$realRank}, Score:{$score}\n;关键点解析自动去重同一个user_id多次zAdd只会保留最新分数不会产生重复数据。分数类型Score 是 double 类型支持小数适合精确计分。复杂度即使排行榜有 1 亿用户获取 Top 10 依然是O(log⁡NM)O(\log N M)O(logNM)极快。2. 分布式锁 (Distributed Lock with Lua)场景定义Lock Key:lock:order_create_1001Value:unique_token(防止误删别人的锁)TTL: 10 秒 (防止死锁)核心代码步骤 A: 加锁 (Lock)?php$redisnewRedis();$redis-connect(127.0.0.1,6379);$lockKeylock:order_create_1001;// 生成唯一标识通常用 uniqid random 或 uuid$owneruniqid(client_,true);$ttl10;// 秒// Lua 脚本尝试设置锁 (SET NX EX)// 如果 key 不存在则设置 value 和过期时间返回 1 (成功)// 如果 key 已存在返回 nil (失败)$lockScriptLUAif redis.call(SET, KEYS[1], ARGV[1], NX, EX, ARGV[2]) then return 1 else return 0 endLUA;$isLocked$redis-eval($lockScript,[$lockKey,$owner,$ttl],1);if($isLocked){echoLock acquired by{$owner}\n;// --- 执行业务逻辑 ---sleep(2);// ------------------// 步骤 B: 解锁 (Unlock) - 必须用 Lua 保证原子性$unlockScriptLUAif redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 endLUA;$released$redis-eval($unlockScript,[$lockKey,$owner],1);if($released){echoLock released successfully\n;}else{echoFailed to release lock (maybe expired or owned by others)\n;}}else{echoFailed to acquire lock, busy...\n;// 可选重试机制或降级处理}关键点解析唯一 Value ($owner)这是防止误删锁的关键。如果 A 拿到锁业务执行超时导致锁自动过期B 拿到了锁。此时 A 恢复执行并调用DEL如果没有校验 ValueA 会把 B 的锁删掉原子性GETDEL必须在 Lua 中执行。如果分开写高并发下依然可能误删。SET NX EXRedis 2.6.12 支持在SET命令中同时实现NX(不存在才设) 和EX(过期时间)这是最简洁的加锁方式。三、深度剖析那些容易被忽视的细节1. 排行榜的“同分处理”问题如果两个用户分数相同谁排前面机制Redis ZSet 默认按Member 的字典序排列当 Score 相同时。优化如果需要“先达到的排前面”可以将 Score 设计为复合值Score 真实分数 * 10000000000 (MAX_TIMESTAMP - 当前时间戳)这样分数高者优先分数相同时间短时间戳大减完小者优先。注意需小心浮点数精度问题最好用整数运算。2. 锁的“看门狗” (Watchdog) 机制问题业务逻辑执行时间超过 TTL 怎么办现象锁自动释放其他线程进入导致并发安全问题。解决方案简单版设置一个较长的 TTL如 30s假设业务不会超过这个时间。进阶版 (Redlock/Redisson 模式)启动一个后台线程/协程每隔 TTL/3 时间检测一次如果锁还是我的且业务没做完就续期 (Expire)。原生 PHP 难点PHP 是同步阻塞的实现看门狗需要pcntl_fork(CLI 模式) 或配合 Swoole/Hyperf。在纯 Web 模式下通常依赖合理的 TTL 估算。3. Lua 脚本的性能缓存Redis 会缓存已加载的 Lua 脚本通过 SHA1 哈希。优化第一次用eval(传脚本内容)后续用evalSha(传 SHA1) 可以减少网络传输流量。$sha$redis-script(load,$lockScript);$redis-evalSha($sha,[$lockKey,$owner],1);四、风险陷阱生产环境的“暗礁”1. 大 Key 问题 (Big Key)场景排行榜有 1000 万用户。风险虽然 ZSet 读取快但如果一次性zRange($key, 0, -1)获取全部会阻塞 Redis 线程导致其他请求超时。对策永远只查局部Top N 或 分页游标ZSCAN。2. 锁死锁 (Deadlock)场景加了锁但代码抛出异常后面的解锁代码没执行。对策PHP 端使用try...finally块确保finally中执行解锁逻辑。Redis 端务必设置EX(过期时间)依靠 Redis 自动清理作为最后一道防线。3. 时钟漂移场景分布式系统中不同服务器时间不一致影响基于时间的锁判断较少见主要影响 Redlock 算法。对策尽量依赖 Redis 服务器时间或使用 NTP 严格同步。4. 脑裂 (Split-Brain)场景主从切换期间锁写在旧主已隔离新主认为无锁。对策对于极高可靠性要求需使用Redlock 算法向 N 个独立 Redis 实例申请锁过半成功才算成功。普通业务单机 Redis 或哨兵模式通常足够。五、性能优化与最佳实践1. 批量操作排行榜如果需要更新大量用户分数使用Pipeline批量发送zAdd命令减少网络 RTT。$pipe$redis-multi(Redis::PIPELINE);foreach($usersas$u){$pipe-zAdd($key,$u[score],$u[id]);}$pipe-exec();2. 内存优化ZSet 编码当元素少且成员短时Redis 会用ziplist(压缩列表) 存储极省内存。尽量控制 Member 长度。定期清理对于不再活跃的排行榜如已结束的活动及时DEL释放内存。3. 锁的粒度原则锁的粒度越细越好。错误lock:global_order(全局锁串行化性能差)。正确lock:order_user_{userId}或lock:product_{productId}(只锁特定资源并发度高)。 总结原生 PHP Redis 实战全景图维度核心要点关键命令/技术排行榜ZSet 跳表自动排序zAdd,zRevRange,zRevRank,zRem分布式锁Lua 原子性唯一 ValueSET NX EX,eval,GETDEL原子性脚本即事务避免多步操作一切交给 Lua安全性防误删防死锁校验 Owner设置 TTLtry-finally性能** Pipeline, 局部查询**避免全量扫描批量写入陷阱大 Key, 异常未解锁限制 Range异常处理机制终极心法Redis 是利器但需用正确的姿势挥舞。ZSet 让排序变得 trivialLua 让并发变得可控。理解它们就是理解“如何用简单的原语构建复杂的同步机制。记住原子性是分布式的基石超时是死锁的克星。于结构中见效率于脚本中见安全以 ZSet 为尺以 Lua 为盾于高并发浪潮中筑秩序之基。最好的锁是持有时最短释放时最稳最好的榜是更新时无感查询时极速。行动指令给开发者编写测试用例模拟 100 个并发进程同时抢锁验证是否有重复执行。压测排行榜插入 10 万条数据测试zRevRange和zRevRank的耗时。模拟异常在持有锁时强制kill脚本观察 TTL 是否生效自动释放。封装类库将上述逻辑封装成RedisLeaderboard和RedisLock类方便复用。研究 Redlock阅读 Antirez 的 Redlock 论文理解多实例锁的权衡。监控慢日志开启 Redisslowlog检查是否有耗时的 ZSet 操作。尝试 Pipeline对比单条执行与 Pipeline 批量执行的耗时差异。这就是原生 PHP 结合 Redis 实现排行榜与分布式锁于代码中见逻辑于原子里见真章以结构为骨以脚本为魂于并发世界中求稳健之真。最后送你一句话排行榜记录的是胜负分布式锁守护的是底线。一个向上激发竞争一个向内维持秩序。用好 Redis 这两把钥匙你的系统既能勇攀高峰又能稳如泰山。