Redis结合DB2用法大揭秘，性能提升真不是吹的，数据库快得飞起

前段时间我在做一个项目,用户量突然暴增，原本老老实实直接查DB2数据库的系统，一下子变得慢吞吞的，用户抱怨连连，页面加载个数据要转半天圈，后台的DB2服务器CPU都快飙到顶了，我们团队急得团团转，试了各种优化SQL语句、给数据库加索引的办法，效果都不太理想，后来，我们组里一个资深大哥提出了引入Redis的方案，这一用上，效果简直是立竿见影，数据库的压力骤减，系统速度快得飞起，今天我就把这套“组合拳”的用法揭秘一下，保证都是用大白话讲清楚。

（来源：项目实战经验）

第一招：用Redis给DB2当“前台”，挡住大部分询问。

你可以把DB2数据库想象成公司仓库里最博学的老专家,他什么数据都知道，但年纪大了，每次有人来问问题，他都要翻半天账本才能回答，很耗费精力，而Redis呢，就像是坐在公司门口的一个超级机灵的前台小哥，他记性特别好。

我们当时最典型的场景就是用户登录后查看自己的基本信息,以前每次用户点开“我的主页”，程序就直接跑去问DB2老专家：“编号123的用户信息是啥？”老专家就得吭哧吭哧地去庞大的用户表里找，哪怕只有0.1秒，也架不住每秒成千上万人同时问啊。

用了Redis之后,流程就变了，用户第一次点开“我的主页”时，程序还是会去问DB2老专家，拿到用户信息后，不仅返回给用户，还会顺手复制一份交给Redis前台小哥，并且告诉他：“这条信息你先帮我记着，有效期设成30分钟。”下次再有同一个用户（比如还是编号123）来问信息时，程序会先跑去问门口的Redis小哥：“嘿，你记得编号123的信息吗？”Redis小哥记性超好，瞬间就能把数据拿出来，只有在Redis小哥那里找不到（我们称之为“缓存未命中”），程序才会去打扰DB2老专家。

这样一来,DB2老专家一天下来被询问的次数可能连以前的十分之一都不到，自然就轻松了，整个系统的响应速度也因为大部分请求被Redis快速响应而变得极快，这招专门对付那些读得多、写得少，并且数据不是时刻在变的信息，效果最好。

（来源：基于缓存经典模式“Cache-Aside”的实践）

第二招：用Redis存“热点数据”，减轻DB2“扛大旗”的压力。

我们的项目里有个热门商品排行榜,每分钟都要根据销量更新一次，如果每次都直接去DB2里GROUP BY、SUM、ORDER BY，那这个查询对DB2来说就是个沉重的负担，尤其是在高峰期。

我们的做法是,不在DB2里直接算这个排行榜，每当有一笔订单成交，更新完DB2里的核心数据后，我们同时会在Redis里对一个叫“商品:123:销量”的键进行增加操作，Redis处理这种简单的加减计算速度是微秒级的，非常快，到了需要展示排行榜的时候，程序直接让Redis把所有商品的销量数据拿出来，排个序，前十名就是热销榜了，这个复杂的计算过程完全由Redis承担了，DB2只需要安心处理最核心的交易记录存储，分工明确，效率倍增。

这就好比,原来所有杂活累活（包括计算排行榜这种重体力活）都让DB2老专家一个人干，现在好了，我们把计算销量排名这种重复性的体力活交给了精力旺盛的Redis小伙计，老专家只需要做最关键的数据归档工作。

（来源：利用Redis高性能计数器和排序功能应对热点查询）

第三招：用Redis当“临时笔记本”，记下琐事不烦主库。

还有些数据,没必要永久保存在庄重的DB2里，比如用户登录后生成的会话信息（Session），或者短信验证码、页面临时缓存等，这些数据有个特点：有时效性，过一段时间就没用了。

以前这些数据也都往DB2里塞,导致DB2里充满了各种短期无效数据，就像一本正经的账本上画满了临时草稿，看着都乱，现在我们都把它们存到Redis里，并设置好过期时间，比如验证码存5分钟，5分钟后Redis自动就把它删了，用户Session存一天，一天不登录自动失效。

这样做的好处是,DB2的表格变得更“干净”了，只存放真正需要长期保留的核心业务数据，体积更小，查询和维护起来也更高效，Redis则完美发挥了它处理临时、快速数据的特长。

（来源：Redis在会话存储和临时数据管理中的常见应用）

说白了,Redis不是要取代DB2，而是给它找了一个能力互补的黄金搭档，DB2就像硬盘，数据安全可靠，是最终的家；Redis就像内存，速度极快，是干活的前沿阵地，把经常要用的、临时的、计算量大的活交给Redis，让DB2专注于保证数据持久化和处理最核心的复杂事务，这个组合用好了，数据库性能提升真不是吹的，说“快得飞起”一点都不过分，用的时候也要注意数据一致性、缓存雪崩等问题，但那又是另一个话题了，希望我们这套实战经验对你有启发。