Memcached 完全指南 / 第 1 章：Memcached 简介

第 1 章：Memcached 简介

1.1 历史起源

Memcached 最初由 Brad Fitzpatrick 于 2003 年为 LiveJournal 开发，目的是解决高并发读取场景下的数据库压力问题。

发展时间线

核心设计理念

Memcached 的设计哲学可以用三个词概括：简单、快速、分布式。

┌─────────────────────────────────────────────┐
│              Memcached 设计原则              │
├─────────────────────────────────────────────┤
│  1. K/V 存储：只做一件事，做到极致           │
│  2. 内存优先：数据只存在内存中，重启即丢失   │
│  3. 无持久化：不做 RDB/AOF，简化设计         │
│  4. 客户端分片：服务端无中心，客户端路由     │
│  5. O(1) 复杂度：所有操作常数时间            │
│  6. 懒惰删除：过期数据不立即回收，按需清理   │
└─────────────────────────────────────────────┘

1.2 核心特性

特性概览

为什么选择 Memcached？

场景一：纯粹的缓存层

如果你的需求是"查询 → 缓存 → 返回"，不需要复杂数据结构，Memcached 是最佳选择：

# 典型缓存流程
Client → 查询 Memcached
  ├── 命中 → 直接返回（< 1ms）
  └── 未命中 → 查数据库 → 写入缓存 → 返回

场景二：大规模分布式缓存

Memcached 的客户端分片架构天然支持水平扩展：

                    ┌─── Memcached Node 1 (2GB)
Client ──哈希路由──┼─── Memcached Node 2 (2GB)
                    ├─── Memcached Node 3 (2GB)
                    └─── Memcached Node N (2GB)

1.3 适用场景

非常适合的场景

不适合的场景

1.4 Memcached vs Redis

这是最常被问到的问题。两者都是优秀的内存缓存，但定位不同。

架构对比

Memcached 架构:                    Redis 架构:
┌──────────────┐                   ┌──────────────┐
│   Client     │                   │   Client     │
│ (一致性哈希) │                   │              │
└──┬───┬───┬───┘                   └──────┬───────┘
   │   │   │                              │
   ▼   ▼   ▼                              ▼
┌──┐ ┌──┐ ┌──┐                    ┌──────────────┐
│N1│ │N2│ │N3│  ← 无中心          │ Redis Server │ ← 有中心
└──┘ └──┘ └──┘                    │  (主从/集群)  │
                                  └──────────────┘

功能对比表

性能对比（单节点，小 Value）

注意：以上数据为参考值，实际性能受硬件、网络、Value 大小、并发量等因素影响。

选型决策树

需要持久化？
  ├── 是 → Redis
  └── 否 → 需要复杂数据结构？
              ├── 是 → Redis
              └── 否 → 需要发布订阅/Lua 脚本？
                          ├── 是 → Redis
                          └── 否 → 纯缓存 + 大规模 + 高吞吐？
                                      ├── 是 → Memcached ✓
                                      └── 否 → 两者均可（团队熟悉度决定）

1.5 谁在使用 Memcached？

大规模部署案例

Facebook 的经典架构

Facebook 在 2013 年的 USENIX 论文《Scaling Memcache at Facebook》中描述了其架构：

用户请求
    │
    ▼
┌─────────┐     ┌──────────┐     ┌───────────┐
│ Web 层  │────▶│ McRouter  │────▶│ Memcached │
│ (PHP)   │     │ (代理层)  │     │  集群     │
└─────────┘     └──────────┘     └───────────┘
    │                                  │
    ▼                                  ▼
┌─────────┐                    ┌───────────┐
│ MySQL   │◀────── 失效通知 ───│ 集群间    │
│ 集群    │                    │ 复制      │
└─────────┘                    └───────────┘

1.6 Memcached 的局限性

了解局限性同样重要：

已知限制

1.7 本教程路线图

基础篇（第 1-5 章）
  ├── 了解 Memcached（你在这里）
  ├── 安装与部署
  ├── 架构原理
  ├── 核心命令
  └── 数据类型与序列化

进阶篇（第 6-10 章）
  ├── Slab 分配器详解
  ├── LRU 淘汰策略
  ├── 一致性哈希
  ├── 多线程模型
  └── 通信协议

运维篇（第 11-14 章）
  ├── 安全加固
  ├── 监控与告警
  ├── 性能优化
  └── Docker 部署

实战篇（第 15-16 章）
  ├── 多语言客户端
  └── 生产最佳实践

1.8 快速体验

如果等不及看完全部教程，可以先用 Docker 快速体验：

# 启动 Memcached
docker run -d --name mc-test -p 11211:11211 memcached:1.6-alpine

# 安装命令行客户端
sudo apt-get install -y libmemcached-tools  # Debian/Ubuntu
# 或
brew install libmemcached                     # macOS

# 使用 telnet 连接（最简单的方式）
telnet localhost 11211

# 尝试基本操作
set mykey 0 3600 5       # 设置 Key，Flags=0，TTL=3600秒，5字节
hello                     # 值
STORED                    # 返回结果

get mykey                 # 获取
VALUE mykey 0 5           # 返回
hello
END

quit                      # 退出

扩展阅读

• Memcached 官方文档
• Scaling Memcache at Facebook (USENIX 2013)
• Memcached GitHub 仓库
• Memcached Wiki

小结