Memcached 1.6.45 已正式发布。这次更新没有把重点放在新功能上，而是集中处理崩溃、安全漏洞、协议参数转换以及 proxy 响应解析等问题。对于直接暴露 ASCII、Meta 协议，或者正在使用内置 proxy 能力的部署，这类修复会直接影响服务稳定性与输入处理边界，值得安排升级验证。
修复集中在输入解析和 proxy 边界
从发布摘要看，1.6.45 涉及三组值得关注的改动。
一组是协议层的数值转换。版本将更多 strto 调用迁移到更安全的处理方式，并修复 ASCII 协议中 flags 参数的数值转换。Memcached 的文本协议需要把客户端传入的长度、过期时间、标志位等字符串转换成整数；异常字符、溢出值或边界值如果没有被一致处理，可能导致错误响应、连接异常，严重时还可能触发崩溃。
另一组是 Meta 协议修复，包括 meta preparse 阶段对 F flag 的处理。摘要没有披露完整触发条件，因此不能据此推断具体影响范围。不过，使用 Meta Text Protocol 的客户端应把包含 F 参数的请求加入回归测试，而不是只验证常规的 get 和 set。
第三组集中在 proxy：
- 用户配置错误会得到额外警告，降低错误配置静默进入运行期的概率。
- 修复
res:line()返回错误响应的问题。 - 修复 large gets 场景中过量读取空格的问题。
这些问题说明，升级测试不能只观察 Memcached 进程是否启动，还要覆盖 proxy 路由、错误后端响应、大批量读取和配置失败路径。
为什么维护版本也需要认真回归
缓存通常不保存唯一数据副本，但缓存故障仍可能迅速放大到数据库、搜索服务和上游 API。一次进程崩溃会让大量 key 同时失效；如果多台实例因相同输入依次退出，就可能形成缓存击穿。
协议解析修复还可能带来可观察的行为变化。旧版本可能接受某些格式不规范的参数，新版本则明确返回 CLIENT_ERROR。这通常是更合理的行为，但依赖宽松解析的旧客户端可能因此暴露问题。
安全方面，发布摘要只说明包含安全漏洞修复，没有列出漏洞编号、攻击前提或严重等级。因此，运维决策应保持克制：不要虚构具体攻击方式，也不要因为 Memcached 位于内网就忽略升级。至少应确认服务没有暴露到公网，并通过安全组、防火墙或网络策略限制访问来源。
可以这样实践：启动 1.6.45 并执行协议冒烟测试
下面是一套可复制的最小验证流程。假设官方容器仓库已经提供 memcached:1.6.45 镜像；如果团队使用自建镜像，请替换镜像地址，并保留相同版本号。
docker pull memcached:1.6.45
docker run --rm -d \
--name memcached-1645 \
-p 127.0.0.1:11211:11211 \
memcached:1.6.45 \
memcached -m 64 -c 256 -vv
printf 'version\r\n' | nc 127.0.0.1 11211
预期版本响应中应包含 1.6.45。端口绑定到 127.0.0.1，避免测试实例意外暴露到外部网络。
接着验证基本读写、flags 返回值和非法 flags 的处理：
printf 'set release 42 60 6\r\n1.6.45\r\nget release\r\nquit\r\n' \
| nc 127.0.0.1 11211
printf 'set bad not-a-number 60 1\r\nx\r\nquit\r\n' \
| nc 127.0.0.1 11211
第一条命令应写入并读取 release，返回的 VALUE 行应保留 flags 值 42。第二条命令用于观察非法数值参数是否被拒绝。不同客户端对错误后的连接处理可能不同，因此自动化测试应断言错误类型，同时记录服务日志和进程状态。
还可以用一个短脚本检查升级后实例不会因一组边界输入退出：
#!/usr/bin/env bash
set -euo pipefail
host="${MEMCACHED_HOST:-127.0.0.1}"
port="${MEMCACHED_PORT:-11211}"
for request in \
'version\r\n' \
'get missing\r\n' \
'set k 0 1 1\r\nx\r\n' \
'set k invalid 1 1\r\nx\r\n'
do
printf '%bquit\r\n' "$request" | nc -w 2 "$host" "$port" >/dev/null || true
done
response="$(printf 'version\r\n' | nc -w 2 "$host" "$port")"
printf '%s\n' "$response"
printf '%s' "$response" | grep -q 'VERSION 1.6.45'
这只是冒烟测试，不等价于完整安全验证。使用 proxy 的团队还应根据自己的配置补充三类用例：错误配置能否产生清晰警告、res:line() 能否保留预期响应、large gets 是否在大 key 集合和特殊空格组合下稳定工作。
升级时检查这些事项
生产升级可以采用单实例或单分片滚动替换，并观察命中率、连接数、淘汰量、错误响应和上游数据库负载。缓存进程重启会造成局部冷缓存，因此不要在高峰期同时替换全部节点。
升级清单可以压缩为以下几项：
- 固定到明确的
1.6.45制品，并验证二进制或镜像来源。 - 检查监听地址和网络访问控制，禁止不必要的公网访问。
- 回归 ASCII、Meta 协议以及实际使用的 proxy 路由。
- 加入非法数值、超长请求、large gets 和后端错误响应测试。
- 先灰度升级，监控崩溃、协议错误、延迟和数据库回源流量。
- 保留可执行的回滚方案，但避免因旧客户端依赖非法协议输入而长期停留在旧版本。
1.6.45 的价值在于收紧协议输入边界并修补多个稳定性问题。对于缓存基础设施，这类维护版本不需要复杂的功能迁移，却仍需要真实流量模型下的验证，尤其是 proxy 和 Meta 协议使用者。