Redis性能提升其实挺大程度靠系统参数调节，聊聊那些配置优化的点吧

说到Redis性能提升,很多人第一反应是优化代码或者用更高级的数据结构，但其实，有很大一块性能红利是藏在操作系统的配置里的，你把Redis安装好，直接用默认配置跑，可能只能发挥它六七成的功力，剩下的，就得靠调整系统和Redis本身的参数来“解锁”了，这就像买了一辆高性能跑车，但你得知道怎么调校发动机和悬挂，才能让它真正跑起来。

最立竿见影的一点,就是解决内存分配的问题，Redis是内存数据库，所有数据都放在内存里，频繁地申请和释放内存是家常便饭，默认的内存分配器（比如glibc的malloc）可能不太适合Redis这种高强度、多变的负载，它容易产生内存碎片，也就是说，总内存看着还很多，但都是一小块一小块的，当需要分配一大块连续内存时就会失败，导致Redis被迫进行耗时的内存整理，甚至崩溃。（来源：Redis官方文档对内存管理的说明）

怎么办呢？一个被广泛验证有效的办法是使用jemalloc这个替代的内存分配器，它在处理碎片方面表现好得多，你可以在编译Redis的时候就选择使用jemalloc，很多Linux发行版的Redis包默认就已经这么做了，检查一下你的Redis启动日志，如果看到jemalloc的字样，那就说明已经在用了，这个简单的选择，可能就能让你的Redis运行得更稳定、更流畅。

我们得聊聊透明大页（Transparent Huge Pages, THP），这个本是Linux内核为了提升内存管理效率的一个功能，但对Redis来说，却常常是个“性能杀手”。（来源：Redis官方文档中“Latency generated by transparent huge pages”章节）为什么这么说呢？THP会尝试将小内存页合并成一个大内存页，这个合并过程本身就需要锁定内存，而Redis作为内存密集型应用，需要频繁、低延迟地访问内存，THP的合并操作可能会引起短暂的、但非常明显的停顿，对于要求毫秒级响应的Redis简直是灾难，通常的建议是直接关闭它，你可以通过命令echo never > /sys/kernel/mm/transparent_hugepage/enabled来禁用THP，并把它加到系统启动脚本里永久生效，关了之后，很多之前无法解释的周期性延迟可能就消失了。

再来是内存过载设置（overcommit_memory），Linux内核有个机制叫内存过量提交，它允许程序申请比物理内存加上交换空间（swap）总和还要多的内存，这个设置有三个值：0、1、2。（来源：Linux内核文档关于vm.overcommit_memory的说明）当这个值是0时（默认值），内核会尝试估算是否有足够内存，在内存紧张时可能会拒绝Redis的fork操作（比如做持久化RDB快照时），导致持久化失败，建议把它设置为1，意思是内核总是同意内存申请，这样fork过程会更顺利，设置命令是sysctl vm.overcommit_memory=1。

然后不得不提最大内存和淘汰策略，你必须在Redis配置文件redis.conf里明确设置maxmemory参数，告诉Redis最多能用多少内存，绝对不能让它无限制地用下去，否则会用尽系统内存，导致系统开始狂用swap，或者直接被OOM Killer机制杀掉进程，设定了最大内存后，还要设置maxmemory-policy，也就是内存满了之后怎么办，是淘汰最近最少用的键（allkeys-lru）？还是只淘汰设定了过期时间的键（volatile-lru）？或者是直接报错（noeviction）？根据你的业务特点选对策略至关重要，比如如果是缓存场景，用allkeys-lru就很合适；如果数据都不能丢，那可能得选择noeviction并确保有足够的内存。

还有网络和连接相关的。tcp-backlog参数决定了连接队列的长度，如果客户端连接非常频繁，适当调大这个值（比如511）可以防止连接被拒绝。timeout参数可以自动关闭长时间空闲的连接，释放资源。

持久化方式的选择也深刻影响性能，如果你对数据丢失的容忍度比较高，比如纯做缓存，那么可以只使用AOF并调整appendfsync为everysec甚至no，这会比默认的everysec和总是同步的RDB快照模式性能更高，但代价是宕机时可能丢失更多数据，这完全是一个根据业务需求在性能和数据安全之间的权衡。

优化Redis性能,千万别只盯着Redis本身的命令和数据结构，花点时间检查一下操作系统层面的这几个关键点：用jemalloc代替默认分配器、坚决关闭透明大页THP、设置好内存过载参数、在Redis配置里明确最大内存和淘汰策略，这些调整不需要你改动一行业务代码，但带来的性能提升和稳定性改善，往往是颠覆性的，先把这些基础的、系统层面的“地基”打牢，再去考虑更上层的优化，才能事半功倍。