您如何解决 memcached 的键/值限制？答案

【问题标题】：How do you work around memcached's key/value limitations?您如何解决 memcached 的键/值限制？
【发布时间】：2009-07-14 14:32:59
【问题描述】：

Memcached 对键（250？）和值（大约 1MB）有长度限制，以及一些（据我所知）对键的字符限制不是很明确。在您看来，解决这些问题的最佳方法是什么？我使用 Perl API Cache::Memcached。

如果原始值太大（“parts:”），我目前所做的是为主键的值存储一个特殊字符串，在这种情况下，我使用名为 1+ 个部分main key>、2+

等。在某些情况下，这似乎“OK”（但很乱），对其他人来说不太好，而且它的内在问题是某些部分可能随时丢失（所以空间浪费在保存其他内容上，时间浪费在阅读上）。

至于密钥限制，可能可以实现散列并将完整密钥（以解决冲突）存储在值中，但我还不需要这样做。

有没有人想出一种更优雅的方法，或者甚至是透明地处理任意数据大小（和键值）的 Perl API？是否有人破解了 memcached 服务器以支持任意键/值？

【问题讨论】：

标签： memcached

【解决方案1】：

服务器已经允许你指定你想要的任何大小：

-I            Override the size of each slab page. Adjusts max item size
              (default: 1mb, min: 1k, max: 128m)

但是，大多数时候，当人们想要缓存更大的对象时，他们做错了。您真的需要 one 缓存键中的那么多数据吗？未压缩？

如果您有足够大的任务，那么低延迟访问的好处与您实际传输数据所需的时间相比相形见绌。或者您发现将所有内容都放在同一个键中意味着您的前端最终不得不做大量工作来反序列化他们想要的一些数据。

这取决于您的需求，如果不了解您在做什么，我无法告诉您什么最适合您。如果您确实需要大于 1MB 的内容，这就是我们添加 -I 的原因。

【讨论】：

【解决方案2】：

$key=abs(crc32($long_key))

通过这种方式，您可以获得唯一的密钥查询和其他可能的长键有超过 250 个字符的更改 memcache 看到了。

哇……小心点。很好的建议，但没有重要的警告。这可能会导致碰撞。当然这是非常不可能的，但它只需要发生一次就会导致一个惊天动地的错误。您可能仍然希望使用 memcached 存储长密钥，并始终仔细检查密钥处的冲突。处理它们的最佳方法是存储一个简单的 long_key/value 对列表。

【讨论】：

在（大多数）场景中，您使用 memcached 缓存保存在其他地方的数据，发生冲突的可能性消除了程序对此的担忧。简单地监视 memcached 的高冲突率将告诉您是否存在问题，只有这样才值得花时间寻找相互覆盖的密钥。如果正确实施缓存策略并且您正在缓存已持久化的数据，则不会出现惊天动地的错误，只会降低性能。
取决于您要缓存的内容。如果缓存的信息对用户来说是私有的，那么哈希冲突可能意味着泄露私有数据（我称之为惊天动地的错误）。诚然，有一些散列可以有效地使散列冲突概率为零，但 crc32 不是其中之一。只需 77000 多一点的值，哈希冲突的几率就会达到 2 分之一 (preshing.com/20110504/hash-collision-probabilities)。为密钥使用更好的哈希函数会有所帮助，但我所知道的每个哈希表实现都会导致冲突。这并不难；只需存储并检查密钥。

【解决方案3】：

对于太大的值，我们存储了一个键列表，而不是存储标准值（解码时总是字典）。然后我们读取每个键中的数据，并恢复主值。我认为我们还会在密钥太长时对其进行哈希处理（在我们的数据集中可能会发生这种情况，但极少发生）。

我们确实在 memcached 客户端上直接编写了所有这些代码（我们使用的是 Python），因此在更高级别上它都是透明的。

【讨论】：

【解决方案4】：

与最初的问题没有实际关系，但如果您考虑切换到 APC：它的最大值。键的 len 是 9727 个字符。（在 PHP 5.3.2 上测试）

【讨论】：

【解决方案5】：

$key=abs(crc32($long_key))

通过这种方式，您可以获得查询的唯一键和其他长键，这些键的变化可能超出 memcache 看到的 250 个字符。

【讨论】：