namenode 内存优化问题

众所周知,gfs(hdfs)的master,负责名字空间的管理,名字空间包括
文件和chunk信息,文件到chunk的映射,chunk到chunkserver的映射.
名字空间目前是全内存实现,当文件量
或是 chunk数量
增加,内存也会随着增加,内存优化可以说是master的下一个重大改进.
master组是目前比较通用的解决方案,其中,本人所知的解决方案包括:
1.名字空间划分.
2.名字空间key value化
对于第一种,灵活性差,如果要解决单点故障，需要对每台服务器做服务器组。
对于第二种，其大体的架构如下:
名字空间被key value结构化后,持久化到mysql 中,这里被持久化的名字空间只包括文件
以及文件到chunk的影射信息,而 chunk信息,以及chunk的位置信息,则仍然内存化
master本地包含一个对mysql进行部分缓存的cache
1.角色扮演:master  组中,分为一个leader和多个follower,master通过抢占分布式锁的方法,竞选leader.
2.读: master先读本地cache,如果读不到在读mysql,如果都读不到.说明文件不存在
3.写: 由leader更新mysql,并在分布式锁上置通知位,分布式锁发event通知其他follower,follower收到更新通知后,更新本地cache.

各位同学对这样的架构是否有自己的看法

另外,自己对这样的架构,在某些地方也有一定的
:
1.master与分布式锁断开,此时如果有更新事件,无法从分布式锁获得更新事件,此时,本地的cache会出现失效,却本机并不知道的情况
2.缓存如何设计,才能以最大的性能,满足read,write,open,readdir,exists等操作
3.mysql如何设计,如何分表，如何设计字段,如何建立索引,才能最大程度满足性能
4.单点由master单点转化到mysql单点.

另,感谢国宝给出的架构

能用MongoDB做后端持久化不，用其Replication Set + Shard