Memcached

1、 Memcached 是什么，有什么作用？

Memcached 是一个开源的，高性能的内存缓存软件， 从名称上看 Mem 就是内存的意思， 而 Cache 就是缓存的意思。

Memcached 的作用：通过在事先规划好的内存空间中临时缓存数据库中的各类数据，以达到减少业务对数据库的直接高并发访问，从而达到提升数据库的访问性能，加速网站集群动态应用服务的能力。

2、memcached 服务在企业集群架构中有哪些应用场景？

一、 作为数据库的前端缓存应用

a、完整缓存（易）， 静态缓存

例如： 商品分类（京东）， 以及商品信息，可事先放在内存里， 然后再对外提供数据访问， 这种先 放到内存， 我们称之为预热，（先把数据存缓存中） ，用户访问时可以只读取 memcached 缓存， 不读取数据库了 。

b、热点缓 存（难）

需要前端 web 程序 配合， 只缓存热点的数据，即缓存经常被访问的数据。

先预热数据库里的基础数据， 然后在动态更新， 选读取缓存， 如果缓存里没有对应的数据，程序再 去读取数据库，然后程序把读取的新数据放入缓存存储。

特殊说明 ：

如果碰到电商秒杀等高并发的业务，一定要事先预热，或者其它思想实现， 例如：称杀只是获取资格，而不是瞬间秒杀到手商品。

那么什么是获取资格？ _

就是在数据库中，把 0 标成 1.就有资格啦。再慢慢的去领取商品订单。 因为秒杀过程太长会占用服务器资源。

如果数据更新，同时触发缓存更新，防止给用户过期数据。

对于持久化缓存存储系统， 例如： redis，可以替代一部分数据库的存储，

一些简单的数据业务，投票，统计，好友关注，商品分类等。 nosql= not only sql

二、 作业集群的 session 会话共享存储

Memcached 服务在不同企业业务应用场景中的工作流程

• 当 web 程序需要访问后端数据库获取数据时会优先访问 Memcached 内存缓存， 如果缓存中有数据就直接获取返回前端服务及用户， 如果没有数据（没有命中）， 在由程序请求后端的数据库服务器，获取到对应的数据后， 除了返回给前端服务及用户数据外，还会把数据放到 Memcached 内存中进行缓存，等待下次请求被访问， Memcache 内存始终是数据库的挡箭牌，从而大大的减轻 数据库的访问压力，提高整个网站架构的响应速度，提升了用户体验。
• 当程序更新，修改或删除数据库中已有的数据时，会同时发送请求通知 Memcached 已经缓存的同一个 ID 内容的旧数据失效，从而保证 Memcache 中数据和数据库中的数据一致。
• 如果在高并发场合，除了通知 Memcached 过程的缓存失效外，还会通过相关机制，使得在用户访问新数据前，通过程序预先把更新过的数据推送到 memcache 中缓存起来，这样可以减少数据库的访问压力，提升 Memcached 中缓存命中率。
• 数据库插件可以再写入更新数据库后，自动抛给 MC 缓存起来，自身不 Cache。

3、 Memcached 服务分布式集群如何实现？

特殊说明： Memcached 集群 和 web 服务集群是不一样的， 所有 Memcached 的数据总和才是数据库的数据。每台 Memcached 都是部分数据。

（一 台 memcached 的数据，就是一部分 mysql 数据库的数据）

a、程序端实现

程序 加载 所有 mc 的 ip 列表， 通 过对 key 做 hash (一致 性哈 希算 法)

例如： web1 (key)===>对应 A,B,C,D,E,F,G … ..若干台服务器。（通过哈希算法实现）

b、负载均衡器

通过对 key 做 hash (一致性哈希算法)

一致哈希算法的目的是不但保证每个对象只请求一个对应的服务器， 而且当节点宕机，缓存服务器的更新重新分配比例降到最低。

4、 Memcached 服务特点及工作原理是什么？

a、完全基于内存缓存的

b、节点之间相互独立

c 、 C/S 模式架构， C 语言编写， 总共 2000 行代码

d、异步Ｉ /O 模型，使用 libevent 作为事件通知机制

e、被缓存的数据以 key/value 键值对形式存在的

f、全部数据存放于内存中，无持久性存储的设计，重启服务器，内存里的数据会丢失

g、当内存中缓存的数据容量达到启动时设定的内存值时，就自动使用 LRU 算法删除过期的缓存数 据。

h 、可以对存储的数据设置过期时间，这样过期后的数据自动被清除，服务本身不会监控过期，而是 在访问的时候查看 key 的时间戳, 判断是否过期

j 、 memcache 会对设定的内存进行分块，再把块分组，然后再提供服务。

5、简述 Memcached 内存管理机制原理？

早期 的 Memcached 内存 管理 方式 是通 过 malloc 的分 配的 内存， 使 用完 后通 过 free 来回 收内 存， 这种 方式 容易 产生 内存 碎片， 并 降低 操作 系统 对内 存的 管理 效 率。 加重 操作 系统 内存 管理 器的 负担， 最 坏的 情况 下， 会导 致操 作系 统比memcached 进程 本身 还慢， 为 了解 决这 个问 题， Slab Allocation 内存 分配 机制 就延 生了 。

现在 Memcached 利用 Slab Allocation 机制 来分 配和 管理 内存 。

Slab

Allocation 机制 原理 是按 照预 先规 定的 大小， 将 分配 给 memcached 的内 存分 割 成特 定长 度的 内存 块（chunk)， 再 把尺 寸相 同的 内存 块， 分成 组

（chunks slab class),这些 内存 块不 会释 放， 可以 重复 利用 。

而且， slab allocator 还有 重复 使用 已分 配的 内存 的目 的。 也就 是说， 分 配到 的

内存 不会 释放， 而 是重 复利 用。

Slab Allocation 的主 要术 语

Page

分配 给 Slab 的内 存空 间， 默认 是 1MB 。分配 给 Slab 之后 根据 slab 的大 小切 分 成 chunk。

Chunk

用于 缓存 记录 的内 存空 间。

SlabClass

特定 大小 的 chunk 的组 。

集 群 架 构 方 面 的 问 题

6、 memcached 是怎么工作的？

Memcached 的神 奇来 自两 阶段 哈希 （two-stage hash） 。 Memcached 就像 一 个巨 大的 、 存储 了很 多<key,value>对的 哈希 表 。 通过 key， 可以 存储 或查 询任 意 的数 据。

客户 端可 以把 数据 存储 在多 台 memcached 上。 当查 询数 据时， 客 户端 首先 参考 节点 列表 计算 出 key 的哈 希值 （阶 段一 哈希） ， 进而 选中 一个 节点； 客 户端 将请 求发 送给 选中 的节 点， 然后 memcached 节点 通过 一个 内部 的哈 希算 法（阶段 二 哈希） ， 查找 真正 的数 据（item） 。

7、 memcached 最大的优势是什么？

Memcached 最大 的好 处就 是它 带来 了极 佳的 水平 可扩 展性，特别 是在 一个 巨大 的 系统 中。 由于 客户 端自 己做 了一 次哈 希， 那么 我们 很容 易增 加大 量 memcached 到集 群中 。memcached 之间 没有 相互 通信， 因此 不会 增加 memcached 的负 载； 没有 多播 协议， 不 会网 络通 信量 爆炸 （implode） 。 memcached 的集 群很 好用 。 内存 不够 了？ 增加 几台 memcached 吧； CPU 不够 用了？ 再 增加 几台 吧； 有多 余 的内 存？ 在增 加几 台吧， 不 要浪 费了 。

基于 memcached 的基 本原 则， 可以 相当 轻松 地构 建出 不同 类型 的缓 存架 构。 除 了这 篇 FAQ， 在 其他 地方 很容 易找 到详 细资 料的 。

8、 memcached 和 MySQL 的 query cache 相比， 有什么优缺点？

把 memcached 引入 应用 中， 还是 需要 不少 工作 量的 。 MySQL 有个 使用 方便 的 query cache， 可 以自 动地 缓存 SQL 查询 的结 果， 被缓 存的 SQL 查询 可以 被反 复 地快 速执 行 。 Memcached 与之 相比， 怎么 样呢？ MySQL 的 query cache 是集 中 式的， 连 接到 该 query cache 的 MySQL 服务 器都 会受 益。

当您修改表时， MySQL 的 query cache 会立刻被刷新（flush）。存储 一个 memcached item 只需要很少的时间，但是当写操作很频繁时， MySQL 的 query cache 会经常让所有缓存数据都失效。

在多核 CPU 上， MySQL 的 query cache 会遇到扩展问题（scalability issues） 。在多核 CPU 上， query cache 会增加一个全局锁 （global lock） , 由 于需要刷新更多的缓存数据，速度会变得更慢。

在 MySQL 的 query cache 中，我们是不能存储任意的数据的（只能是 SQL 查询结果）。而利用 memcached，我们可以搭建出各种高效的缓存。比 如，可以执行多个独立的查询，构建出一个用户对象（user object），然后将 用户对象缓存到 memcached 中。而 query cache 是 SQL 语句级别的，不可能 做到这一点。在小的网站中，query cache 会有所帮助，但随着网站规模的增加， query cache 的弊将大于利。

query cache 能够利用的内存容量受到 MySQL 服务器空闲内存空间的限 制。给数据库服务器增加更多的内存来缓存数据，固然是很好的。但是，有了 memcached，只要您有空闲的内存，都可以用来增加 memcached 集群的规 模，然后您就可以缓存更多的数据。

9、memcached 和服务器的 local cache（比如 PHP 的 APC、mmap 文件等）相比，有什么优缺点？

首先， local cache 有许 多与 上面 (query cache)相同 的问 题。 local cache 能够 利 用的 内存 容量 受到 （单 台） 服务 器空 闲内 存空 间的 限制 。不 过， local

cache 有 一 点 比 memcached 和 query cache 都 要 好， 那 就 是 它 不 但 可 以 存 储 任 意 的 数 据， 而 且 没 有 网 络 存 取 的 延 迟 。

local cache 的数据查询更快。考虑把 highly common 的数据放在 local cache 中吧。如果每个页面都需要加载一些数量较少的数据，考虑把它们放在 local

cached 吧。

local cache 缺少集体失效（group

invalidation） 的特性。在 memcached 集群中， 删除或更新一个 key 会让所有 的观察者觉察到。但是在 local cache 中, 我们只能通知所有的服务器刷新 cache （很慢，不具扩展性），或者仅仅依赖缓存超时失效机制。

local cache 面临着严重的内存限制，这一点上面已经提到。

10、 memcached 的 cache 机制是怎样的？

Memcached 主 要 的 cache 机 制 是 LRU （最 近 最 少 用） 算 法 +超 时 失 效 。 当 您 存 数 据 到 memcached 中， 可 以 指 定 该 数 据 在 缓 存 中 可 以 呆 多 久 Which is forever, or some time in the future。 如 果 memcached 的 内 存 不 够 用 了， 过 期 的 slabs 会 优 先 被 替 换， 接 着 就 轮 到 最 老 的 未 被 使 用 的 slabs。

11、 memcached 如何实现冗余机制？

不 实 现！ 我 们 对 这 个 问 题 感 到 很 惊 讶 。 Memcached 应 该 是 应 用 的 缓 存 层 。 它 的 设 计 本 身 就 不 带 有 任 何 冗 余 机 制 。 如 果 一 个 memcached 节 点 失 去 了 所 有 数 据， 您 应 该 可 以 从 数 据 源 （比 如 数 据 库） 再 次 获 取 到 数 据 。 您 应 该 特 别 注 意， 您 的 应 用 应 该 可 以 容 忍 节 点 的 失 效 。 不 要 写 一 些 糟 糕 的 查 询 代 码， 寄 希 望 于 memcached来保 证一 切！ 如果 您担 心节 点失 效会 大大 加重 数据 库的 负担， 那 么您 可以 采取 一 些办 法。 比如 您可 以增 加更 多的 节点 （来 减少 丢失 一个 节点 的影 响） ， 热 备节 点 （在 其他 节点 down 了的 时候 接管 IP） ， 等等 。

12、 memcached 如何处理容错的？

不处 理！ 在 memcached 节点 失效 的情 况下， 集群 没有 必要 做任 何容 错处 理 。 如 果发 生了 节点 失效， 应 对的 措施 完全 取决 于用 户。 节点 失效 时， 下面 列出 几种 方 案供 您选 择：

忽略它！ 在失效节点被恢复或替换之前，还有很多其他节点可以应对节 点失效带来的影响。

把失效的节点从节点列表中移除。做这个操作千万要小心！在默认情况下 （余数式哈希算法），客户端添加或移除节点，会导致所有的缓存数据不可用！

因为哈希参照的节点列表变化了，大部分 key 会因为哈希值的改变而被映射到 （与原来）不同的节点上。

启动热备节点，接管失效节点所占用的 IP。这样可以防止哈希紊乱 （hashing chaos）。

如果希望添加和移除节点，而不影响原先的哈希结果，可以使用一致性哈 希算法 （consistent hashing） 。您可以百度一下一致性哈希算法。支持一致性 哈希的客户端已经很成熟，而且被广泛使用。去尝试一下吧！

两次哈希（reshing）。当客户端存取数据时，如果发现一个节点down 了， 就再做一次哈希 （哈希算法与前一次不同）， 重新选择另一个节点 （需要注 意的时，客户端并没有把 down 的节点从节点列表中移除，下次还是有可能先 哈希到它） 。如果某个节点时好时坏， 两次哈希的方法就有风险了， 好的节点和 坏的节点上都可能存在脏数据（stale data）。

13、如何将 memcached 中 item 批量导入导出？

您不 应该 这样 做！ Memcached 是一 个非 阻塞 的服 务器 。任 何可 能导 致 memcached 暂停 或瞬 时拒 绝服 务的 操作 都应 该值 得深 思熟 虑。 向 memcached 中批 量导 入数 据往 往不 是您 真正 想要 的！ 想象 看， 如果 缓存 数据 在导 出导 入之 间 发生 了变 化， 您就 需要 处理 脏数 据了；

14、如果缓存数据在导出导入之间过期了，您又怎么处理这些数据呢？

因此， 批 量导 出导 入数 据并 不像 您想 象中 的那 么有 用。 不过 在一 个场 景倒 是很 有 用 。 如果 您有 大量 的从 不变 化的 数据， 并且 希望 缓存 很快 热 （warm） 起来， 批量 导入 缓存 数据 是很 有帮 助的 。虽 然这 个场 景并 不典 型， 但却 经常 发生， 因 此我 们 会考 虑在 将来 实现 批量 导出 导入 的功 能。

如果 一个 memcached 节点 down 了让 您很 痛苦，那么 您还 会陷 入其 他很 多麻 烦 。 您的 系统 太脆 弱了 。您 需要 做一 些优 化工 作。 比如 处理 ”惊群 ”问题 （比 如 memcached 节点 都失 效了，反复 的查 询让 您的 数据 库不 堪重 负 … 这个 问题 在 FAQ 的其 他提 到过） ， 或者 优化 不好 的查 询。 记住， Memcached 并不 是您 逃避 优化 查询 的借 口。

15、 memcached 是如何做身份验证的？

没有 身份 认证 机制！ memcached 是运 行在 应用 下层 的软 件 （身份 验证 应该 是应 用 上层 的职 责） 。 memcached 的客 户端 和服 务器 端之 所以 是轻 量级 的， 部分 原因 就 是完 全没 有实 现身 份验 证机 制 。这样， memcached 可以 很快 地创 建新 连接， 服务 器端 也无 需任 何配 置。

如果 您希 望限 制访 问，您可 以使 用防 火墙，或者 让 memcached 监听 unix domain socket。

16、 memcached 的多线程是什么？如何使用它们？

线程 就是 定律 （threads rule） ！ 在 Steven Grimm 和 Facebook 的努 力下 ， memcached 1.2 及更 高版 本拥 有了 多线 程模 式 。多线 程模 式允 许 memcached 能 够充 分利 用多 个 CPU， 并在 CPU 之间 共享 所有 的缓 存数 据 。 memcached 使用 一 种简 单的 锁机 制来 保证 数据 更新 操作 的互 斥。 相比 在同 一个 物理 机器 上运 行多 个 memcached 实例， 这 种方 式能 够更 有效 地处 理 multi gets。

如果 您的 系统 负载 并不 重， 也许 您不 需要 启用 多线 程工 作模 式。 如果 您在 运行 一 个拥 有大 规模 硬件 的、 庞大 的网 站， 您将 会看 到多 线程 的好 处。

简单 地总 结一 下： 命令 解析 （memcached在这 里花 了大 部分 时间） 可以 运行 在多 线程 模式 下 。memcached 内部 对数 据的 操作 是基 于很 多全 局锁 的 （因此 这部 分工 作不 是多 线程 的） 。未 来对 多线 程模 式的 改进， 将 移除 大量 的全 局锁， 提 高 memcached 在负 载极 高的 场景 下的 性能 。

17、 memcached 能接受的 key 的最大长度是多少？

key 的最 大长 度是 250 个字 符。 需要 注意 的是， 250 是 memcached 服务 器端 内 部的 限制， 如果 您使 用的 客户 端支 持”key 的前 缀 ”或类 似特 性， 那么 key （前缀 +原始 key）的最 大长 度是 可以 超过 250 个字 符的 。我们 推荐 使用 使用 较短 的 key， 因为 可以 节省 内存 和带 宽。

memcached 对 item 的过 期时 间有 什么 限制？

过期 时间 最大 可以 达到 30 天 。 memcached 把传 入的 过期 时间 （时间 段） 解释 成 时间 点后， 一旦 到了 这个 时间 点， memcached 就把 item 置为 失效 状态 。 这是 一 个简 单但 obscure 的机 制。

18、 memcached 最大能存储多大的单个 item？

1MB。如 果你 的数 据大 于 1MB， 可 以考 虑在 客户 端压 缩或 拆分 到多 个 key 中。 为什 么单 个 item 的大 小被 限制 在 1M byte 之内？

啊 … 这是 一个 大家 经常 问的 问题！

简单 的回 答： 因为 内存 分配 器的 算法 就是 这样 的。

详细 的回 答： Memcached 的内 存存 储引 擎 （引擎 将来 可插 拔 …） ， 使用 slabs 来 管理 内存 。 内存 被分 成大 小不 等的 slabs chunks （先分 成大 小相 等的 slabs， 然后 每个 slab 被分 成大 小相 等 chunks，不同 slab 的 chunk 大小 是不 相等 的）。chunk 的大 小依 次从 一个 最小 数开 始， 按某 个因 子增 长， 直到 达到 最大 的可 能值 。

19、 memcached 能够更有效地使用内存吗？

Memcache 客户 端仅 根据 哈希 算法 来决 定将 某个 key 存储 在哪 个节 点上， 而不 考 虑节 点的 内存 大小 。因 此， 您可 以在 不同 的节 点上 使用 大小 不等 的缓 存。 但是 一 般都 是这 样做 的： 拥有 较多 内存 的节 点上 可以 运行 多个 memcached 实例， 每 个 实例 使用 的内 存跟 其他 节点 上的 实例 相同 。

20、什么是二进制协议，我该关注吗？

关于 二进 制最 好的 信息 当然 是二 进制 协议 规范：

二进 制协 议尝 试为 端提 供一 个更 有效 的、 可靠 的协 议， 减少 客户 端/服务 器端 因处 理协 议而 产生 的 CPU 时间 。

根据 Facebook 的测 试，解析 ASCII 协议 是 memcached 中消 耗 CPU 时间 最多 的 环节 。所 以， 我们 为什 么不 改进 ASCII 协议 呢？

21、 memcached 的内存分配器是如何工作的？为什么不适用malloc/free！？为何要使用 slabs？

实际 上， 这是 一个 编译 时选 项。 默认 会使 用内 部的 slab 分配 器。 您确 实确 实应 该 使用 内建 的 slab 分配 器 。 最早 的时 候， memcached 只使 用 malloc/free 来管 理 内存 。然而，这种 方式 不能 与 OS 的内 存管 理以 前很 好地 工作 。反复 地 malloc/free 造成 了内 存碎 片， OS 最终 花费 大量 的时 间去 查找 连续 的内 存块 来满 足 malloc 的 请求， 而不 是运 行 memcached 进程 。 如果 您不 同意， 当然 可以 使用 malloc！ 只

是不 要在 邮件 列表 中抱 怨啊

slab 分配 器就 是为 了解 决这 个问 题而 生的 。 内存 被分 配并 划分 成 chunks， 一直 被 重复 使用 。 因为 内存 被划 分成 大小 不等 的 slabs， 如果 item 的大 小与 被选 择存 放 它的 slab 不是 很合 适的 话， 就会 浪费 一些 内存 。 Steven Grimm 正在 这方 面已 经 做出 了有 效的 改进 。

22、 memcached 是原子的吗？

所有 的被 发送 到 memcached 的单 个命 令是 完全 原子 的。 如果 您针 对同 一份 数据 同时 发送 了一 个 set 命令 和一 个 get 命令， 它们 不会 影响 对方 。 它们 将被 串行 化 、 先后 执行 。即 使在 多线 程模 式， 所有 的命 令都 是原 子的， 除 非程 序有 bug:)

命令 序列 不是 原子 的。 如果 您通 过 get 命令 获取 了一 个 item， 修 改了 它， 然后 想 把它 set 回 memcached， 我 们不 保证 这个 item 没有 被其 他进 程（process， 未 必是 操作 系统 中的 进程） 操 作过 。在 并发 的情 况下， 您 也可 能覆 写了 一个 被其 他 进程 set 的 item。

memcached 1.2.5 以及 更高 版本， 提 供了 gets 和 cas 命令， 它 们可 以解 决上 面 的问 题。 如果 您使 用 gets 命令 查询 某个 key 的 item， memcached 会给 您返 回 该 item 当前 值的 唯一 标识 。如果 您覆 写了 这个 item 并想 把它 写回 到 memcached 中， 您可 以通 过 cas 命令 把那 个唯 一标 识一 起发 送给 memcached 。 如果 该 item 存放 在 memcached 中的 唯一 标识 与您 提供 的一 致， 您的 写操 作将 会成 功。 如果 另一 个进 程在 这期 间也 修改 了这 个 item， 那么 该 item 存放 在 memcached 中的 唯一 标识 将会 改变， 您 的写 操作 就会 失败

23、如何实现集群中的 session 共享存储？

Session 是运 行在 一台 服务 器上 的， 所有 的访 问都 会到 达我 们的 唯一 服务 器上， 这 样我 们可 以根 据客 户端 传来 的 sessionID， 来获 取 session， 或在 对应 Session 不 存在 的情 况下（session 生命 周期 到了/用户 第一 次登 录），创建 一个 新的 Session； 但是， 如 果我 们在 集群 环境 下， 假设 我们 有两 台服 务器 A， B， 用 户的 请求 会 由 Nginx 服务 器进 行转 发（别的 方案 也是 同理） ， 用户 登录 时， Nginx 将请 求转 发 至服 务器 A 上， A 创建 了新 的 session， 并将 SessionID 返回 给客 户端， 用户 在浏 览其 他页 面时， 客 户端 验证 登录 状态， Nginx 将请 求转 发至 服务 器 B， 由 于 B 上 并没 有对 应客 户端 发来 sessionId 的 session，所以 会重 新创 建一 个新 的 session， 并且 再将 这个 新的 sessionID 返回 给客 户端， 这 样， 我们 可以 想象 一下， 用 户每 一次 操作 都有 1/2 的概 率进 行再 次的 登录， 这 样不 仅对 用户 体验 特别 差， 还会 让 服务 器上 的 session 激增， 加 大服 务器 的运 行压 力。

为了 解决 集群 环境 下的 seesion 共享 问题， 共 有 4 种解 决方 案：

1.粘性 session

粘性 session 是指 Ngnix 每次 都将 同一 用户 的所 有请 求转 发至 同一 台服 务器 上， 即将 用户 与服 务器 绑定 。

2.服务 器 session 复制

即每 次 session 发生 变化 时， 创建 或者 修改， 就 广播 给所 有集 群中 的服 务器， 使 所有 的服 务器 上的 session 相同 。

3.session 共享

缓存 session， 使 用 redis， memcached。

4.session 持久 化

将 session 存储 至数 据库 中， 像操 作数 据一 样才 做 session。

24、 memcached 与 redis 的区别？

1 、 Redis 不仅 仅支 持简 单的 k/v 类型 的数 据， 同时 还提 供 list， set， zset， hash 等数 据结 构的 存储 。 而 memcache 只支 持简 单数 据类 型， 需要 客户 端自 己处 理复 杂对 象

2 、 Redis 支持 数据 的持 久化， 可 以将 内存 中的 数据 保持 在磁 盘中， 重 启的 时候 可 以再 次加 载进 行使 用（PS： 持 久化 在 rdb 、 aof） 。

3、 由 于 Memcache 没 有 持 久 化 机 制， 因 此 宕 机 所 有 缓 存 数 据 失 效 。 Redis 配 置 为 持 久 化， 宕 机 重 启 后， 将 自 动 加 载 宕 机 时 刻 的 数 据 到 缓 存 系 统 中 。 具 有 更 好 的 灾 备 机 制 。

4 、 Memcache 可 以 使 用 Magent 在 客 户 端 进 行 一 致 性 hash 做 分 布 式 。 Redis 支 持 在 服 务 器 端 做 分 布 式（PS:Twemproxy/Codis/Redis-cluster 多 种 分 布 式 实 现 方 式）

5 、 Memcached 的 简 单 限 制 就 是 键 （key） 和 Value 的 限 制 。 最 大 键 长 为 250 个 字 符 。 可 以 接 受 的 储 存 数 据 不 能 超 过 1MB （可 修 改 配 置 文 件 变 大） ， 因 为 这 是 典 型 slab 的 最 大 值， 不 适 合 虚 拟 机 使 用 。 而 Redis 的 Key 长 度 支 持 到 512k。

6 、 Redis 使 用 的 是 单 线 程 模 型， 保 证 了 数 据 按 顺 序 提 交 。 Memcache 需 要 使 用 cas 保 证 数 据 一 致 性 。 CAS （Check and Set） 是 一 个 确 保 并 发 一 致 性 的 机 制， 属 于 “ 乐 观 锁 ”范 畴； 原 理 很 简 单： 拿 版 本 号， 操 作， 对 比 版 本 号， 如 果 一 致 就 操 作， 不 一 致 就 放 弃 任 何 操 作cpu 利 用 。 由 于 Redis 只 使 用 单 核， 而 Memcached 可 以 使 用 多 核， 所 以 平 均 每 一 个 核 上 Redis 在 存 储 小 数 据 时 比 Memcached 性 能 更 高 。 而 在 100k 以 上 的 数 据 中， Memcached 性 能 要 高 于 Redis 。

7 、 memcache 内 存 管 理： 使 用 Slab Allocation。 原 理 相 当 简 单， 预 先 分 配 一 系 列 大 小 固 定 的 组， 然 后 根 据 数 据 大 小 选 择 最 合 适 的 块 存 储 。 避 免 了 内 存 碎 片 。 （缺 点： 不 能 变 长， 浪 费 了 一 定 空 间） memcached 默 认 情 况 下 下 一 个 slab 的 最 大 值 为 前 一 个 的 1.25 倍 。

8、redis 内 存 管 理： Redis 通 过 定 义 一 个 数 组 来 记 录 所 有 的 内 存 分 配 情 况， Redis 采 用 的 是 包 装 的 malloc/free， 相 较 于 Memcached 的 内 存 管 理 方 法 来 说， 要 简 单 很 多 。由 于 malloc 首 先 以 链 表 的 方 式 搜 索 已 管 理 的 内 存 中 可 用 的 空 间 分 配， 导 致 内 存 碎 片 比 较 多