2025-09-28
上天权限系统的验证使用了Redis。今天简单了解下Redis是啥以及常规的应用场景，这样后续项目改进也能有效的加入Redis。
Redis（Remote Dictionary Server）是一个开源的、基于内存的高性能 Key-Value 数据存储系统。
（1）缓存，Redis数据存储在内存中，所以读写速度快非常多。比如上次的权限验证，将我们的用户权限放入了缓存，这样就不用每次查询都要去数据库里访问了，大大减小了数据库的压力。
（2）共享存储，在分布式系统中，用户的登录状态需要共享，Web 网站的登录 Token 或 Session 存储在 Redis 中，保证多个应用节点共享登录状态。这儿具体解释下为啥需要这个。喵喵CRM上是使用JWT的Token认证的。看起来似乎很简单，只要这个用户登陆了，我们给他个Token，每次请求他带着这个Token访问就行。
但是，考虑一个问题，Token是有时限的。假如一个用户刚刚申请到Token，但是下一秒这个用户因为某些原因被剔除了，实际上我们期望这个用户立马就不能访问了，但是因为Token的原因，这个用户还可以在时限内访问系统的很多数据。而如果换一种方式，Token 只是一个索引，真正的用户状态存储在服务端（例如 Redis）。这样的话，token 本身没什么价值，只有和 Redis 里的状态匹配上才算数。这时候随便踢人、改权限，Redis一更新，全局就生效了。
另外，假如喵喵CRM做大做强了，可以部署到多台服务器上了，这时候用Redis共享session，不管用户的请求落到哪台服务器，token 都能查到同一个状态，体验一致。如果用Django默认的session，用户A登录到服务A，就只能一直打到A上。换一台机器就找不到session了（唔，有点类似于状态云同步）
（3）实时统计，好吧，这我是没想到的……点赞计数、在线人数统计也会放到Redis里面。可是不就是写个变量就能存储吗？为啥也要用Redis？在真实的服务部署中，往往有多个应用进程，甚至多台服务器。如果只在某个进程里用一个变量存点赞数：其他进程/服务器看不到这个数据。用户访问不同节点时，计数就会不一致。至于为啥不放到数据库一类的……我想这种高频的数据读写，数据库估计能给访问到爆炸吧。而且Redis可以提供RDB快照和AOF日志，宕机了数据也不会丢；还提供原子自增INCR/ZINCRBY操作，能在百万级并发下保证正确性。
（4）消息队列，轻量级（为啥轻量级呢？因为Redis本身就不是干消息队列的，只不过速度快、实现简单，所以有些简单场景就用Redis了），消息队列就是两个模块之间本来直接对接，比如下单——写入库存，但是直接对接强耦合+同步执行，一旦有个操作慢了或者挂掉，另一个操作也会受到影响。而通过消息队列，上游把任务丢到队列里，下游慢慢拿任务去处理就行。适用场景：异步任务、秒杀队列、日志收集等等。
（5）高并发控制（分布式锁、限流器），抢购场景，库存 100 件。上万个人同时点“立即购买”，单机程序里很简单，但分布式系统里有很多节点，光靠本地锁不管用。Redis 可以用来当“大家都能访问的锁”。每个下单请求先抢锁，抢到才继续扣库存。没抢到就排队或直接提示“售罄”。限流则是防止恶意访问，比如短信验证接口固定计数器，设置60秒过期，短时间内过多请求就拒绝。