主题:【半原创】Flickr 网站架构研究(1) -- 西电鲁丁
共:💬69 🌺366
1.
Flickr为中央数据库配置了Memcached作为数据库缓存,接下来的问题是,为什么用Memcached?为什么Shard不需要Memcached?Memcached和Master,Slave的关系怎样?
增加一个问题,从第一篇的图中看,Central DB同Shard一样,也有Master和Slave的配合。所以问题是,既然Central DB已经有了Slave,负责“读”,为什么还另外需要MemCached?
2.
"Write Through Cache"就是将所有的数据库”写“操作都先写入”Cache",然后由Cache统一去更新数据库的各个Node,“Write Through Cache"维护每一个Node的更新状态,当有读请求时,即将请求转向状态为”已同步“的Node,这样即避免了复制滞后和Memcached的同步问题,但缺点是其实现极为复杂
这里所说的“Cache”,是不是指MemCached?如果是这样的话,任何对Central DB的更改,先要放到MemCached里去,然后再push到Central DB?
这样颠倒主次关系的做法,是不是很容易make troubles?
- 相关回复 上下关系8
压缩 3 层
🙂【原创】Flickr 网站架构研究(4) 19 西电鲁丁 字4650 2009-09-06 01:41:51
🙂深入浅出,写得真好,一个小疑问。 1 邓侃 字1023 2009-09-20 20:07:11
🙂嗯,欢迎拍砖。 3 西电鲁丁 字924 2009-09-20 22:24:26
🙂关于MemCache与Slave的比较
🙂1。这个原因我已经写了 2 西电鲁丁 字1088 2009-08-27 22:05:54
🙂我的问题应该这样表述 邓侃 字249 2009-08-27 22:15:16
🙂不完全是Flickr网站一家的问题 1 西电鲁丁 字372 2009-08-27 22:44:05
🙂这个观点有说服力 邓侃 字147 2009-08-27 22:52:46