2021SC@SDUSC
seafile支持集群，实现了一个集群管理系统。这个系统的核心内容独立为另一个项目：ccnet-server，用以协调网络应用的运行。这篇文章主要介绍集群管理。集群中当然还有其他功能，例如对等体识别、连接管理、服务调用、消息传递等，而这些内容属于协议，在seafile : librpc 分析中可以找到。
集群中分为三个层次结构：用户、群组、组织。集群管理就是对这三个层次的结构进行维护。
三个层级依次递进，所管理的用户数量的数量级逐级递增。
这三个层次的相关信息可以很方便地用关系模型描述，并且需要统一在同一个数据库下进行维护，所以这个系统的数据持久化主要基于关系型数据库。
用户集群中的一个个体，即一个用户。用户之间存在沟通和联系，但这不是集群管理的关键。集群管理主要做的是对用户信息进行维护，至于怎样将信息在集群内部进行协调，集群管理一概不关心。
用户管理的ER图如下：
用户的信息包括基本的id、邮箱、密码等。另外有两个标签：is_staff代表是否是管理员，is_active代表目前是否活跃。
集群中有一个特殊的关系，叫做对等体。对等体之间通过协议来通信或协调其他工作，例如seafile中以自身实现的rpc协议来进行rpc操作。
那么如何判断几个用户之间是否是对等体？为用户间添加了一个关系，称作绑定。绑定关系明确了一个用户有哪些对等体，以方便用户向对等体进行通信。
角色用户可能扮演多个角色，因此创建了另外一个实体UserRole来表示用户当前的角色。这些角色并不是预定义的，可由开发者通过集群的功能自定。
用户管理操作由于用户管理重点是对用户信息进行管理，所以内容就是增删查改。详细信息见user-mgr.h。
群组将多个用户进行集中式管理，每个用户属于一个群组。ER图如下：
群组的结构是一棵树（对应了集合的包含关系），根被称为顶级群组，每个群组都有一个指向父群组的指针。更方便的，通过一个字符串路径能够唯一确定一个群组，这个信息以实体GroupStructure表示。
群组管理操作群组管理中除了对群组自身进行操作，还要设计到群组中用户的操作，内容依旧是增删查改。详见group-mgr.h。
组织将多个群组进行集中式管理，每个群组属于一个组织。ER图如下：
组织就是一个集群。与组织相关的关系和实体中描述了组织中包含的用户、群组的信息。
内容与群组类似，但并不关系群组和用户间的具体关系，重点关注组织和用户、组织和群组间的关系。具体内容详见org-mgr.h
集群架构通过源码，我们能总结出上述内容所实现的集群架构。一个最基本的线索就是包含关系：群组是用户的集合、组织是群组的集合。这个关系也是我们从ER关系中作出的直观推断。实际上这里实现的集群的结构也正是如此：分层架构。
现在我们已经知道了分层这样一个关系，现在思考为什么要进行分层。
首先，集群内还存在一个关系，那就是管理。管理显然是不可或缺的，因为有时候在可进行可靠交互时，必须引入第三方。但集群的管理同样也是个问题，它与管理的规模挂钩。而集群管理的分层架构，恰好体现了分而治之的思想。试想一下，如果全部交由一个中心用户来管理所有其他用户，那么中心用户的负载将会过大。于是分层架构中就诞生了群组的概念，将各个群组分摊给一些管理员，群组管理员管理群组内的用户。那么谁来管理管理员，于是需要一个级别更高管理员，来管理集群内其他所有管理员和所有用户。如果这些管理员负载也太大了，那么就进一步分为更小的群组，这也就是群组间呈现的树状关系。
为了方便管理，并且考虑到集群的动态性，我们需要将集群实体化，并在持久化部件中进行维护。这个时候又有问题了，谁来实体化？于是引入创建者的概念。一个群组由某个用户进行创建，并将其持久化，这个用户被称为创建者。
现在我们重新考虑集群内部的各种关系，包括管理与创建关系，从用户开始向上递推，于是我们得到了更加清晰的描述：
上图也就是对集群管理的总结。
至于seafile集群去中心化的特性、对等体、集群内个体间的详细关系与相互作用等，那就是协议中的内容了，这里不做阐述。如果说想了解seafile中集群的通讯协议，详见librpc。
