Memcached 依赖项

发布于 2024-10-19 13:34:23 字数 642 浏览 0 评论 0原文

我正在使用 memcahced (特别是 Enyim memcached 客户端),我希望能够使缓存中的键依赖于其他键,即,如果键 A 依赖于键B,那么每当密钥B被删除或更改时,密钥A也会失效。

如果可能的话,我还想确保在集群中的节点发生故障的情况下保持数据完整性,即如果密钥B在某个时候不可用,密钥A如果密钥 B 无效,> 仍应无效。

基于这篇文章我相信这是可能的,但我正在努力理解该算法,以说服自己这是如何/为什么起作用的。

有人可以帮我吗?

I'm using memcahced (specifically the Enyim memcached client) and I would like to able to make a keys in the cache dependant on other keys, i.e. if Key A is dependent on Key B, then whenever Key B is deleted or changed, Key A is also invalidated.

If possible I would also like to make sure that data integrity is maintained in the case of a node in the cluster fails, i.e. if Key B is at some point unavailable, Key A should still be invalid if Key B should become invalid.

Based on this post I believe that this is possible, but I'm struggling to understand the algorithm enough to convince myself how / why this works.

Can anyone help me out?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

秋意浓 2024-10-26 13:34:23

我最近经常使用 memcached,我确信您尝试对依赖项执行的操作不可能“按原样”使用 memcached,而是需要从客户端处理。此外,数据复制应该发生在服务器端而不是客户端,这是两个不同的域。 (至少对于 memcached,看到它缺乏数据存储逻辑。尽管 memcached 的要点就在于,极端简约以获得更好的性能)

对于数据复制(防止物理故障集群节点),您应该查看 membased http://www.couchbase.org/get/couchbase/current

对于 deps 算法,我可以在客户端中看到类似的内容:对于任何给定的键,都有一个可疑的附加键保存依赖键的列表/数组。

# - delete a key, recursive:
function deleteKey( keyname ):
    deps = client.getDeps( keyname ) #
    foreach ( deps as dep ):
        deleteKey( dep )
        memcached.delete( dep )
    endeach
    memcached.delete( keyname )
endfunction

# return the list of keynames or an empty list if the key doesnt exist
function client.getDeps( keyname ):
    return memcached.get( key_name + "_deps" ) or array()
endfunction

# Key "demokey1" and its counterpart "demokey1_deps". In the list of keys stored in
# "demokey1_deps" there is "demokey2" and "demokey3".
deleteKey( "demokey1" );
# this would first perform a memcached get on "demokey1_deps" then with the
# value returned as a list of keys ("demokey2" and "demokey3") run deleteKey()
# on each of them.

干杯

I've been using memcached quite a bit lately and I'm sure what you're trying to do with depencies isn't possible with memcached "as is" but would need to be handled from client side. Also that the data replication should happen server side and not from the client, these are 2 different domains. (With memcached at least, seeing its lack of data storage logic. The point of memcached though is just that, extreme minimalism for bettter performance)

For the data replication (protection against a physical failing cluster node) you should check out membased http://www.couchbase.org/get/couchbase/current instead.

For the deps algorithm, I could see something like this in a client: For any given key there is a suspected additional key holding the list/array of dependant keys.

# - delete a key, recursive:
function deleteKey( keyname ):
    deps = client.getDeps( keyname ) #
    foreach ( deps as dep ):
        deleteKey( dep )
        memcached.delete( dep )
    endeach
    memcached.delete( keyname )
endfunction

# return the list of keynames or an empty list if the key doesnt exist
function client.getDeps( keyname ):
    return memcached.get( key_name + "_deps" ) or array()
endfunction

# Key "demokey1" and its counterpart "demokey1_deps". In the list of keys stored in
# "demokey1_deps" there is "demokey2" and "demokey3".
deleteKey( "demokey1" );
# this would first perform a memcached get on "demokey1_deps" then with the
# value returned as a list of keys ("demokey2" and "demokey3") run deleteKey()
# on each of them.

Cheers

娇纵 2024-10-26 13:34:23

我不认为这是一个直接的解决方案,但尝试在内存缓存键中创建一个命名空间系统,例如 http://www.cakemail.com/namespacing-in-memcached/。简而言之,生成的键包含其他 memcached 键的当前值。在命名空间问题中,其想法是使特定命名空间内的整个范围的键无效。这是通过增加命名空间键的值之类的方法来实现的,并且在重新生成该键时,引用先前命名空间值的任何键都将不匹配。

你的问题看起来有点不同,但我认为通过将Key A设置在Key B“命名空间中,如果节点B不可用,则计算密钥 A 的完整命名空间密钥例如

"Key A|Key B:<whatever Key B value is>"

将返回 false,从而允许您确定 B 不可用并使密钥 A 的缓存查找无效。

I don't think it's a direct solution but try creating a system of namespaces in your memcache keys, e.g. http://www.cakemail.com/namespacing-in-memcached/. In short, the keys are generated and contain the current values of other memcached keys. In the namespacing problem the idea is to invalidate a whole range of keys who are within a certain namespace. This is achieved by something like incrementing the value of the namespace key, and any keys referencing the previous namespace value will not match when the key is regenerated.

Your problem looks a little different, but I think that by setting up Key A to be in the Key B "namespace, if a node B was unavailable then calculating Key A's full namespaced key e.g.

"Key A|Key B:<whatever Key B value is>"

will return false, thus allowing you to determine that B is unavailable and invalidate the cache lookup for Key A.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文