Memcached对密钥（250？）和值（差不多1 MB）有长度限制，还有一些（据我所知）对密钥没有很好定义的字符限制。在您看来，解决这些问题的最佳方法是什么？我使用Perl API Cache :: Memcached。
如果原始值太大（“parts：＆lt; number＆gt;”），我目前所做的是存储主键值的特殊字符串，在这种情况下，我存储＆lt; number＆gt;具有名为1 +＆lt; main key＆gt;，2 +＆lt; main key＆gt;的键的部件对某些情况来说，这似乎“好”（但很乱），对其他人来说不太好，而且它有一些固有的问题，即某些部分可能随时都会丢失（因此空间被浪费以保留其他部分和时间是浪费了阅读它们。）
至于关键限制，人们可能会实现散列并在值中存储完整的密钥（以解决冲突），但我还不需要这样做。
有没有人提出更优雅的方式，甚至是透明处理任意数据大小（和键值）的Perl API？有没有人黑客入侵memcached服务器以支持任意键/值？
答案 0 :(得分：20)
服务器已经允许您指定所需的大小：
-I Override the size of each slab page. Adjusts max item size
(default: 1mb, min: 1k, max: 128m)
然而，大多数时候，当人们想要缓存更大的对象时，他们做错了什么。你真的需要一个缓存密钥中的那么多数据吗？未压缩？
如果您有足够大的任务，则实际传输数据所需的时间相比，低延迟访问的好处相形见绌。或者你发现在同一个键中抛出所有东西意味着你的前端最终不得不做大量的工作来反序列化他们想要的一些数据。
这取决于您的需求，如果不了解您正在做的事情，我无法告诉您什么对您最好。如果你确实需要大于1MB的东西，那就是我们添加-I的原因了。
答案 1 :(得分：9)
$键= ABS（CRC32（$ long_key））
这样你就获得了独特的钥匙 查询和其他可能的长键 有超过250个字符的变化 memcache看到了。
哇......小心。很好的建议，但没有重要的警告。这可能会导致碰撞。当然这是非常不可能的，但它只需要发生一次，以造成一个惊天动地的错误。您仍然可能希望使用memcached存储长密钥，并始终仔细检查密钥上的冲突。处理它们的最佳方法是存储一个简单的long_key / value对列表。
答案 2 :(得分：0)
对于太大的值，我们存储了一个键列表，而不是存储标准值（当解码时，它总是字典）。然后我们读取每个键中的数据，并恢复主值。我认为当它们太长时（我们的数据集可能会发生，但极少发生），我们也会对键进行哈希处理。
我们确实在memcached客户端（我们使用的是Python）之上直接编写了所有这些代码，因此在更高级别它完全透明。
答案 3 :(得分：-1)
与初始问题没有实际关系，但如果您考虑转换到APC：最大值。 len for keys是9727个字符。 （在PHP 5.3.2上测试）
答案 4 :(得分：-2)
$key=abs(crc32($long_key))
通过这种方式，您可以获得查询和其他长密钥的唯一密钥，这些密钥可能会有超过250个字符的memcache所见的更改。