Redis调优那些事儿，教你一步步搞定高性能缓存系统

综合自互联网多位技术博主如“程序员小灰”、“架构师之路”以及Redis官方文档的实践建议）

Redis调优那些事儿,教你一步步搞定高性能缓存系统

想把Redis用得更溜,让它跑得又快又稳？光会简单的set和get可不够，调优这事儿，就像给汽车做保养，得从里到外都照顾到，下面我就用大白话，一步步跟你说说Redis调优的那些关键点。

第一步：别让内存成为“火药桶”

Redis是把所有数据都放在内存里的,所以内存管理是头等大事，内存用满了，Redis可就罢工了。

• 设置最大内存：一定要在配置文件（redis.conf）里设置maxmemory参数，告诉Redis最多能用多少内存，比如你服务器有8G内存，可以分6G给Redis，留2G给系统和其他程序，别让它吃光所有资源。
• 制定淘汰策略：当内存快满的时候，新数据进来，老数据怎么办？这就是淘汰策略，默认是noeviction（不淘汰，直接报错），这在生产环境很危险，常用的策略有：
  • allkeys-lru：尝试淘汰最近最少使用的键，不管它有没有设置过期时间，这是最常用的策略，比较公平。
  • volatile-lru：只从设置了过期时间的键中淘汰最近最少使用的。
  • allkeys-random：随机淘汰所有键。 根据你的业务特点选，比如如果缓存的数据热度差别很大，用allkeys-lru效果就很好。

第二步：让数据持久化“恰到好处”

为了防止断电丢数据,Redis提供了两种“存盘”方式：RDB和AOF。

• RDB（快照）：就像给数据库拍一张完整的照片存起来，优点是恢复速度快，文件小，缺点是可能会丢失最后一次快照之后的数据（比如5分钟拍一次，服务器在第4分钟59秒挂了，这5分钟的数据就没了）。
• AOF（日志）：把每一个写命令都记下来，优点是数据安全，最多丢失1秒的数据（如果配置为每秒同步一次），缺点是文件会越来越大，恢复速度慢。
• 怎么选？ 通常的做法是两者都开启，用AOF来保证数据不丢失，用RDB来做冷备份和快速恢复，在配置文件里把appendonly改成yes，并调整appendfsync为everysec（每秒同步一次），这是个兼顾性能和安全的折中方案。

第三步：堵住性能“漏水点”

有时候Redis变慢,不是它本身的问题，而是你的用法不对。

• 警惕“大Key”：一个字符串Key的值有几百KB甚至几MB，一个列表里有几十万元素，这都是“大Key”，它们会拖慢查询速度，特别是在做持久化、网络传输时，很容易阻塞其他请求，解决办法是拆分大Key，比如把一个大的HashMap拆成多个小的；或者用其他数据结构，比如用HyperLogLog来代替存储巨大唯一值的集合。
• 避免“慢查询”：有些命令天生就慢，比如keys *，它会遍历所有键，数据量一大就直接卡死，排查线上问题要用scan命令代替，还有，对一个大集合执行hgetall、smembers也可能很慢，应该用hscan、sscan或者只获取需要的字段。
• 禁用长耗时的命令：在生产环境，可以直接在配置里用rename-command把keys、flushdb等危险命令重命名成一个复杂的字符串，甚至直接禁用，防止误操作。

第四步：网络与配置“精雕细琢”

• 合理设置超时时间：给缓存数据设置过期时间（TTL），这不仅是业务需要（保证数据不过时），也能让Redis自动清理不再需要的数据，释放内存空间，不要一股脑都设置成永不过期。
• 使用连接池：你的应用程序连接Redis，不要每次操作都创建新连接，连接和断开很耗资源，一定要用连接池，复用连接。
• 关注内存碎片：Redis用久了，删删改改，内存里会产生很多小空隙，就像磁盘碎片，可以通过info memory命令查看mem_fragmentation_ratio（内存碎片率），如果这个值长时间远大于1.5，可以考虑重启Redis实例或者使用Redis 4.0以上版本的memory purge命令（如果支持）来主动清理碎片。

第五步：升级你的“武器库”

如果单机的Redis性能已经到了瓶颈,就要考虑扩展了。

• 主从复制：一台主库（Master）负责写，多台从库（Slave）负责读，这样可以做读写分离，提升读性能，同时从库还能作为主库的备份。
• Redis集群：当数据量巨大，一台机器内存装不下时，就需要用集群，Redis集群把数据分片存储在多个节点上，这样就能突破单机内存限制，同时性能也成倍增长。

Redis调优是个系统工程,没有一劳永逸的银弹，你得先从最重要的内存、持久化入手保证稳定性，然后优化使用方式避免性能陷阱，最后再根据业务增长考虑架构扩展，平时多使用info命令看看Redis的状态，做到心中有数，这样才能真正搞定一个高性能的缓存系统。