Memcached 1.6.43 已发布，这不是那种“顺手更新一下”的小版本。摘要里明确标出了多个安全相关修复，包括 binprot 项目引用计数溢出、mcmc 上游版本提升，以及 seccomp 沙箱规则调整。对把 Memcached 放在核心读路径、会话缓存或热点数据缓存里的团队来说，这类版本更适合进入短周期变更窗口，而不是等到下次大版本整理。
这次发布为什么值得关注
这次更新的关键词是“安全修复”和“运行时稳定性”。摘要中提到的几个点，虽然没有展开完整漏洞细节，但已经足够指导升级优先级：
- binprot：避免项目引用计数溢出。binprot 是 Memcached 的二进制协议路径。引用计数一旦出现溢出，通常意味着对象生命周期管理可能被破坏。缓存系统看起来只是“丢了再算”，但进程级内存错误可能影响的是整个节点的可靠性。
- mcmc：因安全问题提升上游版本号。mcmc 是 Memcached 相关组件之一，摘要明确标注为 security。依赖升级类修复经常容易被忽略，但它们同样会进入供应链风险面。
- seccomp：允许工作节点沙箱中使用 ppoll。这说明沙箱规则与运行时系统调用之间做了适配。对于启用了 seccomp 的部署环境，系统调用白名单不完整可能导致工作线程异常失败。
- core：holding locks 时避免重新分配 slab。锁持有期间做内存或 slab 相关操作，容易放大尾延迟或引入复杂并发风险。这个修复更偏稳定性，但对高并发缓存节点也很实用。
- lru_crawler 相关修复。LRU crawler 参与过期对象扫描与内存整理路径，相关修复通常会影响后台维护任务的可预期性。
换句话说，1.6.43 的价值不在于新功能，而在于让已有部署少踩一些底层坑。
升级前先确认你的暴露面
Memcached 最危险的部署方式，是把它当成“内网小工具”，却让它长期裸奔。升级版本之前，建议同时检查三件事：监听地址、协议使用方式、以及是否启用了系统级隔离。
可以这样快速看本机 Memcached 是否监听在所有网卡：
ss -lntup | grep -E 'memcached|:11211'
如果看到类似 0.0.0.0:11211 或 [::]:11211，就要确认安全组、防火墙、Kubernetes NetworkPolicy 或主机防火墙是否已经限制来源。多数业务场景下，Memcached 应只对应用服务器或同一集群内服务开放。
再确认当前版本：
memcached -h | head -n 1
如果系统包没有直接提供 1.6.43，可以先查看发行版安全更新渠道，而不是盲目源码覆盖安装：
# Debian / Ubuntu
apt-cache policy memcached
# RHEL / CentOS / Fedora 系
rpm -q memcached
可以这样实践：用容器做一次可回滚验证
如果你的线上 Memcached 不是容器化部署，也仍然可以用容器快速验证客户端兼容性、基础命令和启动参数。下面示例假设你使用官方或内部镜像仓库中带有 1.6.43 的镜像标签；运行前把镜像名替换成你们实际使用的镜像。
#!/usr/bin/env bash
set -euo pipefail
IMAGE="memcached:1.6.43"
NAME="memcached-1643-test"
docker rm -f "$NAME" >/dev/null 2>&1 || true
docker run -d \
--name "$NAME" \
-p 127.0.0.1:11211:11211 \
"$IMAGE" \
memcached -m 128 -c 1024 -v
printf 'version\r\n' | nc 127.0.0.1 11211
printf 'set release 0 60 6\r\n1.6.43\r\nget release\r\nquit\r\n' | nc 127.0.0.1 11211
这段脚本做了几件保守的事：
- 只绑定到
127.0.0.1，避免测试实例意外暴露到局域网。 - 使用
version检查服务实际返回的版本。 - 用最基础的文本协议执行
set/get，验证客户端链路之前先确认服务本身可用。
如果你们使用二进制协议客户端，也应在预发环境跑一组真实业务读写用例。因为这次摘要中特别提到 binprot 安全修复，兼容性验证不应只覆盖文本协议。
systemd 部署的收敛检查
很多生产环境仍然通过 systemd 管理 Memcached。升级时不建议只替换包就结束，最好顺手检查启动参数是否符合当前安全边界。下面是一个可改造的 override 示例，用来限制监听地址并保留明确的资源上限。
sudo systemctl edit memcached
写入：
[Service]
ExecStart=
ExecStart=/usr/bin/memcached -l 127.0.0.1 -p 11211 -m 1024 -c 4096 -U 0
应用并检查：
sudo systemctl daemon-reload
sudo systemctl restart memcached
sudo systemctl status memcached --no-pager
ss -lntup | grep ':11211'
printf 'version\r\nquit\r\n' | nc 127.0.0.1 11211
这里的参数需要按你的环境调整：
-l 127.0.0.1：只允许本机访问。如果应用与缓存不在同一主机，应改成内网地址，并配合防火墙或安全组。-m 1024：分配 1024 MB 内存。不要直接照抄，按节点容量和业务缓存命中率设置。-c 4096：最大连接数。需要结合客户端连接池配置一起看。-U 0：关闭 UDP。很多业务不需要 UDP；如果你确实依赖 UDP，就不能照搬这一项。
上线建议：把它当安全变更处理
Memcached 1.6.43 的摘要已经明确包含 security 标签，因此建议按安全补丁流程推进：
- 先盘点版本：列出所有 Memcached 节点、镜像、AMI、基础包版本和部署方式。
- 先预发验证：覆盖文本协议、二进制协议、连接池、超时、重试和高并发读写。
- 分批滚动：缓存节点通常可以滚动替换，但要注意热 key、会话缓存和预热策略。
- 观察指标：重点看连接数、驱逐数、命中率、尾延迟、进程重启、客户端超时。
- 收紧暴露面：升级不能替代访问控制。监听地址、防火墙、安全组和网络策略仍然要查。
这类版本的取舍很清楚：它不会给业务带来可见的新能力，但能降低底层协议、依赖和运行时隔离上的风险。越是承担核心读流量的 Memcached 集群，越应该尽快完成验证和滚动升级。