CN115150418A

CN115150418A - 服务器集群的数据存储方法

Info

Publication number: CN115150418A
Application number: CN202211032453.3A
Authority: CN
Inventors: 李艳波; 李江涛; 王鑫哲; 贾宏伟; 郭建君
Original assignee: Beijing Weiling Times Technology Co Ltd
Current assignee: Beijing Weiling Times Technology Co Ltd
Priority date: 2022-08-26
Filing date: 2022-08-26
Publication date: 2022-10-04
Anticipated expiration: 2042-08-26
Also published as: CN115150418B

Abstract

本公开实施例涉及一种服务器集群的数据存储方法，该方法包括：S10、中间件接收服务器集群中第一服务器上报的日志更新记录信息；S20、所述中间件的数据收集后台服务根据日志更新记录信息获取第一服务器中的与日志更新记录信息对应的日志信息，所述日志信息包括：日志数据，该日志数据的标识；S30、所述中间件的消息队列服务根据所述日志数据的标识，将所述日志数据排列在标识对应的队列中；以使至少一个数据消费者从所述队列中获取日志数据以存储或分析。本发明的方法采用异步结构，去解决了数据量特别大且类型特别多时：收集数据时产生的堆积而影响都存储系统的性能的缺陷。

Description

服务器集群的数据存储方法

技术领域

本申请属于计算机技术领域，具体涉及一种服务器集群的数据存储方法。

背景技术

现有技术中，对服务器数据的收集均是直接使用数据库（MySQL等）进行数据收集。数据量大时，数据库性能压力大。数据不经过程序中转时，影响整体的数据收集链路的速度。

另外，现有技术中对服务器数据的收集可经由数据收集服务写入数据库中。

然而，上述数据收集的方案都属于同步方案，当一条数据未执行完成时，下一条数据需要等待。数据量越大大，速度越慢。由此，导致，数据收集时间长，且数据库性能压力大，影响整体稳定性。

鉴于此，亟需一种能够收集不同数据结构的数据，同时减少数据库压力，且提高收集速度的数据收集方案。

发明内容

（一）要解决的技术问题

鉴于现有技术的上述缺点、不足，本申请提供一种服务器集群的数据存储方法，该方法消除了数万台以上的服务器同时收集不同数据结构的数据时的性能压力和有效降低了I/O压力和程序本身的压力，收集速度快。

（二）技术方案

为达到上述目的，本申请采用如下技术方案：

第一方面，本发明实施例提供一种服务器集群的数据存储方法，其包括：

S10、中间件的数据收集后台服务接收服务器集群中第一服务器上报的日志更新记录信息；

S20、所述中间件的数据收集后台服务根据日志更新记录信息获取第一服务器中的与日志更新记录信息对应的日志信息，所述日志信息包括：日志数据，该日志数据的标识；举例来说，日志数据可包括：服务器集群中各服务器运行、每一服务器内各系统运行/程序运行产生的数据，本实施例不对日志数据进行限定。

S30、所述中间件的消息队列服务根据所述日志数据的标识，将所述日志数据排列在标识对应的队列中；以使至少一个数据消费者从所述队列中获取日志数据以存储或分析。

可选地，所述服务器集群包括多个不同类型的服务器，其各个服务器所在地理位置不同。

可选地，所述服务器集群包括：游戏服务器、web服务器和/或应用服务器。

可选地，所述日志更新记录信息包括：日志数据的标识、服务器标识、时间标识；

所述中间件包括多个数据收集后台服务，每一数据收集后台服务对应一种数据类型的日志信息；所述数据类型与所述日志数据的标识相同；可理解的是，数据类型可为中间件根据业务类型、数据查看的紧急程度，和字符串or数字类型，进行相应的划分后确定的；或者数据类型可为中间件借助于用户触发的指令、业务类型、数据查看的紧急程度，和字符串or数字类型等划分的。日志数据的标识可为日志数据的业务类型的标识、数据查看紧急程度的标识、字符串/数字类型的标识组成的一标识。

所述S20包括：

所述中间件基于所述日志更新记录信息中日志数据的标识，选择与该标识匹配的数据收集后台服务；

选择的数据收集后台服务根据日志更新记录信息，从服务器标识所属服务器中获取日志数据的标识对应的日志信息。

可选地，消息队列服务包括：多个队列，各队列中排列的日志数据的标识不同；举例来说，消息队列服务可根据业务类型、数据查看的紧急程度，和字符串or数字类型，进行相应的队列划分，之后关联的日志数据可进入到各自所属的队列里。

所述S30中的将所述日志数据排列在标识对应的队列中，包括：

判断该标识所属队列的长度是否大于预设长度，若是，则将待放入队列的日志数据存储在消息队列服务的等待区。

可选地，所述方法还包括：

数据消费者根据操作指令从操作指令所属的队列中获取日志数据，并将数据存储在ES中。

可选地，所述数据消费者和ES为不同设备中的程序；所述中间件位于云主机中，所述云主机与服务器集群为不同的设备。

第二方面，本发明实施例提供一种电子设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上第一方面任一项所述的服务器集群的数据存储方法的步骤。

第三方面，本发明实施例提供一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上第一方面任一项所述的服务器集群的数据存储方法的步骤。

（三）有益效果

本申请提供的技术方案可以包括以下有益效果：

本发明的方法更细致的消除了数万台以上的服务器同时收集不同数据结构的数据时的性能压力和有效降低了I/O压力和程序本身的压力。本发明的方法中采用异步方案，中间件在各个步骤间，只执行好自己的步骤即可，无需等待本条任务是否完成后才能进行下一步，即相互步骤之间无冲突。

另外，本发明的方法解决了数据量特别大且类型特别多时：收集数据时产生的堆积不会影响到系统的性能；以及解决了数据量特别大且类型特别多时：接收数据几乎不会产生堆积从而影响数据库的性能。

本发明的方法实现了数据收集的可控性，当前数据收集的步骤可单独控制，而不像现有方案中为一个整体，不能单独增加或删减，可在任务运行时进行运行服务的设备的增加和删除。同时可实现了横向拓展性，便于维护。

附图说明

本申请借助于以下附图进行描述：

图1为本发明一实施例提供的服务器集群的数据存储方法的流程示意图；

图2为本发明另一实施例提供的服务器集群的数据存储方法的架构示意图。

具体实施方式

为了更好的解释本发明，以便于理解，下面结合附图，通过具体实施方式，对本发明作详细描述。可以理解的是，以下所描述的具体的实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合；为了便于描述，附图中仅示出了与发明相关的部分。

本发明实施例的中间件可为一应用程序，其位于云主机中，用于连接服务器集群和另一用于存储数据的服务器系统。消息队列可为数据传输过程中，保存未被归档的数据的容器。

中间件可以根据数据结构/数据类型定制对接服务器集群中服务器的日志数据的数据收集后台服务。

如图1和图2所示，本实施例提供一种服务器集群的数据存储方法，本实施例的方法可以由任一计算设备来执行，该计算设备可以通过软件和/或硬件的形式实现，如图1所示，该方法包括下述的步骤：

S10、中间件的数据收集后台服务接收服务器集群中第一服务器上报的日志更新记录信息。

本实施例中服务器集群中包括多个独立的且地理位置不同的多个类型的第一服务器，为更好的说明，该步骤中使用第一服务器，其不具有特指作用。例如，服务器集群包括：游戏服务器、web服务器和/或应用服务器。

本实施例中，日志更新记录信息可包括：日志数据的标识、服务器标识。需要说明的是，日志数据的标识为复合型标识其可为日志数据的业务类型的标识、数据查看紧急程度的标识、字符串/数字类型的标识组成的一标识。当然，在其他实施例中，日志数据的标识也可为单一形式的标识，本实施例不对其限定，根据实际需要配置。

S20、中间件的数据收集后台服务根据日志更新记录信息获取第一服务器中的与日志更新记录信息对应的日志信息，所述日志信息包括：日志数据，该日志数据的标识。

在本实施例中，中间件可包括多个数据收集后台服务，每一数据收集后台服务对应一种数据类型的日志信息；所述数据类型与所述日志数据的标识相同。可理解的是，数据类型可为中间件根据业务类型、数据查看的紧急程度，和字符串or数字类型，进行相应的划分后确定的；或者数据类型可为中间件借助于用户触发的指令、业务类型、数据查看的紧急程度，和字符串or数字类型等划分的。

相应地，上述步骤S20可包括：中间件基于所述日志更新记录信息中日志数据的标识，选择与该标识匹配的数据收集后台服务；

S30、中间件的消息队列服务根据所述日志数据的标识，将所述日志数据排列在标识对应的队列中；以使至少一个数据消费者从所述队列中获取日志数据以存储或分析。

本实施例中的消息队列服务包括：多个队列，各队列中排列的日志数据的标识不同。

在实际应用中，S30中的将所述日志数据排列在标识对应的队列中，可包括：判断该标识所属队列的长度是否大于预设长度，若是，则将待放入队列的日志数据存储在消息队列服务的等待区。

其中，等待区的日志数据可不按照队列方式排放，混合排列。

在实际应用中，上述方法还可包括下述的步骤S40：

S40、数据消费者根据操作指令从操作指令所属的队列中获取日志数据，并将数据存储在ES中。

本实施例中的中间件可包括多个数据收集后台服务和一个消息队列服务。该消息队列服务中包括多个队列，该队列可为其他实施例中的消息队列。举例来说，消息队列服务可根据业务类型、数据查看的紧急程度，和字符串or数字类型，进行相应的队列划分，得到划分的多个队列。

本实施例的方法解决了数据量特别大且类型特别多时：收集数据时产生的堆积不会影响到系统的性能；以及解决了数据量特别大且类型特别多时：接受数据几乎不会产生堆积从而影响数据库的性能。

在另一实施例中，服务器集群可包括：游戏服务器（如图2中所示的Game Server（GS））、web服务器和应用服务器。针对游戏服务器可为N个，如服务N个玩家就有N台服务器。上述服务器集群中各个服务器的地理位置可不同。在实际使用中，该服务器集群的各服务器可为多个云主机设备。

本实施例中的中间件可包括位于多个云主机中的数据收集后台服务，数据收集后台服务可根据上报的日志更新记录信息向相应的服务器内抓取已经产生的日志更新记录信息对应的日志信息。通常，为更好的实现数据收集后台服务的数据收集功能，可将数据收集后台服务部署在服务器集群的服务器中如各云主机中。

中间件中的消息队列服务可将收集的日志信息中的日志数据推送给对应的队列即消息队列。本实施例的消息队列可根据用户的相关指令、业务类型、紧急程度等信息进行划分；每一消息队列的队列长度可根据需要调整。针对消息队列的等待区的存储数据不设限，且不对数据类型或紧急程度等进行区分。即，消息队列保存所有的日志数据并将按照数据类型产生不同的队列。超过队列长度的数据内容由执行区放到等待区。等待区的容量几乎无上限，等待区数量过多也不会引起整个中间件所属的系统卡顿，更不会引起服务器集群的系统卡顿。

举例来说，日志数据可为服务器中的CPU、内存、网络数据等，游戏服务器中的日志数据可包括游戏帧数、启动时长等。

服务器集群中产生数据的量和频率不固定。由于实际中的ES写入到数据库的频率和速度是固定的。故，本实施例的中间件中通过设置数据等待区，由消费者一点点去等待区拿取数据，并存储到ES里，解决现有技术中的数据量特别大且类型特别多容易引起卡顿的缺陷。

如图2所示，中间件可以根据服务器集群的数据类型定制对接服务器中日志数据的数据收集后台服务。如图2中数据收集后台服务为5个。即按照数据类型的指标进行收集，数据类型值可以日志数据的纬度。同一个业务下，存在不同类型的数据纬度（每一数据维度可为一种日志数据的格式）。例如服务器数据、游戏数据。通过约定好的格式，服务器的日志数据对接中间件的数据收集后台服务。游戏数据对接游戏数据收集后台服务。图2中仅示出的是5个数据收集后台服务，在实际应用中可不限定5个，根据实际需要进行配置。

数据消费者（N个）到消息队列中拿去相应的数据内容即日志数据，并将数据放入到ES中，ES（Elastic Search）整理分析对应的数据信息，ES为存储数据便于检索的工具如数据分析引擎。数据消费者是链接消息队列和ES的程序，用于将数据写入ES里。

在图2中， GS中的数据收集后台服务可主动抓取GS中变动的数据即上述的日志数据，数据收集后台服务将主动抓取的数据发送消息队列。消息队列可接收的数据理论上无限大。本实施例中，GS产生的数据量大小、频率和时间段不尽相同，但接收端的ES的存储效率没有那么高，故设置消息队列进行临时存储；通过数据消费者去消息队列拿取数据，并将数据存储到ES内。

通常，运行GS的为单台云主机。这样的主机目前有上万台。图2中的中间件运行在三台主机内，此时的数据收集后台服务、消息队列可均为软件服务。

由此，本实施例中的中间件可以实现横向扩展数据收集后台服务，使得较好较快的收集服务器集群中服务的日志数据，实现了横向扩展性，同时，可对中间件中消息队列的等待区进行扩展，如增加内存、硬盘等，实现纵向扩展，提高了数据读取存储的便捷性。

需要说明的是，数据消费者和ES可为不用设备中的程序，例如，GS在阿里云的云主机内运行，数据消费者在其他独立的云主机内，此时，ES可为公司独立机房，图2所示的整条链路全部是单独部署，均未集成在一个设备中。

本申请第三方面提供了一种服务器，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，计算机程序被处理器执行时实现如上实施例中任意一项所述的服务器集群的数据存储方法的步骤。

上述本发明实施例揭示的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器、专用集成电路、现成可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件单元组合执行完成。软件单元可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

另外，本发明实施例可提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上方法实施例中的任意一种服务器集群的数据存储方法。

应当注意的是，在权利要求中，不应将位于括号之间的任何附图标记理解成对权利要求的限制。词语“包含”不排除存在未列在权利要求中的部件或步骤。位于部件之前的词语“一”或“一个”不排除存在多个这样的部件。此外，需要说明的是，在本说明书的描述中，术语“一个实施例”、“一些实施例”、“实施例”、“示例”、“具体示例”或“一些示例”等的描述，是指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。

尽管已描述了本发明的优选实施例，但本领域的技术人员在得知了基本创造性概念后，则可对这些实施例做出另外的变更和修改。所以，权利要求应该解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种修改和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也应该包含这些修改和变型在内。

Claims

1.一种服务器集群的数据存储方法，其特征在于，所述方法包括：

S20、所述中间件的数据收集后台服务根据日志更新记录信息获取第一服务器中的与日志更新记录信息对应的日志信息，所述日志信息包括：日志数据，该日志数据的标识；

2.根据权利要求1所述的数据存储方法，其特征在于，所述服务器集群包括多个不同类型的服务器，其各个服务器所在地理位置不同。

3.根据权利要求2所述的数据存储方法，其特征在于，所述服务器集群包括：游戏服务器、web服务器和/或应用服务器。

4.根据权利要求1至3任一所述的数据存储方法，其特征在于，所述日志更新记录信息包括：日志数据的标识、服务器标识和时间标识；

所述中间件包括多个数据收集后台服务，每一数据收集后台服务对应一种数据类型的日志信息；所述数据类型与所述日志数据的标识相同；

所述S20包括：

5.根据权利要求1所述的数据存储方法，其特征在于，消息队列服务包括：多个队列，各队列中排列的日志数据的标识不同；

6.根据权利要求1所述的数据存储方法，其特征在于，所述方法还包括：

7.根据权利要求6所述的数据存储方法，其特征在于，所述数据消费者和ES为不同设备中的程序；所述中间件位于云主机中，所述云主机与服务器集群为不同的设备。

8.一种电子设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上权利要求1至7任一项所述的服务器集群的数据存储方法的步骤。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上权利要求1至7任一项所述的服务器集群的数据存储方法的步骤。