风之用法聊聊Redis那些神奇的地方，winds和redis的故事还没说完

来源于网络作者“风之用法”的分享，主要围绕其使用Redis的心得体会）

风之用法聊聊Redis那些神奇的地方,winds和redis的故事还没说完，这个故事啊，得从一个最简单的需求开始，那时候，我还是个新手，觉得数据库嘛，不就是存东西和取东西，我的项目叫“winds”，一个挺小的应用，最开始，用户登录后的信息，我都老老实实地放在MySQL里，每次用户点一下页面，我的winds就得跑去问MySQL：“这个用户是谁？有权限吗？” MySQL就像个动作有点慢的老管家，虽然可靠，但每次都要翻半天账本，尤其是人一多，winds就感觉有点喘不过气来，页面打开的速度也慢了下来。

后来,我听说了Redis，说它特别快，能把数据放在内存里，我一开始的想法特别简单，就觉得它是个“快一点的缓存”，我在winds和MySQL之间，请来了Redis这位“闪电侠”，用户第一次登录，winds还是得去麻烦MySQL老管家，但拿到用户信息后，winds会麻利地复制一份，交给Redis保管，并告诉它：“这个信息，你先帮我拿300秒。”接下来的299秒里，再有请求来问这个用户是谁，winds就直接找Redis了，Redis就在内存里，几乎是瞬间就能给出答案，就这么一个小小的改变，winds整个应用感觉就像卸下了沉重的包袱，轻快得能飞起来，这是我第一次感受到Redis的神奇，它用一种近乎直白的方式，解决了最迫切的性能问题。

但风之用法和redis的故事,这才刚刚开始，如果只把它当缓存，那可真是大材小用了，winds后来需要做一个文章点赞的功能，最开始，我的思路还是老一套：在数据库里有一张点赞表，谁点了哪篇文章，就插一条记录进去，取消点赞，就删掉这条记录，要统计一篇文章有多少赞，就去数一下这张表里有多少条记录，这个方法，在只有几个用户的时候没问题，可一旦火了，一篇文章可能有几千几万个赞，每次显示文章都要去数据库里数一遍，MySQL老管家非得累趴下不可。

这时候,我想起了Redis的另一个神奇法宝——数据结构，Redis不像MySQL，只有简单的表，它肚子里有好多宝贝数据结构，对于点赞这个场景，Redis的Set（集合）简直是天作之合，我可以为每一篇文章创建一个Set，它的名字就叫“article:123:likes”（假设123是文章ID），每当有一个用户点赞，winds就执行一个简单的命令“SADD”，把这个用户的ID扔进这个Set里，取消点赞呢，就用“SREM”命令把用户ID拿出来，最妙的是，想知道这篇文章总共有多少赞，根本不用去“数”，直接一个“SCARD”命令，Redis瞬间就告诉你这个Set里有多少个元素，也就是点赞数，这个操作的时间复杂度是O(1)，意思是无论Set里有一万个用户还是十万个用户，查询速度都是一样快！这对于winds来说，简直是魔法，它不再需要频繁地打扰MySQL，所有的点赞操作和计数都在Redis内部以光速完成。

再后来,winds要做一个排行榜功能，比如一周热文排行榜，这要是用MySQL来做，得写多么复杂的SQL语句啊，还得考虑时间范围，性能想想都头疼，Redis又一次展现了它的神奇，它有一个叫ZSet（有序集合）的数据结构，我可以把文章ID作为成员，把点赞数、阅读量或者一个综合热度分数作为分值（score）存进去，只需要一个命令，ZREVRANGE”，winds就能瞬间取出分数最高的前十篇文章，完美生成排行榜，当文章的热度分数发生变化时，ZSet会自动维护顺序，winds根本不用操心排序的事情。

风之用法还提到,Redis的List（列表）结构帮winds实现了简单的消息队列，比如用户注册成功后，要发欢迎邮件和初始化一些数据，这些任务不要求实时完成，winds就把这些任务包装成一个消息，用“LPUSH”命令推进Redis的一个List里，然后另外一个专门处理任务的程序，用“RPOP”命令从另一边慢慢地取出来执行，这样，用户注册的主流程就能飞快地返回结果，不会被发邮件这种慢操作拖累，这种解耦和异步的能力，让winds的架构变得更清晰、更健壮。

winds和redis的故事真的还没说完,从最初一个简单的缓存工具，到后来处理点赞、排行榜、消息队列，Redis就像一个多啦A梦的四次元口袋，总能掏出合适的工具来解决winds成长中的烦恼，风之用法最后感慨道，Redis的神奇之处不在于它有多少高大上的概念，而在于它用一系列简单、直接、高效的数据结构和命令，实实在在地解决了分布式系统中最常见的那些痛点，它让像winds这样的应用，能够轻松应对高并发，实现复杂的功能，而无需一开始就构建极其复杂的架构，这大概就是为什么Redis能如此受欢迎的原因，它的魅力，需要在实际的摸爬滚打中，像风之用法一样，一点点去发现和体会。