关于集群式流媒体文件系统的cache管理

作为一个集群式的文件系统，cache管理的必要性不言而谕，在此就不做诠释了。主要概述一下设计思想。

其cache管理由两部分构成：cache manager(CM)和cache agent(CA)。CM位于service master上，CA位于每个流业务单元板(SSU)上。CM负责跟踪所有CA报上来的cache使用情况，主要是承担策略管理的角色，包括cache热度跟踪，load balance调度，同时对cache的租用和释放，都将进行管理。CA的任务是负责本地cache的分配，租用和释放，是CM所下达策略的执行者。

一些设计原则是：

1. CA对cache的操作语义是透明的。即cache可以是将本地SSU的内存作为cache，也可以是将本地disk作为cache，其对CA的操作interface是透明的。这种方式即可保障系统对物理构架的最大兼容性。

2. 对cold read和warm read业务进行可配置策略管理。即对cache块的状态，是以一个生命周期的模式来进行管理。cold read/warm read/复制/租赁过期/释放，对不同业务所需要的cache使用策略，可以灵活配置。避免统一管理模式，造成资源浪费。比如：有些业务对cache要求的租用时间很短，我们即可以在短时间里释放它。有些业务模块要求的cache数量需要最低保证，所以应该设置最低保证，等等。

3. cache的使用流程：业务申请==>CA评估==>租用==>cold read==>如果失败，转向CM协调，CM分配新的CA，本地CA向重定向的CA申请==>申请成功，向CM注册==>warm read==>租赁过期，CA释放==>通知CM注销==>如CA认为此cache块热度可以续租赁，继续保持租赁。

4. CA之间的cache租赁是readonly。其所租赁的cache由primary方提供，使用cache租赁的称为secondary方。所以，对任何secondary方的释放操作，都不存在数据修改的同步问题。

5. CA负责cache租赁的重定向。此操作对业务层是透明的，如果其中的一个CA失败，租赁申请方将负责尝试第二个CA，直到所有可能的尝试都失败，CA将最终返回业务层错误信息。

(此文仅限业内交流，请勿转载)