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