赞美memcached

# 赞美 memcached 来源：https://jchri.st/blog/in-praise-of-memcached/ 如果你碰巧担任系统管理员，或者只是恰好负责维护某人的基础设施（https://github.com/python-discord/infra），那么很可能在某个时刻，你会听到“我们需要一个缓存”的话题。 你稍作思索，然后伸手拿起了 Redis，因为你习惯了它，它功能齐全，而且确实能工作！你记得它是一个优秀、稳定的缓存，好奇新版本带来了哪些新功能，于是前往它的主页： > 你的智能体并没有失败，是它们的上下文出了状况。**好奇的智能体想知道：** 我该如何将 Redis Iris 用作 AI 应用的实时上下文引擎？1 (https://jchri.st/blog/in-praise-of-memcached/#fn:1) 没错，大概又跟 AI2 (https://jchri.st/blog/in-praise-of-memcached/#fn:2) 有关。这倒也情有可原，因为 Redis 是一家需要赚钱的公司。 不管怎样，先不管 Redis 的主页，你部署了它，然后一切顺利——你那可靠的缓存。你把连接字符串交给提出需求的人，然后事情就告一段落。 ## 几个月后 过了一段时间，人们发现 `cache.set("key", "value")` 是一个非常简单的抽象，显然比 `INSERT INTO table VALUES ('key', 'value')` 要简单得多。于是大家开始把*REmote DIctionary Server*（远程字典服务器）当作一种*始终存在*、*持久化*数据、*就是数据库*的东西。 你对此一无所知，你的运维同事也不知道。因此，你的告警系统同样对此一无所知，因为你假设大家都把*缓存*当作易失性数据来对待。 当你偶然对 Redis 做了点什么——比如升级、迁移到另一个节点，或者你的猫按下了 RAID0 服务器硬盘托架的弹出按钮——你才会发现这个问题已经持续了多久。 问题不在于 Redis 没有持久化能力，而在于通常 Redis 是被作为*缓存*引入技术栈的，并且所有人都假设大家会以缓存的方式来使用它。 通常，当你意识到这一点时，已经为时已晚，Redis 已经和应用程序纠缠得太深，无法轻易替换。于是，你只能永远享受像养宠物一样维护和监控它的乐趣。 ## 进入 memcached 首先——memcached 是什么？很简单，问问它的网站（https://memcached.org/）就知道了： > **Memcached 是什么？** 免费开源、高性能、分布式内存对象缓存系统，本质通用，但旨在通过减轻数据库负载来加速动态 Web 应用。3 (https://jchri.st/blog/in-praise-of-memcached/#fn:3) 哇，页面第一句话就直截了当，甚至还附带了代码示例。再看看顶部那些可爱的小吉祥物！ Memcached 也是一种缓存，与 Redis 类似。你可能正在使用像 Django 这样的框架，它支持可插拔的缓存（https://docs.djangoproject.com/en/6.0/topics/cache/），允许你在不同的缓存后端之间切换。 但**为什么你应该使用 memcached**，尽管它的功能远不如 Redis 丰富？以下是我现在总是倾向于选择 memcached 而非 Redis 的原因： - **处理 memcached 宕机**极为容易，因为客户端库通常忽略连接异常。例如，如果服务器宕机，一个简单的 `get` 只会返回默认值（或空值）。 - **对 memcached 进行集群**非常棒，因为 memcached 实际上没有内置集群功能。要实现“集群”，你只需在客户端库中配置多个 URL4 (https://jchri.st/blog/in-praise-of-memcached/#fn:4)，客户端会基于键的哈希来选择目标实例。如果客户端调用检测到某个实例失效，它会将该节点从哈希器中移除（https://pymemcache.readthedocs.io/en/latest/getting_started.html#using-a-memcached-cluster）。过一段时间后，客户端会自动尝试重新连接并使用该失效节点。 - memcached “解决”了整个持久化问题，因为它根本不会持久化到磁盘。因此，它非常适合被当作无状态工作负载，在你希望的任意位置进行调度。 这些在 Redis 中并非不可能实现，只不过 memcached 的架构总体更倾向于这些方向，这使得从运维角度来看，它要简单直接得多。 但是，由于 memcached 本身相对简单（而且你可以用大约 64 MB 的缓存大小运行几十个实例，几乎没有额外开销），如今如果需要缓存，我通常会选择 memcached。 话虽如此，许多“数据库太慢”的问题其实始于“查询太慢”或“缺少索引”，所以做个好人，帮助你的开发人员优化查询吧。 另外，如果你对 memcached 背后的某些决策感兴趣，它的博客（https://memcached.org/blog）上有一些有趣的文章，其中一篇就在五月发布：《那个响应到底花了多长时间……真的吗？》（https://memcached.org/blog/how-long-for-real/）。