本篇是对前面几篇ceph rgw元数据分析类文章的总结，同时整体介绍下rgw元数据分布式改造的架构以及实现逻辑

架构

看过前面"ceph rgw元数据分析"类文章的读者，应该还记得那个rgw 分层架构图，为实现元数据的分布式改造，只需要在store层新增一个存储后端 - 专门用来存储集群元数据（realm，zonegroup，zone等）和用户元数据（user，bucket，bucket index等），实质是将RGWRados中的元数据管理以及数据操作分离：

为最大限度的复用已有的接口，对上层屏蔽修改；在实际操作中，我们在RGWRados内部集成一个新的MStore，它与librados::Rados并列处于同一层次，RGWRados内是以组合（UML中的类关系）方式来使用底层的store（librados::Rados和MStore），所以引入新的store后，只需要修改RGWRados的接口实现，而保持接口定义不变，对调用方隐藏具体的实现细节。

在实践中MStore有多种候选组件，如：Mysql，Mongodb，Tikv等，而元数据服务需要满足高性能，高可用特性等特性，Mysql的高可用方案不够好，Mongodb不完全满足ACID特性，Tikv是一个支持分布式事务的kv数据库，基于raft+rocksdb实现，当前最大可以支持200TB的容量，所以Tikv是个比较合适的选择，更多Tikv的信息请移步：https://github.com/tikv/tikv。

下图是以TiKV作为分布式元数据仓库的一种部署图：由三台RGW网关节点（Gateway1是etcd的master，部署rgw以及tikv）和三台存储节点（部署osd和mon）组成，rgw分别通过::MStore与Tiikv交互完成元数据的处理，通过librados::Rados与OSD交互完成数据的处理，其中:MStore是新增待开发的部分：

逻辑

根据前面文章分析的内容，我们知道rgw中通过:RGWRESTMgr_*,RGWHandler_*, RGWOp_*, RGWServiceInstance实现对资源类别，操作以及服务例程的抽象，资源类别包括：admin(usage, user, bucket, log, metadata,…),s3(bucket, object, service,…)等，操作包括：CRUD等，服务包括：notify，quota，sync，zone，cache等，其中服务例程是为资源操作服务的，它们最终都是通过与librados::*交互完成相应的动作，我们对ceph rgw中关键流程分析及业务逻辑以及ceph rgw启动过程中元数据的创建及初始化中的信息做个汇总，可以得到如下的活动图（简图）：

注：蓝色图框是主要修改的地方

其中，RGWSI_SysObj主要是将上层的pool，oid等原始资源封装成RGWServiceInstance实例可理解的资源对象，并提供对象操作（ROp, WOp, WNOp以及OmapOp）和存储池操作(List)接口，起到适配器的作用，实际调用RGWSI_SysObj_Core的接口完成相应的操作；RGWSI_RADOS将RGW中的资源表示转化为Rados资源，并直接与librados::*交互完成操作。

接口和数据结构方面，通读rgw的代码以及结合前面的系列文章也能快速提出来，小文件合并的设计可以借鉴下Haystack的思路，：） 再写就违反保密协议了，就此结束了，见谅，欢迎私聊，相互探讨。