Redis想快点但又不想存数据，咋整才能真不保存又不卡顿

这个问题说白了就是想让Redis跑得飞快,但又不让它把数据写到硬盘上，彻底变成一个“金鱼脑”，转身就忘，要达到这个目的，核心就是彻底关闭Redis的任何形式的持久化机制，并围绕这个前提进行一系列优化，让它在内存里“裸奔”，从而获得极致的速度。

第一招：釜底抽薪，关闭所有持久化设置

这是最根本的一步,Redis默认为了数据安全，是配置了持久化策略的，我们需要手动把它们全部关掉。

根据Redis官方文档的说明,它的持久化主要有两种方式：一种是RDB，类似于给内存数据拍个快照存下来；另一种是AOF，像写日记一样记录每一个写操作，我们要做的就是让这两种功能都失效。

具体操作就是找到Redis的配置文件,通常叫redis.conf，在这个文件里，找到和RDB相关的设置，你会看到以save开头的几行配置，比如save 900 1，意思是如果900秒内至少有1个键被改变，就自动保存一次快照，我们要把这些save配置行全部注释掉（在行首加），或者直接改成save ""，这明确告诉Redis不要进行RDB快照。

处理AOF,找到appendonly这个配置项，默认是no，但最好确认一下，确保它被设置为appendonly no，这样，Redis就不会再追加以AOF文件的形式记录操作日志了。

做完这两步,重启Redis服务，它就不会再操心数据落地的事情，所有的精力都放在处理内存数据上，速度自然会提升一个档次。

第二招：精打细算，最大化利用内存

既然数据只存在内存里,那么内存的使用效率就至关重要了，目标是用更少的内存存更多的数据，减少不必要的内存分配和回收带来的开销。

一个重要的手段是优化内存数据结构,Redis为了节省内存，提供了一些特别的数据结构，当存储的键值对很小时，可以使用hash数据类型，它比把每个字段都单独存成一个键要省内存得多，如果存储的是整数集合，可以使用ziplist或listpack（取决于Redis版本）这样的紧凑型编码，而不是标准的链表结构。

这些优化通常不需要修改代码,而是在redis.conf文件里进行配置，里面有很多像hash-max-ziplist-entries、list-max-ziplist-size这样的参数，它们就像是开关，当你的数据结构的大小或元素数量低于某个阈值时，Redis会自动采用更省内存的编码方式，你需要根据你实际存储的数据特点，来调整这些阈值，在CPU和内存之间找到一个平衡点，虽然调整这些参数需要一些尝试，但一旦调优好，对内存的节省是非常可观的。

第三招：减轻负担，只做最关键的事

一个只做内存操作的Redis已经很快了,但如果它被一些不必要的任务拖累，速度还是会受影响，我们要尽量让它“轻装上阵”。

首先要关注的是过期键的清理，Redis里可以给键设置过期时间，到期后会自动删除，这个删除动作本身需要消耗CPU资源，Redis的过期策略是惰性删除加上定期删除，惰性删除指的是当客户端尝试访问一个键时，Redis才会检查它是否过期，这本身没问题，但定期删除是Redis会主动轮询一批键进行检查，这可能会引起短暂的延迟。

我们可以通过调整redis.conf中的hz参数来控制定期删除的频率。hz默认是10，表示每秒执行10次后台任务（包括过期键清理），在完全不持久化的场景下，可以适当调低这个值（比如调到5），以减少CPU的消耗，但代价是过期键可能不会那么及时地被清理掉，会多占一会儿内存，这就需要根据你对过期精度的要求来权衡了。

要避免使用慢操作命令，有些Redis命令天生就比较“重”，比如keys *，它会遍历当前数据库的所有键，如果数据量很大，这个命令会直接阻塞Redis服务器，导致其他所有请求卡顿，应该用scan命令来替代它，scan是渐进式的，不会长时间阻塞，类似的，对一个大集合进行求交集、并集等操作，也要谨慎。

第四招：硬件与系统层面的助攻

速度的瓶颈可能不在Redis本身,而在它运行的环境上。

内存速度和容量是根本，既然数据全在内存，那么内存条的频率和时序就很重要，更快的内存意味着更低的延迟，确保分配足够的内存容量，绝对要避免操作系统因为物理内存不足而使用Swap分区（虚拟内存），一旦发生Swap，速度会呈断崖式下跌，因为硬盘速度远远跟不上内存。

CPU核心要够用，Redis是单线程架构的，但它处理网络I/O和后台任务（即使我们调低了频率）还是会用到其他核心，所以一个多核CPU是有益的，可以避免Redis主线程被其他系统进程打扰。

网络带宽和延迟不能拖后腿，Redis的性能很大程度上也取决于网络，确保Redis服务器和客户端之间的网络连接是高速、低延迟的，如果它们部署在同一台机器上，通过回环地址（127.0.0.1）通信，可以消除网络延迟，这是最快的选择。

想让Redis“真不保存又不卡顿”，就是一个系统工程：首先要坚决地关闭持久化，然后像管家一样精细地优化内存使用，接着像教练一样为它减少不必要的负担，最后还要提供一个良好的硬件和系统环境，这一切的前提，是你真的可以接受服务器一旦重启或者进程崩溃，所有数据就瞬间清零的后果，这种模式通常只适用于纯缓存场景，比如缓存一些可以随时从数据库重新加载的热点数据，或者存放一些临时的会话信息。