CN102081619A - 数据更新方法、分发节点及海量存储集群系统 - Google Patents

Abstract

本发明公开了一种数据更新方法、分发节点及海量存储集群系统。其中分发节点包括：命令控制模块，用于通过一个更新线程接接收管理装置发送的更新命令；下发模块，用于通过多个读取线程从所述命令控制模块读取所述更新命令，并根据所述更新命令将数据分别下发到相应的数据节点。本发明的数据更新方法、分发节点及海量存储集群系统，仅通过一个更新线程接收更新命令，避免了现有技术中多线程同时更新的锁问题，提高了系统整体处理效率；同时设置多个读取线程读取更新命令，同时对多个更新命令进行数据下发，提高了数据下发的效率。

Description

数据更新方法、分发节点及海量存储集群系统

技术领域

本发明涉及一种数据存储技术，尤其涉及一种数据更新方法、分发节点及海量存储集群系统。

背景技术

在现有的各种实时系统中对海量数据实现实时查询和同步更新是比较困难的，目前常见的策略通过提升单机硬件性能来提高数据承载量，或者通过把数据按照使用方式不同来划分存储单元。

现有技术中存在以下缺陷：

1、由于多线程的同时更新，系统需要选择一条更新线程而锁住其他更新线程，在处理更新时存在随机I/O操作，导致整体效率提升困难，大部分效率损失在I/O锁竞争和更新线程调度。

2、查询和更新使用相同的线程，导致权限模糊，数据流向不确定，如果查询或更新出现问题，会影响到整个系统。

3、为了保障数据的安全性很多系统采用多副本方式，就是说一个副本在2台或者3个数据节点中保存，进而提高数据安全性，这种方式看似安全其实存在数据安全隐患，当系统代码出现bug时可能使多个数据副本写坏或者丢失；还有当数据同步时如果采用A通知B，B通知C这种逐个通知的更新方式，会使更新不及时，每个节点都是更新同步的关键节点，各个节点间数据容易不一致。

4、随着数据规模的增长过分依赖某个数据中心节点，导致中心节点压力过大，性能降低，系统横向扩展困难。

5、很多业务系统都要求每周7*24小时不间断服务，在小数据量时可以通过几台冗余服务器来保障，但是在海量数据的情况下就要考虑整个系统中每个分发节点离线所带来的影响，而且当机器规模达到一定程度后，比如一千台机器，那么每周、甚至每天可能都会有机器损坏，对系统的正常运行影响较大。

发明内容

本发明的目的在于，提供一种数据更新方法、分发节点及海量存储集群系统，在保持数据下发效率的同时，避免了多线程同时更新的锁问题，提高了系统整体处理效率。

为实现上述目的，根据本发明的一个方面，提供一种数据更新方法，包括：

通过一个更新线程接收所述更新命令；

通过多个读取线程读取所述更新命令，并根据所述更新命令将数据分别下发到相应的数据节点。

为实现上述目的，根据本发明的另一个方面，提供一种分发节点，包括：

命令控制模块，用于通过一个更新线程接接收管理装置发送的更新命令；

下发模块，用于通过多个读取线程从所述命令控制模块读取所述更新命令，并根据所述更新命令将数据分别下发到相应的数据节点。

为实现上述目的，根据本发明的另一个方面，提供一种海量存储集群系统，包括：管理装置、采用树状结构组织的分发节点和数据节点，

所述分发节点，用于通过一个更新线程接收所述更新命令；并通过多个读取线程读取所述更新命令，并根据所述更新命令将数据分别下发到相应的数据节点。

本发明的数据更新方法、分发节点及海量存储集群系统，仅通过一个更新线程接收更新命令，避免了现有技术中多线程同时更新的锁问题，提高了系统整体处理效率；同时设置多个读取线程读取更新命令，同时对多个更新命令进行数据下发，提高了数据下发的效率。

优选地，分发节点还包括：查询模块，用于根据所述管理装置发送的查询命令通过一个或多个查询线程对其他分发节点和/或数据节点进行查询。查询和更新使用不同的线程，使得数据流向清晰，查询、更新权限明晰，查询端或者更新端出现问题不会影响到整个系统。

更优地，分发节点中的下发模块还判断是否接收到所述数据节点发送的更新数据成功信息，如果没有接收到，则发送数据不成功，下发模块重复发送数据到数据节点。这样可以保证各个节点数据的一致性，不会因为下端数据模块出现处理故障而数据丢失。

另外，在海量存储集群系统中，分发节点可以包括多个层级，不同层级的分发节点之间交叉相连，逐级下发或查询数据；管理装置中存储还存储各个层级分发节点之间的层次关系及数据下发命令表，根据层次关系及数据下发命令表控制不同层级的分发节点逐级分发数据或查询数据。最上层的分发节点可以接收数据的更新或者查询，根据规则可以迅速的逐级找到下级节点中的数据，实现数据的实时查询和同步更新。

进一步的，每个分发节点还有对应的冗余节点，冗余节点，存储与分发节点相同的数据，执行与分发节点相同的操作。各层级分发节点(包括冗余节点)之间交叉相连，任何节点损坏都不会影响系统正常运转。可以根据需要随意增加分发节点的层级或某个分发节点的冗余节点，便于系统的横向及纵向扩展。另外数据节点也可以根据实际需要随意增加。降低了各个节点的负载压力，提高了各个节点的工作性能。

附图说明

图1是本发明分发节点的实施例结构图；

图2是更新缓存模块中更新命令的存储结构实施例示意图；

图3是更新缓存模块中更新命令的存储结构另一实施例示意图；

图4是本发明海量存储集群系统实施例结构图；

图5是本发明海量存储集群系统分发节点的一种树状结构示意图；

图6是本发明海量存储集群系统分发节点的另一种树状结构示意图；

图7是本发明数据分发方法实施例结构图；

图8是本发明数据分发方法另一实施例结构图。

具体实施方式

以下结合附图对本发明进行详细说明。

装置实施例

图1是本发明分发节点的实施例结构图。如图1所示，本实施例包括：

命令控制模块102，用于通过一个更新线程接接收管理装置发送的更新命令；下发模块104，用于通过多个读取线程从命令控制模块102读取更新命令，并根据更新命令将数据分别下发到相应的数据节点。

本实施例中，仅通过一个更新线程接收更新命令，避免了现有技术中多线程同时更新的锁问题；同时为了保证数据下发的效率，设置多个读取线程读取更新命令，同时对多个更新命令进行数据下发。

优选地，本实施例分发节点还包括：更新缓存模块103，用于按照更新命令的顺序对所述更新命令进行存储；下发模块104，从更新缓存模块103中读取更新命令。

通过对更新命令的缓存，不影响数据下发的效率，而且更新线程写入磁盘后才会给发送端反馈，提高了数据的安全可靠性，不会因为死机、断电带来数据丢失。另外，通过对更新命令的存储，可以记录各个下端数据模块数据的发送量和发送速度，并可以在下端数据模块数据规模达到一定程度，需要分裂到几台机器上时，可以根据存储的更新命令重放更新数据。当某个数据节点出现问题时(故障离线或者处理缓慢)通过更新缓存模块也可以恢复其数据，进而保证系统中多副本的同步。

图2是更新缓存模块中更新命令的存储结构示意图。如图2所示，显示了更新命令存储的形式，图中每一排都表示磁盘上的一个文件，是按照命令顺序在磁盘上保存的。每个更新命令保存后才会给上层回应信息，负责更新队列的更新线程只有一个这样可以避免多个更新线程带来的全局锁问题。

读取线程存在多个，每个读取线程负责一个叶子节点上数据模块的数据更新，并且每个读取线程记录自己发送消息的位置。

图3是更新缓存模块中更新命令的存储结构另一实施例示意图。如图3所示，由于数据模块形式多样所以更新的命令结构及形式也多样，为此更新命令存储时增加了命令类型。由于每个读取线程都负责自己的下端数据模块，所以可以为读取线程增加命令识别表来识别这个更新命令是否是该读取线程需要的，只有当命令识别表中的命令类型和更新队列的命令头中的命令类型一致时才发送给其负责的下端数据模块，否则抛弃。这样，每个读取线程只要负责自己读取的更新命令而不需要关心外部传送来的所有更新命令。

更优地，下发模块104还判断是否接收到所述数据节点发送的更新数据成功信息，如果没有接收到，则发送数据不成功，下发模块104重复发送数据到数据节点。这样可以保证各个节点数据的一致性，不会因为下端数据模块出现处理故障而数据丢失。

下发模块104，还进一步记录下发数据的数据节点的位置信息，以保证数据发送的准确性。

本实施例中，分发节点还包括：查询模块106，用于根据管理装置发送的查询命令通过一个或多个查询线程对其他分发节点和/或数据节点进行查询。当同时对多个节点进行查询时，查询模块106将从多个节点获取的查询结果进行合并。

本实施例中，查询和更新使用不同的线程，通过将查询和更新分开，使得数据流向清晰，查询、更新权限明晰，查询端或者更新端出现问题不会影响到整个系统。另外，便于存储更新命令，更新命令中可以包括数据的新增、删除、更新操作，存储更新命令可以使随机的磁盘更新变成顺序的磁盘操作，提升系统I/O性能。

系统实施例

图4是本发明海量存储集群系统实施例结构图。如图4所示，本实施例包括：管理装置42、采用树状结构组织的分发节点441～44n和数据节点461～46n，分发节点作为树状结构组织的枝干节点，用于分发数据；数据节点作为树状结构组织的叶子节点，用于存储数据；管理装置，用于发送更新命令到所述分发节点；其中，分发节点441～44n，通过一个更新线程接收所述更新命令，并通过多个读取线程读取更新命令，并根据更新命令将数据分别下发到相应的数据节点。

如图5所示，当机器规模达到一定程度后，分发节点可以包括多个层级，图5中的A～F表示三个不同层级的分发节点，不同层级的分发节点之间交叉相连，逐级下发或查询数据；管理装置22中存储还存储各个层级分发节点之间的层次关系及数据下发命令表，根据层次关系及数据下发命令表控制不同层级的分发节点逐级分发数据或查询数据。

分发节点按照预设的数据下发命令表分发数据，可以为每个更新数据签名，作为这一份数据的特征ID。这种签名方法可以采用MD5签名获得64位或者128位签名，签名后可以使特征ID均匀分布。例如：共有40亿的数据，我们根据特征ID前32位(2的32次方可以表示40亿个数据)来划分新增数据的位置，每个分发节点记录一个区间和对应数据模块表，这样就可以通过特征ID来确定数据落到哪个数据模块上了。如图5所示，分发节点D分发特征ID前32位表示1-10亿的数据，分发节点E、分发节点F分别分发特征ID前32位表示10-30亿及30-40亿的数据。

本实施例的多层分发节点的树状结构，可以向下扩展分发节点的层数，上层分发节点管理下层的分发节点，并逐级下发数据。层次之间交叉连接，这样做可以避免某个数据模块出现单点问题。各个分发节点的层次关系、节点号由管理装置22统一指定和分发。多个分发节点可以部署在相同机器上，每个分发节点在这个系统中仅通过IP地址是不能分辨的，还要通过端口号对每个模块进行区分。

图5中的树状结构虽然能够满足速度、容量等多种需要，但是枝干的各个层次上存在很多单点，这样会存在系统更新、查询瓶颈。优选地，如图6所示，树状结构中的每个分发节点都有其对应的冗余节点，冗余节点存储与分发节点相同的数据，执行与分发节点相同的操作。

最上端的分发节点A可以接收数据的更新或者查询，根据规则可以迅速的逐级找到下级节点中的数据，实现数据的实时查询和同步更新。各个节点之间交叉相连，任何节点损坏都不会影响系统正常运转。如果某个分发节点出现瓶颈，可以根据需要随意增加，便于系统的横向扩展。另外数据节点也可以根据实际需要随意增加。

方法实施例

图7是本发明数据分发方法实施例结构图。如图7所示，本实施例包括：

步骤702，通过一个更新线程接收更新命令；

步骤704，通过多个读取线程读取更新命令，并根据更新命令将数据分别下发到相应的数据节点。

本实施例中，仅通过一个更新线程接收更新命令，避免了现有技术中多线程同时更新的锁问题；同时为了保证数据下发的效率，设置多个读取线程读取更新命令，同时对多个更新命令进行数据下发。

图8是本发明数据分发方法另一实施例结构图。如图8所示，本实施例包括：

步骤802，通过一个更新线程接收更新命令；

步骤804，存储更新命令及其命令类型；

步骤806，根据预设的命令识别表判断读取进程读取的更新命令是否与命令识别表中的命令类型相同，如果相同，执行步骤810，如果不同，执行步骤808；

步骤808，抛弃该更新命令；

步骤810，根据该更新命令将数据分别下发到相应的数据节点。

本实施例中，通过步骤804中对更新命令的缓存，不影响数据下发的效率，而且更新线程写入磁盘后才会给发送端反馈，提高了数据的安全可靠性，不会因为死机、断电带来数据丢失。另外，通过对更新命令的存储，可以记录各个下端数据模块数据的发送量和发送速度，并可以在下端数据模块数据规模达到一定程度，需要分裂到几台机器上时，可以根据存储的更新命令重放更新数据。当某个数据节点出现问题时(故障离线或者处理缓慢)通过更新缓存模块也可以恢复其数据，进而保证系统中多副本的同步。

另外，由于每个读取线程都负责自己的下端数据模块，所以在步骤806中为读取线程增加命令识别表来识别这个更新命令是否是该读取线程需要的，只有当命令识别表中的命令类型和更新命令中的命令类型一致时才发送给其负责的下端数据模块，否则抛弃。这样，每个读取线程只要负责自己读取的更新命令而不需要关心外部传送来的所有更新命令。

优选地，本实施例还包括：步骤812，判断是否接收到数据节点发送的更新数据成功信息；如果是，则执行步骤814，结束；如果否，则返回步骤810，重复发送数据到该数据节点。这样可以保证各个节点数据的一致性，不会因为下端数据模块出现处理故障而数据丢失。

本发明的上述实施例，在支持海量存储的同时，通过单线程更新，避免了锁问题；将查询和更新线程分开，使得数据流向清晰，查询、更新权限明晰，查询端或者更新端出现问题不会影响到整个系统；通过多层树形结构，便于数据的实时查询和同步更新，以及系统的横向、纵向扩展；另外通过设置分发节点的冗余节点，提高了系统的稳定性；通过分发节点设置更新命令的缓存，提高了数据的安全可靠性。

应说明的是：以上实施例仅用以说明本发明而非限制，本发明也并不仅限于上述举例，一切不脱离本发明的精神和范围的技术方案及其改进，其均应涵盖在本发明的权利要求范围中。

Claims (15)

1.一种分发节点，其特征在于，包括：

命令控制模块，用于通过一个更新线程接收管理装置发送的更新命令；

下发模块，用于通过多个读取线程从所述命令控制模块读取所述更新命令，并根据所述更新命令将数据分别下发到相应的数据节点。

2.根据权利要求1所述的分发节点，其特征在于，还包括：

更新缓存模块，用于按照所述更新命令的顺序对所述更新命令进行存储。

3.根据权利要求1所述的分发节点，其特征在于，

所述下发模块，还在没有接收到所述数据节点发送的更新数据成功信息时，重复发送数据到所述数据节点。

4.根据权利要求1或3所述的分发节点，其特征在于，所述下发模块，还用于记录下发数据的数据节点的位置信息。

5.根据权利要求1所述的分发节点，其特征在于，还包括：查询模块，用于根据所述管理装置发送的查询命令通过一个或多个查询线程对其他分发节点和/或数据节点进行查询。

6.根据权利要求5所述的分发节点，其特征在于，所述查询模块，还用于将多个查询结果进行合并。

7.一种海量存储集群系统，其特征在于，包括：管理装置、采用树状结构组织的分发节点和数据节点，所述分发节点作为树状结构组织的枝干节点，用于分发数据；所述数据节点作为所述树状结构组织的叶子节点，用于存储数据；所述管理装置，用于发送更新命令到所述分发节点；

所述分发节点，用于通过一个更新线程接收所述更新命令；并通过多个读取线程读取所述更新命令，并根据所述更新命令将数据分别下发到相应的数据节点。

8.根据权利要求7所述的海量存储集群系统，其特征在于，所述分发节点，还按照所述更新命令的顺序对所述更新命令进行存储。

9.根据权利要求7所述的海量存储集群系统，其特征在于，所述分发节点，还用于根据所述管理装置发送的查询命令通过多个查询线程同时对多个其他分发节点和/或数据节点进行查询。

10.根据权利要求9所述的海量存储集群系统，其特征在于，所述分发节点包括多个层级，不同层级的分发节点之间交叉相连，逐级下发或查询数据；

所述管理装置，还存储各个层级分发节点之间的层次关系及数据下发命令表，根据所述层次关系及数据下发命令表控制所述不同层级的分发节点逐级下发数据或查询数据。

11.根据权利要求10所述的海量存储集群系统，其特征在于，还包括每个分发节点对应的冗余节点，所述冗余节点，用于存储与所述分发节点相同的数据，执行与所述分发节点相同的操作。

12.一种数据更新方法，其特征在于，包括：

通过一个更新线程接收所述更新命令；

通过多个读取线程读取所述更新命令，并根据所述更新命令将数据分别下发到相应的数据节点。

13.根据权利要求12所述的数据更新方法，其特征在于，还包括：

按照所述更新命令的顺序对所述更新命令进行存储。

14.根据权利要求12所述的数据更新方法，其特征在于，还包括：

在没有接收到所述数据节点发送的更新数据成功信息时，重复发送数据到所述数据节点。

15.根据权利要求13所述的数据更新方法，其特征在于，

还进一步存储所述更新命令的命令类型；

所述通过多个读取线程读取所述更新命令的操作包括：所述各个读取线程根据预设的命令识别表及所述更新命令的命令类型读取相应的更新命令。

Images