需要缓存策略建议

Mic*_*ael 6 memcached caching

我们有一个幻想足球应用程序,它使用memcached和经典的memcached-object-read-with-sql-server-fallback.这很好用,但最近我一直在考虑所涉及的开销以及这是否是最好的方法.

举个例子 - 我们需要生成用户团队的下拉列表,因此我们遵循以下模式:

  1. 从memcached获取用户团队列表
  2. 如果不可用,请从SQL服务器获取列表并存储在memcached中.
  3. 做一个multiget来获得团队对象.
  4. 回退到从sql store加载对象这些.

这一切都很好 - 每个缓存的数据都相对容易缓存和失效,但这有两个主要缺点:

1)因为我们在对象上操作会产生相当大的开销 - 一个团队在memcached中占用了大约100个字节,我们真正需要的是团队名称和ID的列表 - 而不是所有其他的东西.团队对象.

2)由于加载单个对象的后退,在空缓存或项目到期时生成的SQL查询的数量可能很大:1 x Memcached multiget(未命中,导致)1 x SELECT ... FROM Team WHERE Id IN(...)20 x存储在memcached中这样只有这一个查询的21个网络请求,并且IN查询比特定连接慢.

显然我们可以做一个简单的事情

SELECT Id, Name FROM Teams WHERE UserId = XYZ
Run Code Online (Sandbox Code Playgroud)

并缓存结果,但这意味着每当用户创建新团队时,这些数据都需要特别无效.在这种情况下,它可能看起来相对简单,但我们有很多这类查询,其中许多都在不容易失效的轴上运行(比如朋友在特定的团队中创建的团队的ID和名称列表)游戏).

Sooo ..我的问题是 - 你们中是否有人有解决上述缺点的想法,或者我应该接受是否存在开销并且缓存未命中是不好的,与它一起生活?

小智 0

首先,缓存你需要的内容,可能是两个字段,而不是完整的记录。

二、再次缓存需要的内容,将结果集拆成记录,单独缓存