Hunter的大杂烩 技术学习笔记

July 15, 2008

Federation at Flickr: Doing Billions of Queries Per Day

Filed under: 架构 — hunter @ 11:28 pm

近期highscalability上有一篇文章,介绍了由flickr的数据库高人撰写的flicker的数据库设计,作者说,如果你想知道自己的sharding是否做对,一定要拜读该文。(ppt的title中赫然见到”Federation”一词,难道又会创造一个Federation热吗?) (另,这个ppt里其实没有很多有用的内容,可能更多是通过口头表达的)

flickr架构就不多说了,可以参见highscalability.com的文章 dbanotes上的介绍

ppt主要介绍flickr 遇到的几个问题,以及是如何解决的:

1. mysql master-slave 拓扑问题

将数据sharding分布

建立master-master ring来解决写入的问题

 — 据作者说是为了解决写入点的问题,但是master-master ring可能会使得数据库的写请求量过大,影响读请求的服务

flickr.gif

在应用层实现”分布式事务 ”

  — web 2.0的shard架构决定了分布式事务比较难做
2. slave lag问题

slide标题是”Getting Rid of Replication Lag” ,但是感觉是一个数据定位以及容错的方法:

$id = intval(substr($user_id, -10));
$id % $count_of_hosts_in_shard
—  If host is down, go to the next host in the list
—  If all hosts are down, display error page

3. 系统中的单故障点

通过master-master ring,并且每个server(shard)只提供 50%的服务能力,保证随时可以停止其中一半的服务器进行维护,提升维护能力。
4. 系统无法满足用户需求

5. 无法处理搜索请求

提供两种搜索服务,其一是”single tag search”,用shards来实现,其他的后台调用yahoo搜索服务

6. Multiple Second page load times

其他的一些小tips:

1. 把交换区设置为0 ??

2. 将2.6 kernel 的调度器算法调整为”DEADLINE”?

3. 使用 RAID 10 (最近我们内部的测试似乎表明 10跟5之间的差距不大)

4. 使用 “Battery Back cache” — 啥东东?

5. 64bit system

6. 更多的内存,但是要留下足够给系统生成线程;

7. 优化query

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress