上文

Cache Money真正牛X的地方是在Vector Cache。在生产环境中,它不仅相对Object Cache命中率较更高,带来的性能飞跃更是可观。

在MoSonic的性能测试中,得到了有10倍的性能提高。

Vector Cache性能恐怖,但它对表结构,查询类型,有相当的严格的要求;列举如下:

  • 表必须以自增数字(int / long)id为主键
  • 查询的where中必须是 = 等于条件,如where user_id=1
  • 多个where条件的话,相互关系必须是And,如where user_id=1 and id_deleted=0
  • 查询结果仅能是数据id,如 select id from users where ... 不可以是 select user_name from users where ...
    • 也可以是 select count(*) from users where ...
    • 查询结果支持分页
  • 查询结果必须以id排倒序,也就是order by id desc

只有完全符合上面五个条件,Vector Cache才可以生效;幸运的是,在web 2.0网站中,这类结构/查询正好是最常见的。

以博客为例,博客文章列表显示,分类文章数量,评论显示等等,基本都符合上述的查询。

比方说,要获得等级为1的用户时,需要使用下面的两个查询:

 

  • select id from users where level=1
  • select * from users where id in (....)

 

两个查询cache money都可以完全缓存,如果直接使用:

 

  • select * from users where level=1

 

的话,cache money则会完全失效。

对于两种风格的查询孰优孰劣,可以参考JavaEye老大Robin之前写的:为什么ORM性能比iBATIS好

=============

因为要求了查询结果必须是id,并且排倒序,Vector Cache实际上是可以做到实时自动更新,而不是自动过期。

考虑这样的调用:

 

  1. select count(id) from photos where album_id=1 order by id desc limit 1, 100
  2. select id from photos where album_id=1 order by id desc limit 1, 100
  3. insert into photos (album_id)values(1)
  4. select count(id) from photos where album_id=1 order by id desc limit 1, 100
  5. select id from photos where album_id=1 order by id desc limit 1, 100

 

显示列表,插入数据,再次显示列表;这是相当典型调用。

第1/2步查询会有缓存(即便是没有缓存,查询之后,缓存也会自动被生成,也就是所谓的直读)。

第3步插入数据时,获得数据库自增的ID后,可以直接将此id追加到第1/2步查询缓存结果中。

第4/5步查询直接命中第3步写数据时更新的缓存;完全无需查询数据库。

在查询、应用场景符合的理想情况下,有了Vector Cache,数据库读可以变成恐怖的0读取

数据库仅需要承担写压力,100%的读都有Memcache的自动缓存。

这才是Cache Money的Vector Cache带来读性能飞跃的原因。

所有的数据库查询都变成了memcache get;memcache单机时在读能力,并发负荷能力上都要比传统关系型数据库高一个数量级;而且其shared nothing的架构,又可以水平扩张。

在高并发,多机缓存的情况下,可以预料Cache Money带来的读性能提高远不止10倍。

==============

Twitter的工程师对Cache Money的实现相当巧妙,他们针对一个限制多多的场景做到了100%的读缓存;而这个“限制多多”又恰恰是web 2.0网站中的最典型场景。

我在MoSonic中实现Vector Cache时,完全照搬了Cache Money的实现算法;就是C#的代码量比ruby膨胀了几倍。

:)

下篇会继续讲MoSonic对FriendFeed分布式数据库设计的引用。