Redis做缓存那点事儿，性能咋样能更牛逼一点

说到用Redis做缓存,咱们都希望它越快越好，别成为系统的瓶颈，想让Redis更“牛逼”，不能光靠堆硬件，得从设计和使用方法上多下功夫，这事儿就像开车，好车固然重要，但老司机的驾驶技巧和保养习惯更能决定你能跑多快、跑多远。

第一点，也是最重要的一点：别让Redis干它不擅长的事。 Redis的快，是基于它把所有数据都放在内存里操作，任何可能让Redis卡顿、耗时的操作都要尽量避免，最典型的就是执行时间过长的命令，在没有设置合理上限的情况下，用keys *这个命令去模糊匹配所有键，或者对一个包含几十万成员的集合进行hgetall或smembers操作，这相当于让Redis一次性吐出海量数据，它会瞬间阻塞，其他所有请求都得等着，性能断崖式下跌就来了，正确的做法是，用scan系列命令代替keys，它虽然慢一点，但是分批次执行，不会阻塞；对于大集合，可以考虑用hscan、sscan分页获取，或者干脆想想业务上是不是真的需要一次性拿全量数据。

第二点，把好数据入库的关口，优化存储结构。 存进去的东西合理，取出来才高效，有个很实用的技巧叫“小数据聚合”，要存储用户的个人信息（姓名、年龄、城市等），你别用好几个独立的set user:123:name "张三"、set user:123:age 30这样的键值对，而是应该用一个哈希（Hash）结构hmset user:123 name "张三" age 30 city "北京"，这样一个键就搞定了，不仅节省了大量键本身的元数据开销，而且在网络传输上也更高效，这就是所谓的“批量化”思想，减少网络往返次数，对于不重要的数据，可以考虑启用压缩，用一点CPU时间换网络带宽和内存空间，也是划算的。

第三点，规划好缓存的失效和淘汰策略，防止缓存被“撑爆”。 内存是有限的，数据是无限的，当内存快满的时候，Redis要根据你设定的maxmemory-policy来淘汰数据，默认的noeviction策略是直接报错，这肯定不行，常用的有allkeys-lru（最近最少使用的键被淘汰）或volatile-lru（只在设了过期时间的键中淘汰），选择哪个要看业务：如果所有数据都是缓存，丢了可以从数据库再捞，那就用allkeys-lru；如果有些关键数据你想永久保存，就给它们设一个很长的过期时间或者不设，然后用volatile-lru，千万别让数据无限制地增长，最后Redis内存满了开始频繁淘汰，性能会剧烈波动。

第四点，活用Pipeline和连接池，减少“废话”时间。 Redis是单线程处理命令的，但它处理得非常快，瓶颈往往出现在网络IO上，如果你要连续执行10个get命令，发10次请求、收10次响应，其中9次网络延迟都是浪费，用Pipeline（管道）可以把一堆命令打包，一次性发过去，Redis一次性执行完再一次性把结果返回，能极大提升批量操作的性能，连接池也是类似道理，避免每次操作都建立新的TCP连接，那个开销很大，保持一批“常驻”连接，随用随取，用完放回，效率高得多。

第五点，架构层面的考量：读写分离与持久化权衡。 当读压力特别大的时候，可以搭建Redis主从复制（Replication）架构，主库负责写，多个从库负责读，把流量分散开，这叫水平扩展读能力，Redis提供了RDB和AOF两种持久化方式，保证数据安全，但持久化本身是有代价的，RDB做快照时可能会短暂阻塞，AOF频繁刷盘也会影响性能，要根据业务对数据丢失的容忍度来配置，可以配置为每秒同步一次AOF，这样最多丢一秒的数据，但对性能的影响相对较小，如果追求极致性能且能容忍重启后数据丢失，甚至可以关掉持久化，但这就非常冒险了，通常不推荐。

第六点，监控和慢查询分析不能少。 你都不知道哪里慢，怎么优化？一定要开启Redis的慢查询日志（slowlog），它会记录下执行时间超过阈值的命令，定期检查慢查询日志，就像定期给系统做体检，能发现很多不经意的性能杀手，用info命令查看内存使用情况、连接数、命令统计等信息，对Redis的健康状况做到心中有数。

让Redis性能更牛逼,核心思想就是“扬长避短”：充分发挥其内存操作的极致速度，同时通过合理的数据结构设计、命令使用、架构规划和监控手段，避免网络IO、阻塞操作、内存瓶颈等因素拖后腿，它是个好工具，但能不能发挥出最大威力，全看用工具的人。