Memcached怎么在Linux上运行 Memcached缓存服务器配置详解

在Linux服务器上部署Memcached，看似是条简单的命令，但配置细节上的疏忽，往往会导致服务静默失败或性能不达标。今天，我们就来聊聊那些容易被忽略，却又至关重要的配置要点。

直接用包管理器启动最稳，别碰源码编译

对于绝大多数生产环境，从源码编译安装Memcached并不是个好主意，除非你明确需要SASL认证、特定旧版本，或者发行版仓库确实不提供。更稳妥高效的做法是直接使用系统包管理器。

在Ubuntu或Debian上，执行 sudo apt install memcached libmemcached-tools 即可。而在CentOS/RHEL 8及更新版本中，则应使用 sudo dnf install memcached（RHEL 7及更早版本则用 yum）。安装完成后，系统会自动将其注册为systemd服务，省去了手动编写service文件的麻烦。

一个常见的报错是：Failed to start memcached.service: Unit memcached.service not found。这通常是因为包名输入错误（例如在CentOS上误输为memcached-server），或者在Ubuntu 22.04及之后版本中，默认的universe仓库被禁用。解决后者只需先运行 sudo add-apt-repository universe && sudo apt update。

安装后务必立刻验证：systemctl is-active memcached 命令应返回 active；接着运行 ss -tlnp | grep :11211，确认服务监听在预期的地址上，比如 127.0.0.1:11211。

/etc/memcached.conf 的写法很脆弱，改错一个字母就静默失败

Memcached的配置文件格式有点特别，它既不是JSON，也不是常见的key=value风格，而是纯命令行参数格式。这意味着：

• 每行必须以 - 开头。
• 参数和值之间不能有空格（例如 -m64 是正确的，而 -m 64 会导致配置失效）。
• 大小写敏感（小写 -l 是设置监听地址，而大写 -I 则是无效参数）。
• 注释用 #，但不能直接跟在参数行的末尾（否则会被当作参数值的一部分处理）。

几个关键参数的实际操作建议：

• -m 64：分配64MB内存。注意，设置值不要超过物理内存的50%，否则可能触发Linux的OOM Killer终止进程。
• -l 127.0.0.1,::1：监听地址，可用逗号分隔多个。若需允许外网访问，必须添加 0.0.0.0，并务必同步关闭UDP端口：-U 0，同时配置防火墙放行TCP 11211端口。
• -c 4096：高并发场景下，建议将此值调至4096以上。同时，别忘了修改系统限制：echo 'memcached soft nofile 8192' >> /etc/security/limits.conf。
• 谨慎对待 -S（启用SASL）：如果未正确配置认证凭据，服务会卡在 Failed to initialize SASL 错误上。不确定时，直接注释掉这一行更安全。

连通性验证不能只靠 telnet，得发协议指令

使用 telnet 127.0.0.1 11211 只能测试端口是否开放，无法证明缓存服务功能正常。真正的验证需要遵循Memcached的文本协议。

更推荐使用 nc 127.0.0.1 11211 进入交互模式，然后输入：

set test 0 60 5
hello

如果返回 STORED，再输入 get test。若能收到 VALUE test 0 5\r\nhello\r\nEND 这样的响应，才说明服务完全通畅。这里有个细节：bytes 值（例子中的 5）必须严格等于后续value的字符数，多一个换行或少一个字符都会导致操作失败。

调试时，优先选用 nc 而非 telnet。因为前者对 \r\n 这样的换行符更敏感，能暴露潜在的协议格式问题；而 telnet 有时会自动补全换行，反而掩盖了真实错误。

性能调优里最容易被忽略的是 -f 和 -n 参数

Memcached使用slab分配器管理内存，其中 -f（增长因子）和 -n（最小chunk大小）这两个参数共同决定了内存碎片率。默认的 -f 1.25 -n 48 适用于通用场景。

但如果你的应用场景比较特殊，就需要调整：当缓存大量小对象（如短token字符串）时，可以尝试 -n 64 -f 1.1 来减少内存浪费；若是缓存大对象（如超过10KB的序列化JSON），则可能需要调高 -f 值，以避免产生过多的slab分类。

如何判断是否需要调整？可以通过命令查看当前的slab分布：echo "stats slabs" | nc 127.0.0.1 11211 | grep "chunk_size\|total_chunks"。如果发现很多slab class的 used_chunks 接近 total_chunks，但 evicted（驱逐计数）很高，这就表明chunk大小设置不合理，导致数据被频繁驱逐——这时才值得去调整 -f 和 -n。否则，保持默认配置往往是最省心、最稳妥的选择。