zadd sport:ranking:mx:20210227 7688 赵四 9688 刘能 10026 why 10158 mx 54367 大脚
why 和 mx 看到的都是各自好友某一天的微信步数排行榜。
只要把 key 设计好了，这个问题就迎刃而解了。
但是你仔细思考一下，真的就迎刃而解了吗？
这个问题，我在写第一版的时候可能是被猪油蒙蔽了双眼，没发现。
有种“只缘身在此山中”的味道，一心想着 Redis 了。
你想，如果每个用户都有在redis有一个自己的排行榜，一个用户的分数更新的时候就需要对所有好友的zset更新，这多大的代价啊，对吧？
当以用户为纬度做排行榜的时候，就会出现排行榜巨多的情况，导致维护成本升高。
Redis能做，但不是最佳方案。
那么用什么方案去做呢？
我提个思路吧：
每个用户看到的排行榜不一样，我们其实不用时时刻刻帮用户维护好排行榜。
维护好了，用户还不一定来看，出力不讨好的节奏。
所以还不如延迟到用户请求的阶段。
当用户请求查看排行榜的时候，再去根据用户的好友关系，循环获取好友的步数，生成排行榜。
具体方案，大家自己思考一下吧。
另外多说一嘴，前段时间不是微信支持了修改微信号吗，赢得一大片叫好声。
其实我当时认真的想了一下，从技术上的实现来说这个需求到底有多难。
我不知道有没有历史技术债务在里面。
但是就说当前这个场景，key 里面包含了微信号，注意是微信号，不是微信昵称。
因为在设计之初，产品打包票说：放心，微信号绝对全局唯一，一旦确定，不可变更。
结果呢，现在要变化了。
产品屁颠屁颠的说：怎么实现我不管，这个需求用户呼吁很大，赶紧上线。
你说，对这些类似场景的冲击有多大？
其实冲击也不算特别大，一个字段的变化而已。
但是，微信 14 亿用户啊。
一个简单的需求，涉及到这个体量之后，就一句话：
量变引起质变。
好了，好了，扯远了。说回来。
当我把目光再次放到微信排行榜上的时候，我发现，其实我只是给了一个阉割版的排行榜。
是的，我们现在可以获取到 why 的当前步数是 1680 步，当前排名是 814 名。
比如还是沿用上面的例子，假设现在要获取我的微信好友 jay 的微信步数排行榜情况。
先获取 jay 的名次：
zrevrank sport:ranking:why:20210227 jay
名次为 0，程序里面可以对其进行加一操作。就是第一名了。
接着获取 jay 的今日步数：