memcached数据缓存的设计模式

Question

在现有数据库查询周围包装可选的memcached缓存很容易.例如:

旧(仅限DB):

function getX
    x = get from db
    return x
end

新(带memcache的DB):

function getX
    x = get from memcache
    if found
      return x
    endif

    x = get from db
    set x in memcache
    return x
end

但问题是,并不总是如此缓存.例如,请执行以下两个查询:

-- get all items (recordset)
SELECT * FROM items;

-- get one item (record)
SELECT * FROM items WHERE pkid = 42;

如果我使用上面的伪代码来处理缓存,我会将项目42的所有字段存储两次.一旦进入大记录集并且一次独立.而我宁愿做这样的事情:

SELECT pkid FROM items;

并缓存PK的索引.然后单独缓存每条记录.

总而言之,最适合数据库的数据访问策略并不完全适合内存缓存策略.因为我希望memcache层是可选的(即如果内存缓存已关闭,网站仍然有效)我想要两全其美,但为了这样做,我很确定我需要维护一个很多查询有两种不同的形式(1.获取索引,然后是记录;以及2.在一个查询中获取记录集).分页越复杂.使用DB,您可以执行LIMIT/OFFSET SQL查询,但是使用memcache,您只需获取PK的索引,然后批量获取数组的相关切片.

我不确定如何整齐地设计这个,有没有人有任何建议？

更好的是,如果你自己反对这一点.你怎么处理它？

Answer 1

好吧，我想这是你必须忍受的事情。如果您不真正批量执行操作，Memcahced 将发挥最佳作用。例如，它非常适合诸如“该用户的东西在哪里？这里有很多该用户的东西”之类的内容。这并不真正意味着该查询不执行批处理。当然会 - 如果某些用户的东西像他/她的帖子一样。

我想您会遇到的问题是，您混合了需要从数据库中获取项目的查询和一些需要获取大量相同类型的先前项目的查询。

情况总是有另一面。如果你真的想让你的实现变得毛茸茸的，你可以更改你的批量查询以不包括memcached中已经存在的项目。非常非常难看......

在我看来，它总是归结为“我真正想要缓存哪些查询？”

编辑：

我会采取的方式是：

• 单项查询 - 如果在 memcached 中，则使用该查询，否则从数据库获取并更新 memcached。
• 批量查询 - 不用担心哪些项目在 memcached 中，只需获取所有内容并更新 memcached 即可。

当然，这假设批量查询已经花费了更多的时间来完成，因此我已经花费了很多时间，我可以忍受对已缓存项目的外部查找。

但是，如果您大量使用批量查询，最终您的缓存将包含大量项目。因此，您必须取得平衡，以确定何时仍要执行数据库查找。好处是，如果批量查询位于应用程序生命周期的早期，那么所有内容都会更早缓存。在第一个批量查询之后，您可以告诉自己，您不再需要从数据库中获取数据，除非缓存中的数据因更新或删除而失效。