新浪用Redis搞了个技术方案，性能啥的听说挺不错，挺有意思的

我听说的事儿大概是这样的,新浪微博嘛，你知道的，用户好几亿，每天大家刷刷刷、发发帖、点点赞、转转评，那个数据量海了去了，尤其是像明星出轨、社会热点这种大事件一出来，瞬间就有几百上千万人同时涌进来，服务器要是顶不住，分分钟就得瘫痪。

他们为了解决一个特别具体但又非常要命的问题,就是用Redis搞了个挺巧妙的方案，这个问题就是“计数”，啥计数呢？就是每条微博下面显示的那个转发数、评论数、点赞数，你可别小看这几个数字，觉得它不就是个数字嘛，但对微博来说，每秒钟都有天文数字般的点赞和取消点赞的操作，如果每次有人点赞，都直接去更新那个存在核心数据库（比如MySQL）里的最终数字，那数据库根本受不了，磁盘读写会忙到冒烟，速度也跟不上。

所以呢,新浪的工程师就想了个办法，叫“缓存+持久化”结合的策略，这个说法可能有点专业，我用人话给你讲讲是咋回事。

核心思路就是：先把快速的变动“攒起来”，再找个清闲的时候“一笔一划”地记到账本上。

具体他们是怎么用Redis来“攒”这些数的呢？（根据网络上技术社区如“知乎”上一些新浪工程师的分享和行业分析文章所述）大概分几步：

1. 前端拦截，Redis当临时仓库： 当你在手机上给一条微博点了个赞，这个请求并不会直接冲到后面那个又大又重的核心数据库里去，而是先被一个超级快的“临时仓库”——也就是Redis——给接住了，Redis是那种把所有数据都放在内存里的数据库，读写速度飞快，比读写硬盘的传统数据库快太多了，它就像一个身手敏捷的接待员。
2. 在Redis里“写正字”： 这个接待员（Redis）收到你的点赞指令后，它不会急着去翻找那条微博的总点赞数然后做加法，它干的事儿更取巧：它为每条微博都准备了一个“计数器”，你这个点赞操作过来，它就在这个微博对应的计数器上简单地“+1”，如果过了一会儿你又取消了点赞，它就“-1”，这个过程极其快速，因为只涉及内存里一个数字的加减，所有的实时变化，都先以这种“增量”的形式记录在Redis里，这时候，显示在你手机上的那个点赞数，其实是从Redis这个临时仓库里查出来的最新结果，所以你觉得速度很快。
3. 定期把“账本”誊写清楚： 光在临时仓库里写正字不行啊，万一Redis服务器重启了，内存里的数据丢了咋办？所以得定期把结果同步到那个可靠的、能永久保存数据的核心数据库（MySQL）里，但他们不是有一点变动就同步一次，那样又回到老路了，他们是设定一个时间间隔，比如每隔一段时间（可能是几分钟），或者当这个“增量”累积到一定数量时，才把Redis里攒下来的那个总变化量（50），一次性更新到MySQL里那条微博的最终计数上。 这就好比，餐厅服务员先用小本本记下每一桌点了什么菜（快速记录），等一桌客人点完了，他再一次性把单子送到后厨（更新总账），而不是客人点一个菜，他就跑一趟后厨。

这个方案妙在哪呢？

• 速度快极了： 绝大部分的用户操作（99%以上）都只在飞快的Redis内存里完成，用户感觉不到任何卡顿。
• 保护了核心数据库： 数据库的压力从每秒可能百万次的实时更新，降到了每分钟几十或几百次的批量更新，一下子轻松了无数倍，保证了整个系统的稳定。
• 数据最终是对的： 虽然MySQL里的数字可能比Redis里的稍微延迟几分钟同步，但最终数据会保持一致，对于点赞数、转发数这种不需要绝对实时精确（晚几分钟看到最终准确数字，用户完全能接受）的场景，是完美的权衡。

我听说,新浪用这个基于Redis的方案之后，很好地扛住了各种明星八卦热点带来的流量洪峰，那些数字蹭蹭往上涨，但系统稳得很，这个事儿在技术圈里被聊得很多，因为它不是用了什么特别高深莫测的新技术，而是用了一个很普遍的工具（Redis），通过一个非常巧妙的架构设计思路，就四两拨千斤地解决了一个世界级的难题，所以大家都觉得挺有意思，挺受启发的，说白了，有时候好的方案不在于用多牛的武器，而在于怎么巧妙地使用它。