一种高性能海量文件存储系统，其特征在于：包含master组件和store节点，所述store节点存储在所述master组件中；master组件负责管理集群的元数据，包括集群中存在的store节点以及每个store节点的状态信息，store节点负责存储具体的数据；store节点周期性的向master组件汇报自身的状态信息，而master组件则实时的向其他store节点通知某个store节点的状态变更信息，确保所有的master组件和store节点都有统一的集群元数据信息。决了海量小文件访问效率低下的问题，同时提供了一种良好的用户交互方式，对于海量小文件和大文件共存的场景，也提出了一种高效的存储机制。
一种高性能海量文件存储系统工作方法
技术领域
[0001] 本发明涉及存储领域，具体涉及一种高性能海量文件存储系统工作方法。
背景技术
[0002] 1.现有的大部分存储系统都是将用户文件直接存储在后端文件系统中，这样对于海量小文件会产生大量的inode等元数据，后续的读操作访问元数据需要额外消耗大量的磁盘io，导致性能低下；典型的如ceph、hdfs等；
[0003] 2.针对1中的问题，也有一些知名的存储系统提出了一些解决方案，比如Haystack，采用了小文件合并的方式来解决海量小文件带来的海量元数据问题。但是这类系统也存在一些问题。第一，小文件合并存储后，如何确定其位置信息，用户后续访问时应该从哪里读取？为了解决这个问题，这类系统都会在小文件存储后返回一个特定的文件名，文件名中包含了位置信息，但是这样又需要使用者额外的记住这些信息，造成使用不便；第二，这类系统假设所有的文件都是小文件，全部采用合并存储的方式，但是实际使用过程中，也有可能存在少量大文件的情形。由于合并存储导致删除和更新不方便，容易导致存储空间浪费。如果将大文件也采用合并存储的方式，显然加剧了这个问题；
发明内容
[0004] 本发明针对现有技术的不足，提出一种高性能海量文件存储系统及其工作方法，其中，一种高性能海量文件存储系统，具体技术方案如下：
[0005] 一种高性能海量文件存储系统，其特征在于：包含master组件和store节点，所述store节点存储在所述master组件中；
[0006] master组件负责管理集群的元数据，包括集群中存在的store节点以及每个store节点的状态信息，store节点负责存储具体的数据；
[0007] store节点周期性的向master组件汇报自身的状态信息，而master组件则实时的向其他store节点通知某个store节点的状态变更信息，确保所有的master组件和store节点都有统一的集群元数据信息；
[0008] 每个store存储节点按照存储空间划分策略划分为多个bucket，具体为，由用户为集群设定一个bucket大小参数，一个store节点上的bucket数量＝节点总容量/bucket大小。比如用户设定的bucket大小为100G，如果节点空间为10T，则该节点的bucket数量＝10T/100G＝100
[0009] 其他划分策略包括：用户可以直接设置某个store节点的bucket数量。如果用户设置了当前store节点的bucket数量，则当前store节点最终的bucket数量即为该参数设定的值；如果用户未对当前store节点设置bucket数量，则该store节点最终的bucket数量根据前述的按照存储空间划分的策略计算而来；
[0010] 每个bucket可以直接对应为当前节点的一个目录，但也可以包含其他映射方式，数据实际存储到对应的bucket中；所述划分策略包含但不仅限于存储空间；假设按存储空间来划分，每1T存储空间对应一个bucket，那么一个具有10T存储空间的store节点将会被划分为10个bucket。
[0011] 设定文件存储机制、划分文件内存索引，该文件存储机制为，设置判定文件大小的阈值，设定参考值size1，大于等于size1的文件为大文件，小于size1的文件为小文件；
[0012] 大文件和小文件均存储在其bucket中，
[0013] 对于小文件，在每个bucket下设置有一个聚合文件，所有小文件都合并存储到聚合文件里面；
[0014] 对于大文件，单独存放在bucket下独立的文件中。
[0015] 其中，一种用于高性能海量文件存储系统的工作方法具体为：
[0016] 一种用于高性能海量文件存储系统的工作方法，其特征在于：
[0017] 包括内存索引流程，该内存索引为，
[0018] S1:针对每个bucket下的小文件，在内存中为其建立一个索引，索引内容为文件名到文件系统元数据的映射；
[0019] S2:每次store重启时，根据聚合文件中的信息重建内存索引。
[0020] 3、根据权利要求2所述一种高性能海量文件存储系统工作方法，其特征在于：包括文件上传流程，该文件上传流程为，
[0021] S1：用户请求上传文件时，找到文件的存储位置，假设为bucket1，并将请求发送给对应的store节点；
[0022] S2：将上传文件的大小与参考值size1进行比较，如果上传文件大于参考值size1，上传文件为大文件，进入步骤S3，否则，上传文件为小文件，进入步骤S4；
[0023] S3：直接在bucket1下存储为同名文件；
[0024] S4：采用合并存储的方式，对接收到的小文件内容按照自定义的格式进行封装；
[0025] 封装信息包括其原始内容、长度、状态、文件名，这里将封装后的内容叫做needle，然后将needle整体追加到相应的聚合文件中，同时在内存中按照内存索引流程为其新增索引。
[0026] 进一步地：包括删除文件流程，该删除文件流程为，
[0027] S1:找到需要删除文件的位置并将删除请求发给相应store节点；
[0028] S2:store节点首先在其所在的bucket的内存索引中寻找对应的文件，判断是否有需要删除文件的内存索引，如果有，则判断为小文件，进入步骤S3，否则，判断为大文件，进入步骤S4；
[0029] S3:，对小文件进行删除，操作为将内存索引映射和聚合文件中相应的状态标志设置为已删除，该删除为软删除机制，此刻不会删除needle的磁盘数据；
[0030] S4：直接删除对应的大文件。
[0031] 进一步地：包括读文件工作流程，读文件的工作流程为：
[0032] S1：store节点接收到读请求，利用内存中索引快速的查找相关的元数据，判断文件是否找到，如果在内存索引中找到，且文件没有被删除，则进入步骤S2，否则，进入步骤S3；
[0033] S2：store节点则在聚合文件中查询到相应的偏移量，从磁盘上读取数据；
[0034] S3：考虑读取的文件为大文件，尝试读取对应的大文件，判断是否找到大文件，如果是，则进入步骤S4，否则，进入步骤S5；
[0035] S4：并将内容返回给用户；
[0036] S5：如果本地大文件也没有找到，则说明用户请求了一个不存在的文件，返回错误信息。
[0037] 进一步地：包括更新文件流程，更新文件的流程为，
[0038] S1：定位文件位置并将删除请求发给相应store节点，store机器接收到更新请求；
[0039] S2：利用内存中索引快速的查找相关的元数据，判断在内存索引中是否找到文件，如果找到文件，则进入步骤S3，否则，进入步骤S4；
[0040] S3：判断需要更新的文件为小文件，通过添加一个新needle，将其追加到相同的聚合文件末尾，追加完成后，将以前小文件对应的needle设置为删除状态，同时将内存索引中的文件元数据更新；
[0041] S4：如果内存索引中未找到对应的文件，则考虑为大文件，此时可以直接对本地大文件进行更新。
[0042] 进一步地：包括压缩流程，该压缩流程为：
[0043] S1：逐个复制needle到一个新的聚合文件，并跳过任何重复项、已删除项。
[0044] S2：在压缩时如果接收到删除操作，两个聚合文件都需处理，一旦复制过程执行到原聚合文件末尾，所有对此聚合文件的修改操作将被阻塞，新聚合文件和新内存索引将对前任执行原子替换，随后恢复正常工作。
[0045] 本发明的有益效果为：本发明提出了一种高性能的海量小文件存储方案，解决了海量小文件访问效率低下的问题，同时提供了一种良好的用户交互方式，对于海量小文件和大文件共存的场景，也提出了一种高效的存储机制。
附图说明
[0046] 图1为本发明的结构图；
[0047] 图2为聚合文件结构示意图。
具体实施方式
[0048] 下面结合附图对本发明的较佳实施例进行详细阐述，以使本发明的优点和特征能更易于被本领域技术人员理解，从而对本发明的保护范围做出更为清楚明确的界定。
[0049] 如图1所示：一种高性能海量文件存储系统的具体实施方式如下：
[0050] 一种高性能海量文件存储系统，包含master组件和store节点，所述store节点存储在所述master组件中；
[0051] master组件负责管理集群的元数据，包括集群中存在的store节点以及每个store节点的状态信息，store节点负责存储具体的数据；
[0052] store节点周期性的向master组件汇报自身的状态信息，而master组件则实时的向其他store节点通知某个store节点的状态变更信息，确保所有的master组件和store节点都有统一的集群元数据信息；
[0053] 每个store存储节点按照特定的策略划分为多个bucket，每个bucket可以直接对应为当前节点的一个目录，但也可以包含其他映射方式，所述划分策略包含但不仅限于存储空间；
[0054] 按照存储空间划分的策略：由用户为集群设定一个bucket大小参数，一个store节点上的bucket数量＝节点总容量/bucket大小。比如用户设定的bucket大小为100G，如果节点空间为10T，则该节点的bucket数量＝10T/100G＝100
[0055] 其他划分策略包括：用户可以直接设置某个store节点的bucket数量，如果用户设置了当前store节点的bucket数量，则当前store节点最终的bucket数量即为该参数设定的值；如果用户未对当前store节点设置bucket数量，则该store节点最终的bucket数量根据前述的按照存储空间划分的策略计算而来假设按存储空间来划分，每1T存储空间对应一个bucket，那么一个具有10T存储空间的store节点将会被划分为10个bucket。
[0056] 设定文件存储机制、划分文件内存索引，该文件存储机制为，设置判定文件大小的阈值，设定参考值size1，大于等于size1的文件为大文件，小于size1的文件为小文件；
[0057] 大文件和小文件均存储在其bucket中，
[0058] 对于小文件，在每个bucket下设置有一个聚合文件，所有小文件都合并存储到聚合文件里面；
[0059] 对于大文件，单独存放在bucket下独立的文件中。
[0060] 一种用于高性能海量文件存储系统的工作方法具体实施例为：
[0061] 一种用于高性能海量文件存储系统的工作方法，包括数据分布算法、内存索引流程、文件上传流程、删除文件流程、读文件工作流程、更新文件流程和压缩流程。
[0062] 其中，本发明采用的数据算法为使用一致性哈希算法来定位文件位置，首先将每个bucket根据特定的hash算法hash为一个特定长度的值，比如bucket_key＝hash(bucketname,hostname…)，这些hash参数可以包含自定义的bucket名字、主机名或主机ip等；
[0063] 然后将这些bucket_key分布在整个哈希环上；当用户请求一个文件时，对文件名，也可以增加用户名等其他组合参数，后面统称为文件名，做一次类似的hash并得到一个key值file_key，在得到file_key后，找到比file_key大且与file_key最接近的一个bucket_key，该bucket_key指向的bucket即为文件存储位置。
[0064] 其中，该内存索引流程为，
[0065] S1:针对每个bucket下的小文件，在内存中为其建立一个索引，索引内容为文件名到文件系统元数据的映射；
[0066] S2:每次store重启时，根据聚合文件中的信息重建内存索引。
[0067] 包括文件上传流程，该文件上传流程为，
[0068] S1：用户请求上传文件时，找到文件的存储位置，假设为bucket1，并将请求发送给对应的store节点；
[0069] S2：将上传文件的大小与参考值size1进行比较，如果上传文件大于参考值size1，上传文件为大文件，进入步骤S3，否则，上传文件为小文件，进入步骤S4；
[0070] S3：直接在bucket1下存储为同名文件；
[0071] S4：采用合并存储的方式，对接收到的小文件内容按照自定义的格式进行封装；
[0072] 封装信息包括其原始内容、长度、状态、文件名，这里将封装后的内容叫做needle，然后将needle整体追加到相应的聚合文件中，同时在内存中按照内存索引流程为其新增索引。
[0073] 删除文件流程为，
[0074] S1:找到需要删除文件的位置并将删除请求发给相应store节点；
[0075] S2:store节点首先在其所在的bucket的内存索引中寻找对应的文件，判断是否有需要删除文件的内存索引，如果有，则判断为小文件，进入步骤S3，否则，判断为大文件，进入步骤S4；
[0076] S3:，对小文件进行删除，操作为将内存索引映射和聚合文件中相应的状态标志设置为已删除，该删除为软删除机制，此刻不会删除needle的磁盘数据；
[0077] S4：直接删除对应的大文件。
[0078] 读文件的工作流程为：
[0079] S1：store节点接收到读请求，利用内存中索引快速的查找相关的元数据，判断文件是否找到，如果在内存索引中找到，且文件没有被删除，则进入步骤S2，否则，进入步骤S3；
[0080] S2：store节点则在聚合文件中查询到相应的偏移量，从磁盘上读取数据；
[0081] S3：考虑读取的文件为大文件，尝试读取对应的大文件，判断是否找到大文件，如果是，则进入步骤S4，否则，进入步骤S5；
[0082] S4：并将内容返回给用户；
[0083] S5：如果本地大文件也没有找到，则说明用户请求了一个不存在的文件，返回错误信息。
[0084] 更新文件的流程为，
[0085] S1：定位文件位置并将删除请求发给相应store节点，store机器接收到更新请求；
[0086] S2：利用内存中索引快速的查找相关的元数据，判断在内存索引中是否找到文件，如果找到文件，则进入步骤S3，否则，进入步骤S4；
[0087] S3：判断需要更新的文件为小文件，通过添加一个新needle，将其追加到相同的聚合文件末尾，追加完成后，将以前小文件对应的needle设置为删除状态，同时将内存索引中的文件元数据更新；
[0088] S4：如果内存索引中未找到对应的文件，则考虑为大文件，此时可以直接对本地大文件进行更新。
[0089] 压缩流程为：
[0090] S1：逐个复制needle到一个新的聚合文件，并跳过任何重复项、已删除项。
[0091] S2：在压缩时如果接收到删除操作，两个聚合文件都需处理，一旦复制过程执行到原聚合文件末尾，所有对此聚合文件的修改操作将被阻塞，新聚合文件和新内存索引将对前任执行原子替换，该原子替换的流程为：阻塞对当前聚合文件的所有修改操作，删除旧的聚合文件，将新的聚合文件重新命名为旧的聚合文件名；恢复对当前聚合文件的所有修改操作；随后恢复正常工作。
