Redis里那些用户名单，可能比你想象的还重要，别忽视了用户列表管理

（根据微信公众号“运维漫谈”发布的文章《Redis里那些不起眼的用户名单，可能比你想象的还重要》整理）

你有没有想过,你用的那个APP，它的后台Redis数据库里，可能正躺着你的用户名、最近登录时间，甚至是你正在看的商品列表，这些东西看起来零零散散，好像没什么大不了的，但事实上，这一堆堆的用户相关数据，就像是整个系统的“心脏”，一旦这里出了问题，轻则用户登录不了，重则整个服务瘫痪，数据还可能泄露，真的不能小看了Redis里的用户列表管理。

先说说最常见也最要命的一个场景：用户登录状态，现在很多网站和APP都用Redis来存用户的登录凭证，比如那个叫Token的东西，用户一登录，系统就会在Redis里生成一个Key，这个Key可能就是用户的ID或者一个随机的字符串，Value里存着用户的身份信息和这个Token的有效时间，这套机制运行起来很流畅，用户不用反复登录，体验很好，但问题也藏在这里，你想啊，如果管理不当，比如这个Token的有效期设置得太长，或者干脆忘了设置过期时间，那这些Key就会在Redis里一直活着，变成“僵尸Key”，它们占着内存不说，万一被坏人拿到了，就能一直冒充用户，太危险了，还有一种情况，如果Redis服务器突然宕机了，或者因为内存满了自动清理了数据，那结果就是所有用户瞬间“被下线”，大家都要重新登录，那种体验对用户来说简直是灾难，怎么设置合理的过期时间，怎么做好Redis的高可用保证服务不中断，是管理用户登录状态的头等大事。

除了登录状态,用户列表还以另一种形式存在，那就是各种“关系链”，比如微博的关注列表和粉丝列表，微信的群成员列表，电商平台的购物车商品列表，这些数据也经常用Redis的Set（集合）或Sorted Set（有序集合）这种数据结构来存，它的好处是查询速度特别快，不管你列表里有多少人，都能很快地判断某个人在不在里面，但麻烦事也跟着来了，一个明星有几千万粉丝，这个粉丝列表的Key对应的Value就会非常大，我们常叫它“大Key”，这种大Key在迁移数据或者持久化存储的时候，会特别耗时，可能会阻塞Redis的其他操作，导致服务变慢，更头疼的是，如果这个明星突然爆出个新闻，粉丝数猛增或猛减，对这个大Key的频繁修改又会带来巨大的网络流量和操作压力，对于这种增长可能很快的列表，就得提前想好办法，比如是不是可以按某种规则把一个大列表拆分成多个小列表来存放，避免单个Key过于庞大。

还有一种容易被忽视的列表,就是那些临时性的、用于限制用户行为的名单，为了防止恶意刷接口，系统会限制一个IP地址一分钟内只能请求多少次，这个计数就是放在Redis里的，给每个IP设个Key，记录次数和重置时间，又比如，系统给用户发短信验证码，也会在Redis里记一下，防止短时间内重复发送或者验证码被暴力破解，这些Key的特点是生命周期很短，可能几分钟就失效了，但数量可能极其庞大，因为每个IP、每个手机号都可能产生一个Key，如果管理不好，会产生海量的短期小Key，给内存管理和垃圾回收带来压力，这些限制规则的逻辑如果设计得有漏洞，要么防不住坏人，要么可能误伤正常用户。

也是最敏感的一点,就是数据安全，Redis的设计初衷是追求速度，所以早些年版本在安全性上考虑得没那么周全，甚至默认不需要密码就能连上，如果把存着用户敏感信息的Redis服务直接暴露在公网上，那简直就是给黑客开了扇大门，他们可以轻松地导出所有的用户数据，包括那些Token、关系列表等等，必须给Redis设置复杂的密码，最好限制只能从内部网络访问，绝对不能图省事暴露在公网环境，即使在内网，也要做好权限控制，不是所有的应用都应该有权限访问所有的用户数据。

Redis里的用户名单,远不止是一串ID那么简单，它关系到用户能不能正常使用服务，体验流不流畅，更关系到用户的数据安不安全，它既是保障系统顺畅运行的功臣，也可能成为整个系统中最脆弱的环节，忽视对它的管理，就像是在大坝上留了一个蚁穴，平时看着没事，一旦出事，可能就是毁灭性的，从设计系统的那一刻起，就得好好思考怎么管好这些至关重要的用户列表。