主题：【半原创】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的比较
🙂１。这个原因我已经写了 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