Redis怎么配才快点，性能优化那些事儿聊聊吧

把Redis放在内存里，而且要让内存够大。

这话听起来像是废话，但关键点在于“内存够用”和“内存不够用”是天壤之别，Redis最快的操作都在内存里完成，如果你的内存太小，数据装不下，Redis就会启动一个叫“逐出”的机制，就像你的衣柜满了，要扔掉一些旧衣服才能放新的，这个“扔”的动作（写入磁盘）和后续从磁盘里再把需要的数据“捡回来”（读取磁盘），会比直接操作内存慢成百上千倍。根据“Redis官方文档”的建议，一定要确保你的内存大小足够容纳你的数据集，并且预留一些余量（比如20%-30%），避免频繁发生内存逐出,这是保证高速访问的基石。

别让CPU成了瓶颈，关键是优化数据结构和命令。

Redis是单线程的，这话你得这么理解：它就像一个只有一个收银台的超市，所有顾客（客户端请求）都得排队，如果一个顾客买了整整一购物车的东西，要算半天账，后面的人就得等很久,优化之道就是让每个顾客买东西都快一点。

• 避免使用“慢查询”命令，有些命令天生就比较慢，比如获取一个超长列表里所有元素的 LRANGE key 0 -1，或者对一个大集合进行KEYS *操作（这个命令甚至会阻塞其他所有请求！）。**根据“Redis官方文档”列出的慢命令清单**，我们应该用SCAN系列命令代替KEYS，用HSCAN` 代替一次性获取大哈希的所有字段,分批处理。
• 使用高效的数据结构，Redis提供了几种节省内存的数据结构，ziplist，当你的哈希（Hash）对象里字段不多，或者列表（List）里元素不长时，Redis在底层会用 ziplist 来存储，这比用标准的哈希表要省内存，CPU缓存利用率更高，自然就快了，这些转换的阈值是可以在配置文件里调的，hash-max-ziplist-entries 和 hash-max-ziplist-value。根据“《Redis设计与实现》”这本书里的解释，合理设置这些参数,能在性能和内存之间找到很好的平衡点。
• 管道（Pipeline）打包命令，还记得单线程收银台的例子吗？管道就像是你让朋友帮你一起把要买的东西都拿到收银台，然后一次性结账，客户端可以把多个命令打包成一个请求发送给Redis，Redis处理完后再一次性返回结果，这极大地减少了网络往返的时间，对于需要连续执行多个操作的场景，性能提升非常明显。“Redis创始人antirez在他的博客中” 多次强调,使用管道是降低延迟的有效手段。

网络和持久化配置也是速度的关键。

• 网络延迟不能忽视，如果你的应用服务器和Redis服务器离得太远，或者网络状况不好，光是在路上传输数据就要花很多时间，尽量让它们在一个局域网内，或者同一个机房的内网里，如果用的是云服务,确保它们在同一个可用区。

  

• 持久化策略按需选择，Redis有两种主要的持久化方式：RDB（快照）和AOF（日志）。

  • RDB 是隔一段时间拍个全量快照，优点是恢复快，文件小,缺点是可能会丢失最后一次快照之后的数据。
  • AOF 是记录每一个写操作，优点是数据安全，最多丢失一秒的数据（如果配置为每秒同步），缺点是文件大,恢复慢。

  追求极致性能的话，如果你可以容忍几分钟的数据丢失，可以配置RDB持久化，比如每小时保存一次，这样Redis在大部分时间都在专注处理请求，只在备份时有一点开销，如果对数据安全要求高，就用AOF，但可以配置为 appendfsync everysec（每秒同步一次），这是个在性能和数据安全间比较好的折中。“Redis官方文档” 对这两种方式有详细的对比说明。

一些零碎但有用的技巧。

• 禁用透明大页（Transparent Huge Pages），这是一个Linux内核的特性，但对于像Redis这样需要低延迟内存访问的数据库来说，它可能会导致严重的延迟问题。“Redis官方文档”里明确指出了这一点,并建议在生产环境中将其禁用。
• 设置合理的最大连接数，默认的10000个连接数对大多数场景都够了，但如果你的连接数真的非常多，可能需要调大 maxclients 参数,避免连接被拒绝。

让Redis变快，核心思路就是：保证内存充足，让每个操作都轻快，减少不必要的等待和瓶颈，先从最可能出问题的地方下手，比如看看有没有慢查询，内存够不够用，然后再去微调其他参数，希望这些“事儿”能帮到你。