原生redis到底有多能打，性能表现和实际使用感受聊聊

说到原生Redis的性能,我自己的感受就一个字：快，快到离谱的那种快，这可不是我瞎吹，是有实实在在的场景背书的，我记得以前在公司做一个小型电商项目，用户登录后的会话信息，也就是Session，最开始是存在数据库里的，每次用户点一下页面，哪怕只是看看商品列表，后台都要去数据库查一下这个用户是谁，有没有登录，平时用户少还好，一到做活动，比如秒杀或者发优惠券，数据库直接就扛不住了，页面卡得不行，用户抱怨连天。

后来技术负责人拍板,把Session挪到Redis里，这个改动其实不大，就是换了个存东西的地方，但效果是立竿见影的，最直观的感受就是，网站好像突然“轻”了，页面跳转几乎没有延迟，以前那种点击后转圈圈的情况少了很多，后台数据库的压力也一下子降了下来，CPU使用率从经常性的七八成掉到了二三十，这就是我第一次被Redis“能打”的性能震撼到，这种快，不是那种需要精密测试仪器才能测出来的快，是用户和开发者都能明显感觉到的流畅。

那它为什么能这么快呢？根据Redis官方文档和一些技术博主的分析，比如一位网名叫“程序员囧辉”的作者在他的文章里就详细拆解过，主要原因有几个，第一，Redis把所有数据都放在内存里操作，内存的读写速度比硬盘快了几个数量级，这就好比从你手边拿一本书和跑去图书馆书架上找一本书的区别，速度根本不是一个级别的，第二，Redis是单线程架构，听起来好像单线程是缺点，但恰恰相反，这避免了多线程之间为了争抢资源而带来的复杂性和性能开销（也就是上下文切换），它用一个线程高效地处理所有请求，非常简洁，第三，它用了非常高效的数据结构，比如它的哈希表、跳表这些，都是为速度而生的。

在实际使用中,光有“快”是不够的，还得“稳”，Redis在稳定性上也特别能打，我们当时用它来做缓存，设置一个过期时间，比如用户登录信息保存30分钟，Redis就会像闹钟一样准时，时间一到自动就把数据删了，非常可靠，从没出过岔子，我们还用它做过一个简单的消息队列，比如用户下单后，不是马上扣库存，而是把订单信息往Redis的一个列表里一放，然后由后台服务慢慢去处理，这种方式在高并发时特别好用，能把瞬间的流量洪峰“削平”，避免系统被冲垮，Redis在这种场景下表现得非常稳定，吞吐量极大，几乎没出现过丢消息的情况。

原生Redis也不是没有弱点,最大的问题就是“内存贵”，因为所有数据都放在内存里，所以能存的数据量受限于你的机器内存大小，不像数据库，几个T的硬盘也没多少钱，所以我们当时定了个规矩，只把那些最热、最需要快速访问的数据放Redis里，比如用户会话、热门商品信息、排行榜之类的，那些不常用的、历史数据，还是老老实实放回数据库，虽然Redis有持久化功能（就是把内存数据定期写到硬盘上做备份），防止断电后数据全丢，但配置起来还是需要一些心思的，不像有些数据库开箱即用那么省心。

我的实际使用感受是,原生Redis就像一个天赋异禀的“短跑冠军”，在它擅长的领域——高速读写、简单数据结构、高并发——几乎找不到对手，它能极大地提升应用的响应速度，给用户带来流畅的体验，并且非常稳定可靠，但它不适合存储海量冷数据，也不能处理复杂的查询关系，用对场景，它就是一把无往不利的神兵利器；用错了地方，反而会成为一种负担，了解它的特性，把它用在刀刃上，才能真正发挥出它“能打”的实力。