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。否则，保持默认配置往往是最省心、最稳妥的选择。