Memcached本身不提供分布式能力，其分布式完全由客户端通过一致性哈希算法实现；需部署多个独立实例，并配合支持一致性哈希的客户端（如node-memcached、python-memcached）完成数据分片与故障转移。
Memcached 本身不自带分布式能力，它的“分布式”完全由客户端实现——通过一致性哈希算法把 key 映射到不同服务器节点上。真正要搭建的是多节点 Memcached 服务 + 支持一致性哈希的客户端（如 node-memcached、python-memcached），而不是让 Memcached 实例之间相互通信。
安装并启动多个 Memcached 实例
分布式集群的前提是多个独立运行的 Memcached 服务。你需要在不同机器（或同一台机器的不同端口）上部署多个实例：
- 每台服务器安装 Memcached（依赖 libevent，Linux/macOS 可直接包管理安装）
- 启动时指定不同端口、内存和绑定地址，避免冲突：
memcached -d -u nobody -m 512 -l 192.168.1.10 -p 11211 -c 1024memcached -d -u nobody -m 512 -l 192.168.1.11 -p 11211 -c 1024 - 确认各实例正常监听：
netstat -tuln | grep :11211或ss -tuln | grep 11211 - 生产环境建议开启多线程（-t 参数），例如
-t 4提升并发处理能力
客户端启用一致性哈希
关键不在服务端，而在客户端如何分发请求。主流客户端默认支持一致性哈希（如 node-memcached 使用 libketama 算法）：
- Node.js 示例：
const mc = new Memcached(['192.168.1.10:11211', '192.168.1.11:11211'])—— 自动启用一致性哈希 - Python 示例（python-memcached）：
mc = Client(['192.168.1.10:11211', '192.168.1.11:11211'], pickleProtocol=0, server_max_value_length=1048576)，底层也默认使用一致性哈希 - 避免用简单取模（如
hash(key) % N），节点增减会导致大量 key 重映射、缓存雪崩 - 可选增强：配置虚拟节点（如 node-memcached 的
redundancy或自定义哈希环），提升负载均衡均匀性
生产级配置与高可用保障
单靠多实例还不够，需配套机制应对节点故障和流量波动：
- 设置连接池参数：如
poolSize: 20、timeout: 2000、retry: 5000，防止阻塞和长时间等待 - 启用自动故障转移：客户端检测到某节点超时或拒绝连接后，自动剔除该节点，并在后台定时尝试重连
- 合理分配权重（适用于异构服务器）：
{'192.168.1.10:11211': 2, '192.168.1.11:11211': 1}，让性能强的节点承担更多负载 - 监控基础指标：命中率（
get_hits / cmd_get）、evictions（LRU 清退数）、curr_connections，及时发现过载或内存瓶颈
验证与调试技巧
部署后必须验证数据是否真实按哈希分布，且故障时行为符合预期：
- 用相同 key 在不同客户端反复 set/get，检查是否始终落到同一节点（可用
telnet 192.168.1.10 11211手动 get 验证） - 临时停掉一个节点，观察剩余节点是否承接全部请求，且无报错或大面积 miss
- 查看各节点 stats：
echo "stats" | nc 192.168.1.10 11211 | grep -E "(cmd_get|get_hits|evictions)" - 避免将 session 类敏感数据全量依赖 Memcached 分布式集群——它不保证强一致性，也不提供持久化
