微博点赞用Redis真方便，速度快还省心，秒变高效点赞神器

“微博点赞用Redis真方便，速度快还省心，秒变高效点赞神器”这个说法，最早我是在一个程序员的技术博客里看到的，当时博主在分享他们团队如何优化微博点赞功能的技术方案，通篇看下来，给我的感觉就是，Redis这东西，简直就是为这种高频、瞬发的操作量身定做的。

在没有用Redis之前,博主提到他们遇到的老大难问题就是数据库的压力，你想啊，微博动不动就几万、几十万甚至上百万的点赞，每次用户点一下赞，后台就要去数据库里找到那条微博对应的记录，然后把点赞数加一，再写回去，这还只是点赞，要是取消点赞，还得再减一，一来一回，全是数据库的读写操作，平时可能还好，一旦有个大V发了条爆款微博，或者赶上什么热点事件，点赞的请求就像潮水一样涌过来，数据库服务器立马就喘不过气来了，轻则点赞延迟，用户点了赞半天数字都不动，重则直接把数据库搞挂掉，整个功能都用不了，用户可不管后台发生了什么，他们只会觉得“这App怎么这么卡，体验太差了”。

后来,他们团队引入了Redis，情况就完全不一样了，博主用了一个特别形象的比喻，说这就好比以前所有买票的人都要挤到火车站唯一的售票窗口排队（关系型数据库），现在呢，在每个人口密集的小区门口都设了无数个自动售票机（Redis），你想买票（点赞），下楼在机器上“哔”一下就好了，瞬间完成，根本不用大老远跑去火车站排长队。

具体是怎么做的呢？博客里说得很直白，他们主要用了Redis的两种数据结构，第一种是字符串（String），用来存每个微博帖子的总点赞数，比如微博ID是12345，那在Redis里就存一个键叫 weibo:like:count:12345，它的值就是当前的总点赞数，当有点赞或取消点赞请求过来时，直接在这个键的值上进行加减操作，因为Redis的所有数据都在内存里，这种简单的加减速度极快，是硬盘读写完全没法比的。

但光有总点赞数还不够,还得防止用户重复点赞对吧？这时候就用上了第二种数据结构——集合（Set），他们为每一条微博都创建了一个Redis集合，集合的名字比如叫 weibo:like:users:12345，这个集合里存放的就是所有给这条微博点过赞的用户ID，当用户点击点赞按钮时，后台会先检查这个用户的ID是否已经在这个集合里了，如果不在，说明是第一次点赞，那就执行两个操作：一是把用户ID加到这个小集合里，二是给那个存总点赞数的键的值加一，这两个操作Redis可以保证原子性（虽然博主文章里没提这个词，但意思就是保证这两个动作要么都成功，要么都失败，不会出现加了用户ID但点赞数没加的这种混乱情况），如果发现用户ID已经在集合里了，那这次点击就视为取消点赞，就从集合里移除用户ID，同时总点赞数减一。

你看,这么一个看似复杂的逻辑，在Redis里其实就是一两条指令的事情，而且全在内存里完成，速度自然快得飞起，博主还特别提到，他们根本不需要用户一点赞就立刻去更新后台那个“火车站售票窗口”（关系型数据库），他们可以每隔一段时间，比如一分钟或者五分钟，把Redis里积累的点赞数量变化，一次性批量更新到数据库里就行了，这样一来，数据库的压力就被降到了最低，再也不用担心被点赞请求“冲垮”了。

所以回过头看“微博点赞用Redis真方便，速度快还省心，秒变高效点赞神器”这句话，真是一点都不夸张，它解决的不仅仅是技术层面的性能瓶颈，更重要的是提升了最直观的用户体验，用户点了赞，数字立刻就有反馈，这种流畅感对留住用户来说至关重要，而且对于微博这样亿级用户量的平台来说，每一个细微体验的优化，乘以庞大的用户基数，带来的效益都是巨大的，那个博主在文章最后也感慨，说选择合适的工具真的太重要了，用对了工具，原本让人头疼的难题，可能就迎刃而解了，Redis在点赞这个场景下，确实当得起“神器”这个称呼。