用Redis来管信息，效率蹭蹭往上涨，管理系统也更顺手了

以前我们那个管理系统,一碰上用户多、数据量大的时候，就有点卡壳了，特别是像用户登录状态啊、一些经常要变的临时数据啊，老是往数据库里存了又取，取了又存，数据库都快被这些零碎的小操作给折腾坏了，页面加载也慢，用户体验挺不好的，后来我们琢磨着，得找个专门对付这种高频小数据的帮手，就引入了Redis，这一用上，好家伙，感觉整个系统都活络了，效率真是蹭蹭往上涨，管理起来也顺手多了。

最明显的改善就是用户登录这块儿,以前用户登录，系统得去数据库核对用户名密码，成功后就生成一个会话标识（Session ID），这个标识和用户的信息也得存到数据库的一张表里，用户之后每次点开新页面，系统都要拿着这个标识去数据库里查一下，看看是不是有效的、用户是谁，人少的时候没啥，一旦同时在线的人多了，数据库光是处理这些反复的查询请求就压力山大，有时候页面跳转就能感觉到明显的延迟，用了Redis之后，我们就变了法子，用户登录成功后，我们把那个会话标识和对应的用户信息，比如用户ID、昵称啥的，直接当成一个键值对存到Redis里面，并且给这个数据设置一个过期时间，比如半小时，之后用户再访问，系统就直接从Redis里拿这个会话信息，速度特别快，因为是直接读内存，比去硬盘上找数据库快了好几个数量级，数据库一下子轻松了，页面的响应速度也立马提上来了，用户感觉就是点了就能开，特别流畅。

一些经常需要显示、但又时不时会变动的数据，比如网站的总访问量、某个热门商品的当前库存数、或者是一些需要快速更新的排行榜，这些数据如果每次都实时去数据库计算或者查询，对数据库来说是挺重的负担，我们现在把这些数据也放到Redis里，比如总访问量，每次有人访问网站，我们就在Redis里把一个对应的数字加1，这个操作Redis处理起来飞快，而且非常可靠，我们要在网页上显示这个访问量的时候，直接从Redis里把这个数读出来就行，简单直接，速度没得说，再比如搞个限时秒杀活动，商品库存就那么点，成千上万人同时来抢，要是库存扣减的逻辑完全交给数据库处理，很可能因为同时请求太多而卡死或者出错，我们现在的做法是，先把商品库存数量预先加载到Redis里，用户抢购时，直接通过Redis的原子操作来扣减库存，Redis能保证在同一时间只有一个请求能成功扣减，避免了超卖的问题，而且这个判断和扣减的过程极快，能扛住非常高并发的请求，活动搞得再火爆，系统也稳得住。

Redis自带的数据过期功能也帮了我们大忙,比如我们系统里有很多短信验证码或者邮件验证链接，这些信息都是有时效性的，一般几分钟或者几小时后就失效了，以前得写个定时任务，隔一段时间就去数据库里扫描一遍，把过期的记录删掉，挺麻烦的，现在直接存Redis，设置好三五分钟的过期时间，时间一到，Redis自己就把它清理掉了，我们完全不用操心，省事又不会出错。

还有像消息队列这种需求,我们也能用Redis简单实现，比如用户注册成功后，系统需要给他发个欢迎邮件，这个发邮件的操作比较耗时，如果放在用户点击注册的那个请求里一起处理，用户就得等着邮件发出去才能看到注册成功的提示，体验不好，我们现在是，用户注册的核心信息存数据库后，就把一个“需要发送欢迎邮件”的任务内容，作为一条消息放进Redis的一个列表结构里，然后有一个专门发邮件的后台服务，不停地从这个列表里取任务出来处理，这样注册流程就变得非常快，用户立马就能得到反馈，发邮件的事儿交给后台慢慢做就行了，系统各部分之间配合得更协调了。

把Redis引入到我们的管理系统,就像是给系统请了一个手脚特别麻利、记性特别好的专职助理，它把那些最琐碎、最频繁、最要求速度的数据处理活儿全都揽了过去，让数据库可以专心处理更重要、更复杂的核心业务数据，系统整体的响应速度因此快了很多，运行更稳定，能同时服务更多的用户，我们运维管理起来，也感觉省心了不少，确实更顺手了。