数据处理方法及装置与流程

1.本技术涉及计算机技术领域，特别涉及一种数据处理方法及装置。


背景技术：

2.随着互联网技术的发展，游戏成为了用户不可分割的一部分，而游戏服务方为了能够向用户提供优质的游戏服务；通常情况下，都会在一款游戏中提供多个区服，以方便对游戏关联的玩家进行合规化处理；而随着服务器性能的提高，各种类型的游戏所对应的服务器所能够负载的计算量也变的越来越高；为了能够降低对服务器进行维护的文本，将会涉及到合服处理，即将同一游戏中的至少两个区服合并到一起，这就会涉及到不同区服所对应的数据的合并处理操作；现有技术中，在对游戏进行合服处理时，都是针对一款游戏单独设置一种合服工具，合服工具的复用性较低，且需要维护人员参与，很大程度上加大了合服处理周期，从而会影响玩家的体验，同时由于不同的游戏涉及到的数据类型、字符串类型或二进制数据并不一致，这就导致不同的游戏进行合服处理时，需要针对每款游戏单独编写一个合服工具，且该工具只能够针对单独的一个游戏涉及到的服务器进行合服处理，合服工具的复用性较低；同时因为合服工具的编写都是由c代码实现的，因此如果需要对合服工具进行更新时，就需要重新编写c代码，在此过程会消耗更多的人力物力，因此亟需一种有效的方案以解决上述问题。


技术实现要素：

3.有鉴于此，本技术实施例提供了一种数据处理方法，以解决现有技术中存在的技术缺陷。本技术实施例同时提供了一种数据处理装置，一种计算设备，以及一种计算机可读存储介质。
4.根据本技术实施例的第一方面，提供了一种数据处理方法，包括：
5.接收针对目标游戏中的至少两个服务器提交的合并请求；
6.根据所述合并请求读取预设的数据信息配置表，获得所述目标游戏对应的服务器合并信息；
7.在所述至少两个服务器中确定主服务器和从服务器，并分别确定所述主服务器和所述从服务器对应的数据库；
8.基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理。
9.可选地，所述根据所述合并请求读取预设的数据信息配置表，获得所述目标游戏对应的服务器合并信息，包括：
10.对所述合并请求进行解析，获得所述目标游戏对应的游戏标识；
11.根据所述游戏标识读取所述预设的数据信息配置表，获得所述目标游戏对应的数据信息；
12.将所述数据信息进行整合，根据整合结果获得所述目标游戏对应的所述服务器合
并信息。
13.可选地，所述在所述至少两个服务器中确定主服务器和从服务器，包括：
14.根据所述合并请求确定所述至少两个服务器对应的服务器合并路径；
15.选择所述服务器合并路径中的末端节点对应的服务器作为所述主服务器；
16.选择所述服务器合并路径中的中间节点和起始节点分别对应的服务器作为所述从服务器。
17.可选地，所述基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理步骤执行之前，还包括：
18.判断所述服务器合并信息中是否存在所述目标游戏对应的冲突处理策略；
19.若否，执行所述基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理步骤。
20.可选地，所述判断所述服务器合并信息中是否存在所述目标游戏对应的冲突处理策略的判断结果为是，则执行如下步骤：
21.读取所述从服务器对应的数据库中的游戏数据；
22.根据所述冲突处理策略在所述游戏数据中确定初始游戏数据，并将所述初始游戏数据转换为目标游戏数据；
23.基于所述目标游戏数据对所述从服务器对应的数据库进行更新；
24.相应的，所述基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理，包括：
25.基于所述服务器合并信息对所述主服务器对应的数据库中的游戏数据，以及所述从服务器更新后的数据库中的游戏数据进行合并处理。
26.可选地，所述根据所述冲突处理策略在所述游戏数据中确定初始游戏数据，包括：
27.根据所述冲突处理策略确定冲突数据类型，并在所述游戏数据中确定所述冲突数据类型对应的中间游戏数据；
28.将所述中间游戏数据与所述主服务器对应的数据库中的游戏数据进行比对，根据比对结果确定所述初始游戏数据。
29.可选地，所述将所述初始游戏数据转换为目标游戏数据，包括：
30.将所述初始游戏数据中的字符类型数据转换为目标字符类型数据，以及所述初始游戏数据中的二进制数据转换为目标二进制数据；
31.基于所述目标字符类型数据和所述目标二进制数据组成所述目标游戏数据。
32.可选地，将所述初始游戏数据中的二进制数据转换为目标二进制数据，包括：
33.在所述初始游戏数据中提取第一二进制数据和第二二进制数据，并将所述第一二进制数据向用户进行展示；
34.接收所述用户针对所述第一二进制数据提交的调整指令，根据所述调整指令将所述第一二进制数据转换为第三二进制数据；
35.根据所述冲突处理策略将所述第二二进制数据转换为第四二进制数据；
36.基于所述第三二进制数据和所述第四二进制数据组成所述目标二进制数据。
37.可选地，所述基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理步骤执行之前，还包括：
38.提取所述主服务器对应的数据库中的第一数据，以及所述从服务器对应的数据库中的第二数据；
39.将所述第一数据和所述第二数据分别写入备份数据库。
40.可选地，所述基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理步骤执行之后，还包括：
41.在合并处理结果为合并失败的情况下，读取合并处理操作对应的业务日志；
42.根据所述业务日志确定合并失败信息，基于所述合并失败信息在所述备份数据库中提取所述第一数据和所述第二数据；
43.将所述第一数据写入所述主服务器对应的数据库，以及将所述第二数据写入所述从服务器对应的数据库。
44.可选地，所述基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理，包括：
45.基于所述服务器合并信息将所述从服务器对应的数据库中的数据合并到所述主服务器对应的数据库。
46.根据本技术实施例的第二方面，提供了一种数据处理装置，包括：
47.接收模块，被配置为接收针对目标游戏中的至少两个服务器提交的合并请求；
48.读取模块，被配置为根据所述合并请求读取预设的数据信息配置表，获得所述目标游戏对应的服务器合并信息；
49.确定模块，被配置为在所述至少两个服务器中确定主服务器和从服务器，并分别确定所述主服务器和所述从服务器对应的数据库；
50.合并模块，被配置为基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理。
51.根据本技术实施例的第三方面，提供了一种计算设备，包括：
52.存储器和处理器；
53.所述存储器用于存储计算机可执行指令，所述处理器执行所述计算机可执行指令时实现所述数据处理方法的步骤。
54.根据本技术实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现所述数据处理方法的步骤。
55.本技术提供的数据处理方法，在接收针对目标游戏中的至少两个服务器提交的合并请求后，可以根据合并请求读取预设的数据信息配置表，以获得目标游戏对应的服务器合并信息，实现通过数据信息配置表存储大量游戏的服务器合并信息，达到高复用的效率，并且节省运维人员的额外操作；在确定服务器合并信息后，可以在至少两个服务器中确定主服务器和从服务器，并确定二者分别对应的数据库，最后按照服务器合并信息对主服务器和从服务器对应的数据库中的数据进行合并处理即可，实现了不仅可以支持多游戏的合服处理，还能够提高游戏的合服处理操作，从而能够减少游戏维护周期，以在较短的时间内继续向玩家提供游戏服务。
附图说明
56.图1是本技术一实施例提供的一种数据处理方法的流程图；
57.图2是本技术一实施例提供的一种数据处理方法中冲突处理操作的流程图；
58.图3是本技术一实施例提供的一种应用于游戏区服合并场景中的数据处理方法的处理流程图；
59.图4是本技术一实施例提供的一种数据处理装置的结构示意图；
60.图5是本技术一实施例提供的一种计算设备的结构框图。
具体实施方式
61.在下面的描述中阐述了很多具体细节以便于充分理解本技术。但是本技术能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本技术内涵的情况下做类似推广，因此本技术不受下面公开的具体实施的限制。
62.在本技术一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本技术一个或多个实施例。在本技术一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本技术一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
63.应当理解，尽管在本技术一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本技术一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。
64.首先，对本发明一个或多个实施例涉及的名词术语进行解释。
65.rpg(role
‑
playing game)：角色扮演游戏，由玩家扮演游戏中的一个或数个角色，有完整的故事情节的游戏。
66.act(action game)：动作游戏。玩家控制游戏人物用各种方式消灭敌人或保存自己以过关的游戏，不刻意追求故事情节，设计主旨是面向普通玩家，以纯粹的娱乐休闲为目的。
67.avg(adventure game)：冒险游戏，由玩家控制游戏人物进行虚拟冒险的游戏。
68.fps(first personal shooting game)：第一人称视角射击游戏，以玩家的主观视角来进行射击游戏。
69.tps(third personal shooting game)：第三人称射击类游戏，与第一人称射击游戏的区别在于第一人称射击游戏里屏幕上显示的只有主角的视野，而第三人称射击游戏更加强调动作感，主角在游戏屏幕上是可见的。
70.在本技术中，提供了一种数据处理方法。本技术同时涉及一种数据处理装置、一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。
71.本实施例提供的数据处理方法，在接收针对目标游戏中的至少两个服务器提交的合并请求后，可以根据合并请求读取预设的数据信息配置表，以获得目标游戏对应的服务器合并信息，实现通过数据信息配置表存储大量游戏的服务器合并信息，达到高复用的效率，并且节省运维人员的额外操作；在确定服务器合并信息后，可以在至少两个服务器中确定主服务器和从服务器，并确定二者分别对应的数据库，最后按照服务器合并信息对主服务器和从服务器对应的数据库中的数据进行合并处理即可，实现了不仅可以支持多游戏的
合服处理，还能够提高游戏的合服处理操作，从而能够减少游戏维护周期，以在较短的时间内继续向玩家提供游戏服务。
72.图1示出了根据本技术一实施例提供的一种数据处理方法的流程图，具体包括以下步骤：
73.步骤s102，接收针对目标游戏中的至少两个服务器提交的合并请求。
74.具体的，所述目标游戏具体是指需要进行合服处理的游戏，所述目标游戏可以是rpg类型的游戏、act类型的游戏、avg类型的游戏、fps类型的游戏、tps类型的游戏等；实际应用中，进行合服处理的游戏可以根据需求选定，本实施例在此不作任何限定。相应的，所述至少两个服务器具体是指所述目标游戏对应的至少两个区服。例如在网络游戏j中，其包含有100个区服，玩家在登陆游戏后，需要选择不同的区服进行游戏；也就是说，不同的区服对应不同的玩家集群，且各个玩家集群互不影响(除游戏机制设定的跨服活动外)。进一步的，所述合并请求具体是指针对所述至少两个服务器进行合服的请求；相应的，合服处理具体是指将一个或多个区服合并到另一个区服中，实现将多个区服中的玩家数据和游戏数据进行合并，使得以前处于不同区服的玩家可以在同一区服中进行游戏。
75.基于此，所述合并请求可以由目标游戏的开发方所提交，当游戏开发方需要降低目标游戏的维护成本的情况下，可以通过合并请求启动合服处理操作，实现对目标游戏中的至少两个服务器进行合服处理；或者所述合并请求可以由目标游戏的代理方所提交，当游戏代理方监控到玩家数量降低的情况下，可以通过合并请求启动合服处理操作，实现对目标游戏中的至少两个服务器进行合服处理。
76.具体实施时，所述目标游戏可以是移动端类型的游戏或pc端类型的游戏，其只要涉及到多个服务器，都可以通过本实施例提供的数据处理方法完成合服处理操作，本实施例对此不作任何限定。
77.步骤s104，根据所述合并请求读取预设的数据信息配置表，获得所述目标游戏对应的服务器合并信息。
78.具体的，在接收到所述合并请求之后，进一步的，为了能够实现支持多种游戏的合服处理操作，可以预先存储数据信息配置表，所述数据信息配置表中记录有不同游戏涉及到的表类型信息、字段类型信息、字符串类型信息、数据类型信息、二进制数据信息和/或冲突处理策略信息等，用于支持不同游戏的合服处理操作。也就是说，当接收到所述合并请求后，可以根据请求读取所述预设的数据信息配置表，从而确定目标游戏对应的服务器合并信息，以方便后续可以基于所述服务器合并信息完成合服处理操作；其中，所述预设的数据信息配置表中存储有不同游戏分别对应的服务器合并信息；相应的，所述服务器合并信息具体是指针对游戏进行合服处理操作时，对各种类型的数据进行合并处理的相关信息，以及避免各种类型的数据发生冲突而进行冲突处理策略相关的信息；其中，对各种类型的数据进行合并处理的相关信息是指需要进行合并处理的数据类型信息、字符串信息、数字信息等。
79.进一步的，由于所述数据信息配置表中存储有不同游戏分别对应的服务器合并信息，如果采用遍历的方式将会耗费大量的计算资源，因此为了能够提高确定所述目标游戏对应的服务器合并信息，可以通过读取游戏标识的方式完成，本实施例中，具体实现方式如下所述：
80.对所述合并请求进行解析，获得所述目标游戏对应的游戏标识；
81.根据所述游戏标识读取所述预设的数据信息配置表，获得所述目标游戏对应的数据信息；
82.将所述数据信息进行整合，根据整合结果获得所述目标游戏对应的所述服务器合并信息。
83.具体的，所述游戏标识具体是指目标游戏所对应的唯一标识，且所述游戏标识具有唯一性；相应的，所述数据信息具体是指所述数据信息配置表中所记录的信息，所述数据信息包括但不限于目标游戏涉及的字段信息、字符串信息、数据类型信息、字节信息以及冲突处理策略信息等，用于支持后续合服处理操作。
84.基于此，在接收到所述合并请求后，可以对所述合并请求进行解析，获得所述目标游戏对应的游戏标识，之后基于该游戏标识读取所述预设的数据信息配置表，以快速的确定所述目标游戏对应的所述数据信息，此时确定了在目标游戏中的至少两个服务器进行合并处理时所需要涉及到的合并数据相关的信息，之后将所述数据信息进行整合，根据整合结果即可得到所述目标游戏对应的所述服务器合并信息，以方便后续在进行服务器合并处理时，可以基于所述服务器合并信息完成，以避免数据冲突的问题发生。
85.举例说明，当游戏开发商需要针对旗下的j游戏中的区服(服务器)a、区服b和区服c进行合服的情况下，此时游戏开发商将提交针对j游戏中的区服a、区服b和区服c合服请求；接收合服请求后，对合服请求进行解析，获得j游戏对应的游戏标识id_j，此时可以根据游戏标识id_j读取预设的数据信息配置表，数据信息配置表如下述表1所示，根据读取结果获得j游戏对应的数据信息，数据信息中包含脚本路径script，字段名key，数据类型type，以及冲突处理策略iscallscript，将这部分数据信息作为j游戏对应的区服合并信息，以用于后续完成区服a、区服b和区服c的合服处理操作；其中，表1如下：
[0086] scriptkeytypeiscallscript
……
id_js_jk_jt_ji_j
……
id_ss_sk_st_si_s
……………………………………
[0087]
综上，通过在数据信息配置表中写入游戏标识，可以快速的确定目标游戏对应的服务区合并信息，以实现提高合服处理效率，并且通过数据信息配置表记录多个游戏对应的服务器合并信息，以达到支持任意游戏合服处理的操作，从而实现具备更好的复用性。
[0088]
步骤s106，在所述至少两个服务器中确定主服务器和从服务器，并分别确定所述主服务器和所述从服务器对应的数据库。
[0089]
具体的，在上述确定所述目标游戏对应的服务器合并信息的基础上，进一步的，由于服务器的合并一般都存在主从关系，即需要将一个服务器向另一个服务器合并，如将j游戏中的区服2合并到区服1，则最后合并完成所保留的区服即为区服1，其合并后的区服1包含区服2所有的玩家；因此当在对目标游戏中的至少两个服务器进行合并处理时，需要在至少两个服务器中确定主服务器和从服务器。其中，主服务器具体是指最终能够保留的服务器，从服务器具体是指需要向主服务器进行合并的服务器，即最终所述从服务器将合并到主服务器中；实际应用中，在一次合服处理的过程中，主服务器仅存在一个，而从服务器可以存在多个，也就是说，可以同时将多个服务器都合并到同一主服务器中，本实施例在此不
对从服务器的数据进行限定，可以根据实际应用场景选择。
[0090]
基于此，所述主服务器和所述从服务器所对应的数据库即为存储服务器中涉及到的游戏数据的数据库，其存储有玩家数据、游戏数据和日志等内容，当进行主服务器和从服务器合并时，实则就是将服务器对应的数据库中的数据进行合并处理，以使得主服务器对应的数据库可以容纳多个从服务器对应的数据库中的内容，最后实现将从服务器中的玩家关联的游戏数据都迁移到主服务器当中，实现将主服务器和从服务器中涉及到的玩家进行汇总到一个服务器中进行游戏。
[0091]
进一步的，在从至少两个服务器中确定所述主服务器和所述从服务器时，由于最后的合服处理操作是基于所述合并请求控制的，因此可以通过所述合并请求确定合并路径的方式确定主/从服务器，本实施例中，具体实现方式如下所述：
[0092]
根据所述合并请求确定所述至少两个服务器对应的服务器合并路径；
[0093]
选择所述服务器合并路径中的末端节点对应的服务器作为所述主服务器；
[0094]
选择所述服务器合并路径中的中间节点和起始节点分别对应的服务器作为所述从服务器。
[0095]
具体的，所述服务器合并路径具体是指在服务器进行合并处理时，将一个服务器合并到另一个服务器所对应的合并路径。相应的，所述末端节点具体是指所述服务器合并路径中位于最后一个环节的节点，且该节点所对应的服务器为所述主服务器；相应的，所述起始节点具体是指所述服务器合并路径中位于第一个环节的节点，所述中间节点具体是指所述服务器合并路径中位于起始阶段和末端节点中间的节点，当需要进行合服处理的服务器仅为两个的情况下，则所述中间节点可以为空集；其中，所述中间节点和所述起始节点对应的服务器即为需要向主服务器进行合并的从服务器。
[0096]
基于此，当接收到所述合服请求后，可以根据所述合服请求确定所述至少两个服务器对应的服务器合并路径，确定所述服务器合并路径中的起始节点、中间节点和末端节点，此时选择所述起始节点和所述中间节点对应的服务器作为所述从服务器，以及选择所述末端节点对应的服务器作为所述主服务器即可，以用于后续基于主/从服务器完成合服处理即可。
[0097]
沿用上例，根据合服请求确定需要对区服a、区服b和区服c进行合服处理的情况下，此时根据合服请求确定游戏开发商所需要进行区服合并的路径为区服c<区服b<区服a，也就是说，游戏开发方需要将区服c和区服b都合并到区服a，此时根据路径确定起始节点对应的区服为c，中间节点对应的区服为b，末端节点对应的区服为a，根据各个节点对应的区服信息确定区服c为主区服，区服b和区服a为从区服，以方便后续进行区服之间的合并处理。
[0098]
综上，通过分析服务器合并路径的方式完成主服务器和从服务器的确定，不仅可以保证合并路线的准确性，还能够减少运维人员的参与度，从而进一步提高了合服处理效率，以及达到节省人力物力的目的。
[0099]
步骤s108，基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理。
[0100]
具体的，在上述完成所述主服务器和所述从服务器的确定，以及主服务器和从服务器对应的数据库确定之后，进一步的，此时即可将数据库中的数据按照所述服务器合并
信息进行合并处理即可。也就是说，在合并处理时，实则是基于所述服务器合并信息将所述从服务器对应的数据库中的数据合并到所述主服务器对应的数据库；以达到从服务器对应的游戏数据都迁移到主服务器对应的数据库中的目的，从而完成所述主服务器和所述从服务器的合服处理，后续在进行游戏时，主服务器涉及到的玩家和从服务器涉及到的玩家即可在一个服务器中进行游戏，以达到节省维护服务器资源的目的，从而更加方便对玩家进行合规化处理。
[0101]
实际应用中，在合服处理时，虽然不同的玩家可能处于不同的服务器，但是所参与的游戏数据同一款游戏，因此在合服处理时，实则是将各个服务器对应的数据合并到一起，游戏内容并不会发生变化。同时由于各个服务器对应的数据库中的数据一般都是单独存放，相互之间不会产生干扰，且可能存在重叠部分，除游戏本体涉及到的数据外，还存在重叠的数据可能是玩家对应的id，登录名称，或者游戏角色名称；如区服a和区服b都可以存在游戏角色名称为123的人物。但是当进行合服处理时，如果这部分重叠的数据不进行处理，将会造成合服错误，同时会造成同一服务器中产生大量重复id，登录名称或游戏角色名称的情况，很容易造成玩家混淆，因此为了能够避免这一问题产生的影响，在进行数据合并处理时，可以先进行冲突处理策略的判断，本实施例中，具体实现方式如下所述：
[0102]
判断所述服务器合并信息中是否存在所述目标游戏对应的冲突处理策略；
[0103]
若否，执行步骤s108，基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理。
[0104]
具体的，当所述服务器合并信息中未存在目标游戏对应的冲突处理策略的情况下，说明目标游戏在进行主/从服务器的合服处理时，并不会涉及到重叠数据，此时则直接进行合服处理即可。即将从服务器对应的数据库中的数据合并到主服务器对应的数据库中，达到合服的目的。
[0105]
若是，执行步骤s1082至步骤s1088；图2是本技术一实施例提供的一种数据处理方法中冲突处理操作的流程图；具体包括步骤s1082至步骤s1088：
[0106]
步骤s1082，读取所述从服务器对应的数据库中的游戏数据。
[0107]
具体的，当所述服务器合并信息中存在目标游戏对应的冲突处理策略的情况下，说明目标游戏在进行主/从服务器的合服处理时，将会涉及到重叠数据，并且同一游戏在进行多次不同的合服处理时，所能够涉及到的冲突数据类型大多都是相同的，因此在确定服务器合并信息中存在所述目标游戏对应的冲突处理策略的情况下，即可按照所述冲突处理策略进行调整，以解决冲突问题后再进行合服处理。
[0108]
基于此，在确定存在冲突处理策略的情况下，说明目标游戏的服务器所涉及到的数据存在冲突的可能，为了避免数据混乱，可以对从服务器对应的数据库中的数据进行转换，即读取所述从服务器对应的数据库中的游戏数据，以实现后续可以结合冲突处理策略进行转换，得到与主服务器对应的数据库中的数据不冲突的数据进行合并，以达到合服的目的。
[0109]
步骤s1084，根据所述冲突处理策略在所述游戏数据中确定初始游戏数据，并将所述初始游戏数据转换为目标游戏数据。
[0110]
具体的，所述冲突处理策略具体是指对目标游戏的从服务器对应的数据库中的游戏数据进行转换的策略，且被转换的游戏数据是可能发生与主服务器对应的数据库中的数
据发生冲突的数据；相应的，所述初始游戏数据即为从服务器对应的数据库中可能发生的游戏数据，所述目标游戏数据具体是指按照所述冲突处理策略进行转换后得到的游戏数据。
[0111]
基于此，在确定存在冲突处理策略的情况下，此时可以按照所述冲突处理策略在所述从服务器对应的数据库中的游戏数据中确定初始游戏数据，并对其进行转换，即可得到所述目标游戏数据，以避免后续合并时发生冲突而导致服务器合服失败。
[0112]
进一步的，在根据所述冲突处理策略确定所述初始游戏数据时，由于所述从服务器对应的数据库中的游戏数据较多，如果为了避免冲突发生，对每条数据都进行转换，将浪费大量的计算资源，因此为了节省计算资源的浪费，可以选择与主服务器对应的数据库中的游戏数据重叠的数据作为所述初始游戏数据，本实施例中，具体实现方式如下所述：
[0113]
根据所述冲突处理策略确定冲突数据类型，并在所述游戏数据中确定所述冲突数据类型对应的中间游戏数据；
[0114]
将所述中间游戏数据与所述主服务器对应的数据库中的游戏数据进行比对，根据比对结果确定所述初始游戏数据。
[0115]
具体的，所述冲突数据类型具体是指根据所述冲突处理策略所确定的可能存在数据冲突的类型，为了避免数据冲突造成合服失败，冲突处理策略中将记录更加全面的冲突数据类型，以此可以将所述游戏数据中的可能发生冲突的游戏数据都提取出来，即这部分数据为所述中间游戏数据；进一步的，虽然所述中间游戏数据与主服务器对应的数据库中的数据存在冲突的可能性较大，但是如果不对齐进行筛选，直接进行转换计算量也是较大的，因此可以在得到所述中间游戏数据的情况下，将所述中间游戏数据源与所述主服务器对应的数据库中的游戏数据进行比对，以此筛选出所述初始游戏数据，以方便后续进行转换处理。
[0116]
基于此，当根据所述冲突处理策略确定所述冲突数据类型的情况下，此时可以根据所述冲突数据类型在所述游戏数据中筛选出所述中间游戏数据，为了能够进一步减少计算量的消耗，还可以基于所述中间游戏数据与所述主服务器对应的数据库中的游戏数据进行比对，从而更细粒度的确定所述初始游戏数据，以完成后续的转换处理即可，实现了只对会发生冲突的数据进行确定，不仅节省计算资源，还有效的提高了合服处理效率。
[0117]
进一步的，在将所述初始游戏数据转换为所述目标游戏数据的过程中，考虑到可能存在冲突的数据类型较多，因此为了能够充分的避免冲突问题，可以针对不同的数据类型进行不同的处理操作，本实施例中，具体实现方式如下所述：
[0118]
将所述初始游戏数据中的字符类型数据转换为目标字符类型数据，以及所述初始游戏数据中的二进制数据转换为目标二进制数据；
[0119]
基于所述目标字符类型数据和所述目标二进制数据组成所述目标游戏数据。
[0120]
具体的，所述字符类型数据具体是指所述初始游戏数据中对应于数字和字符串类型的数据，这部分数据映射到游戏中，可以是玩家的id对应的数据，名称对应的数据或游戏角色对应的数据；相应的，所述二进制数据具体是指所述初始游戏数据中对应于二进制数据类型的数据，这部分数据映射到游戏中，可以是玩家创造的建筑物对应的名称，虚拟动物对应的命名等。
[0121]
其中，转换后得到的所述目标字符类型数据具体是指在原有的字符类型数据的基
础上添加了其他不影响游戏内容的字段的数据；相应的，所述目标二进制数据具体是指在所述二进制数据的基础上对每个字段重新定以后所得到的二进制数据。
[0122]
基于此，当确定所述初始游戏数据后，即可选择所述初始游戏数据中的字符类型数据进行转换，得到所述目标字符类型数据；同时对所述初始游戏数据中的二进制数据进行转换，得到所述目标二进制数据，最后基于所述目标字符类型数据和所述目标二进制数据即可组成所述目标游戏数据，用于后续对从服务器对应的数据库进行更新，再进行合服处理操作即可。
[0123]
更进一步的，在将所述二进制数据转换为所述目标二进制数据的过程中，考虑到需要对二进制数据中的个别字段进行重新定义，为了能够保证定义后的二进制数据不会因为合服处理出现冲突的问题，可以向用户展示重新定义的二进制数据，本实施例中，具体实现方式如下所述：
[0124]
在所述初始游戏数据中提取第一二进制数据和第二二进制数据，并将所述第一二进制数据向用户进行展示；
[0125]
接收所述用户针对所述第一二进制数据提交的调整指令，根据所述调整指令将所述第一二进制数据转换为第三二进制数据；
[0126]
根据所述冲突处理策略将所述第二二进制数据转换为第四二进制数据；
[0127]
基于所述第三二进制数据和所述第四二进制数据组成所述目标二进制数据。
[0128]
具体的，所述第一二进制数据具体是指所述初始游戏数据中需要游戏策略进行重新定义的二进制数据，且这部分数据无法根据所述冲突处理策略进行转换；所述第二二进制数据是指所述初始游戏数据中需要游戏策略进行重新定义的二进制数据，且这部分数据可以根据所述冲突处理策略进行转换；相应的，所述第三二进制数据即为游戏策划重新定义后得到的二进制数据；所述第四二进制数据即为根据冲突处理策略重新定义后得到的二进制数据。
[0129]
基于此，首先可以从所述初始游戏数据中提取所述第一二进制数据和所述第二二进制数据，并将所述第一二进制数据向用户进行展示；由于所述第一二进制数据和所述第二二进制数据都是需要重新定义字段的数据，因此可以接收到所述用户针对所述第一二进制数据提交的调整指令，此时即可根据所述调整指令对所述第一二进制数据进行转换，获得所述第三二进制数据；同时，如果将全部二进制数据都交给用户调整，将会浪费过多的人力，因此还可以选择所述第二二进制数据，直接按照所述冲突处理策略对其进行转换即可，以得到所述第四二进制数据，最后基于所述第三二进制数据和所述第四二进制数据即可组成所述目标二进制数据。
[0130]
综上，通过采用不同的处理策略对不同的二进制数据进行调整，不仅可以节省人力物力，还能够降低冲突问题产生的影响，进一步提高了服务器的合服处理操作。
[0131]
步骤s1086，基于所述目标游戏数据对所述从服务器对应的数据库进行更新。
[0132]
步骤s1088，基于所述服务器合并信息对所述主服务器对应的数据库中的游戏数据，以及所述从服务器更新后的数据库中的游戏数据进行合并处理。
[0133]
具体的，在上述将所述初始游戏数据转换为所述目标游戏数据后，此时即可根据转换后的所述目标游戏数据对所述从服务器对应的数据库进行更新，以实现后续合服处理时，可以避免数据冲突造成的合服失败的问题。
[0134]
基于此，在所述从服务器对应的数据库更新完成之后，即可根据所述服务器合并信息将更新后的数据库中的数据合并到所述主服务器对应的数据库中，以达到所述至少两个服务器的合并处理操作。
[0135]
沿用上例，当确定区服b和区服c为从区服，区服a为主区服的基础上，进一步的，此时可以检测j游戏对应的区服合并信息，若检测到j游戏对应的区服合并信息中包含冲突处理策略的情况下，可以进行冲突处理操作；即读取区服c和区服b分别对应的数据库中的游戏数据，根据冲突处理策略确定可能发生数据冲突的类型包括账号id数据，游戏角色名称数据，游戏角色宠物名称数据；则此时可以从区服c和区服b分别对应的数据库的游戏数据中提取这部分数据作为中间数据，并将区服c和区服b分别对应的账号id数据，游戏角色名称数据，游戏角色宠物名称数据与区服a对应的数据库中的游戏数据进行比对，根据比对结果确定区服c与区服a存在游戏角色名称为“甲”相同的数据(区服a和区服c中都存在名称为甲的游戏角色)，同时还确定区服b和区服a中存在账号id为“789”相同的数据(区服b和区服c中都存在账号为789的游戏id)，则将这部分数据作为初始游戏数据。
[0136]
进一步的，为了避免区服b和区服c合并到区服a出现游戏角色名称和账号id重复的问题，此时可以选择初始游戏数据中的字符类型数据：游戏角色名称数据进行转换，转换方式具体是指对区服c中游戏角色名称“甲”对应的数据加入新的字段，使得区服c中的游戏角色名称更改为“甲1”；同时选择初始游戏数据中的二进制数据：账号id数据进行转换，转换方式具体是指将区服b中账号id为“789”对应的二进制数据向游戏策划进行展示，当接收到游戏策划针对账号id为“789”对应的二进制数据提交的调整指令后，此时可以对区服b中的账号id为“789”对应的二进制数据进行转换，使得区服b中的账号id为“789”更改为：“7890”；根据冲突调整策略完成初始游戏数据到目标游戏数据的转换后，此时即可根据转换后的数据对区服b和区服c对应的数据库进行更新，最后再将更新后的区服b和区服c对应的数据库中的游戏数据合并到区服a对应的数据库中即可，以达到合并区服c，区服b和区服a的目的；完成j游戏中的合服处理操作。
[0137]
综上，通过采用冲突处理策略对不同类型的数据进行转换，不仅可以避免数据冲突而导致服务器合并失败的问题，还能够提高合服成功率，从而进一步提高了合服处理效率。
[0138]
同时，由于冲突处理策略是预先写在所述数据信息配置表中的，当需要进行策略更新时，只需要采用写入条件的方式即可更新冲突处理策略，不需要对底层代码进行更新，很大程度上节省了重新编辑合服处理工具的时间，从而进一步的提高了合服处理的复用性。
[0139]
此外，当进行至少两个服务器的合并处理时，由于其根本需要涉及到数据的合并处理，如果合并失败，很可能造成数据的丢失，从而无法支持目标游戏正常运行，因此为了避免数据丢失问题带来的影响，可以采用备份的方式进行数据持久化，本实施例中，具体实现方式如下所述：
[0140]
提取所述主服务器对应的数据库中的第一数据，以及所述从服务器对应的数据库中的第二数据；
[0141]
将所述第一数据和所述第二数据分别写入备份数据库。
[0142]
具体的，所述第一数据具体是指所述主服务器对应的数据库中的游戏数据，所述
第二数据具体是指所述从服务器对应的数据库中的游戏数据；基于此，当需要进行合服处理时，可以先将所述主服务器对应的数据库中的第一数据以及所述从服务器对应的数据库中的第二数据分别写入备份数据库，以避免在发生合服失败时，可以对数据进行还原。
[0143]
更进一步的，当合服失败的情况下，即可从所述备份数据库中提取第一数据和第二数据进行还原，同时还可以读取业务日志，以确定合服失败的原因，及时作出调整，本实施例中，具体实现方式如下所述：
[0144]
在合并处理结果为合并失败的情况下，读取合并处理操作对应的业务日志；
[0145]
根据所述业务日志确定合并失败信息，基于所述合并失败信息在所述备份数据库中提取所述第一数据和所述第二数据；
[0146]
将所述第一数据写入所述主服务器对应的数据库，以及将所述第二数据写入所述从服务器对应的数据库。
[0147]
具体的，所述业务日志具体是指记录合服处理时所发生的数据交叉、业务操作等信息的日志；相应的，所述合并失败信息具体是指导致合服处理操作失败的相关信息，通过所述合服失败信息可以触发数据的还原处理，同时方便运维人员分析合服失败原因。
[0148]
基于此，在合并数据的合并结果为失败的情况下，可以读取合并处理操作对应的业务日志，以确定所述合并失败信息，此时基于合并失败信息触发数据还原处理，即根据所述合并失败信息提取备份数据库中的第一数据和第二数据，并将所述第一数据写入所述主服务器对应的数据库，以及将所述第二数据写入所述从服务器对应的数据库，以达到数据还原的目的，避免数据丢失。
[0149]
综上，通过对数据进行备份处理，可以有效的避免合并失败的情况下数据丢失的问题，同时通过分析业务日志确定合并失败信息，可以方便用户快速的确定合服失败的原因，从而能够及时作出相应，避免缺口扩大。
[0150]
本实施例提供的数据处理方法，在接收针对目标游戏中的至少两个服务器提交的合并请求后，可以根据合并请求读取预设的数据信息配置表，以获得目标游戏对应的服务器合并信息，实现通过数据信息配置表存储大量游戏的服务器合并信息，达到高复用的效率，并且节省运维人员的额外操作；在确定服务器合并信息后，可以在至少两个服务器中确定主服务器和从服务器，并确定二者分别对应的数据库，最后按照服务器合并信息对主服务器和从服务器对应的数据库中的数据进行合并处理即可，实现了不仅可以支持多游戏的合服处理，还能够提高游戏的合服处理操作，从而能够减少游戏维护周期，以在较短的时间内继续向玩家提供游戏服务。
[0151]
下述结合附图3，以本技术提供的数据处理方法对游戏区服合并的处理应用为例，对所述数据处理方法进行进一步说明。其中，图3示出了本技术一实施例提供的一种应用于游戏区服合并场景中的数据处理方法的处理流程图，具体包括以下步骤：
[0152]
步骤s302，接收游戏开发方针对目标游戏中的第一区服和第二区服提交的合服请求。
[0153]
步骤s304，对合服请求进行解析，获得目标游戏对应的游戏标识。
[0154]
步骤s306，根据游戏标识读取预设的数据信息配置表，获得目标游戏对应的区服合并信息。
[0155]
步骤s308，根据合并请求选择第一区服作为主区服，第二区服作为从区服。
[0156]
步骤s310，在服务器合并信息中包含冲突处理策略的情况下，读取从区服对应的数据库中的游戏数据。
[0157]
步骤s312，根据冲突处理策略在游戏数据中确定初始游戏数据，并将初始游戏数据转换为目标游戏数据。
[0158]
步骤s314，基于目标游戏数据对从区服对应的数据库进行更新。
[0159]
步骤s316，基于区服合并信息将从区服对应的更新后的数据库中的游戏数据合并到主区服对应的数据库。
[0160]
步骤s318，根据数据合并结果完成第一区服合并到第二区服的操作。
[0161]
本实施例提供的数据处理方法，在接收针对目标游戏中的至少两个服务器提交的合并请求后，可以根据合并请求读取预设的数据信息配置表，以获得目标游戏对应的服务器合并信息，实现通过数据信息配置表存储大量游戏的服务器合并信息，达到高复用的效率，并且节省运维人员的额外操作；在确定服务器合并信息后，可以在至少两个服务器中确定主服务器和从服务器，并确定二者分别对应的数据库，最后按照服务器合并信息对主服务器和从服务器对应的数据库中的数据进行合并处理即可，实现了不仅可以支持多游戏的合服处理，还能够提高游戏的合服处理操作，从而能够减少游戏维护周期，以在较短的时间内继续向玩家提供游戏服务。
[0162]
与上述方法实施例相对应，本技术还提供了数据处理装置实施例，图4示出了本技术一实施例提供的一种数据处理装置的结构示意图。如图4所示，该装置包括：
[0163]
接收模块402，被配置为接收针对目标游戏中的至少两个服务器提交的合并请求；
[0164]
读取模块404，被配置为根据所述合并请求读取预设的数据信息配置表，获得所述目标游戏对应的服务器合并信息；
[0165]
确定模块406，被配置为在所述至少两个服务器中确定主服务器和从服务器，并分别确定所述主服务器和所述从服务器对应的数据库；
[0166]
合并模块408，被配置为基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理。
[0167]
一个可选的实施例中，所述读取模块404进一步被配置为：
[0168]
对所述合并请求进行解析，获得所述目标游戏对应的游戏标识；根据所述游戏标识读取所述预设的数据信息配置表，获得所述目标游戏对应的数据信息；将所述数据信息进行整合，根据整合结果获得所述目标游戏对应的所述服务器合并信息。
[0169]
一个可选的实施例中，所述确定模块406进一步被配置为：
[0170]
根据所述合并请求确定所述至少两个服务器对应的服务器合并路径；选择所述服务器合并路径中的末端节点对应的服务器作为所述主服务器；选择所述服务器合并路径中的中间节点和起始节点分别对应的服务器作为所述从服务器。
[0171]
一个可选的实施例中，所述数据处理装置，包括：
[0172]
判断模块，被配置为判断所述服务器合并信息中是否存在所述目标游戏对应的冲突处理策略；
[0173]
若否，运行所述合并模块408。
[0174]
一个可选的实施例中，所述判断模块的判断结果为是，则运行如下模块：
[0175]
更新模块，被配置为读取所述从服务器对应的数据库中的游戏数据；根据所述冲
突处理策略在所述游戏数据中确定初始游戏数据，并将所述初始游戏数据转换为目标游戏数据；基于所述目标游戏数据对所述从服务器对应的数据库进行更新；
[0176]
相应的，所述合并模块408进一步被配置为：
[0177]
基于所述服务器合并信息对所述主服务器对应的数据库中的游戏数据，以及所述从服务器更新后的数据库中的游戏数据进行合并处理。
[0178]
一个可选的实施例中，所述更新模块进一步被配置为：
[0179]
根据所述冲突处理策略确定冲突数据类型，并在所述游戏数据中确定所述冲突数据类型对应的中间游戏数据；将所述中间游戏数据与所述主服务器对应的数据库中的游戏数据进行比对，根据比对结果确定所述初始游戏数据。
[0180]
一个可选的实施例中，所述更新模块进一步被配置为：
[0181]
将所述初始游戏数据中的字符类型数据转换为目标字符类型数据，以及所述初始游戏数据中的二进制数据转换为目标二进制数据；基于所述目标字符类型数据和所述目标二进制数据组成所述目标游戏数据。
[0182]
一个可选的实施例中，所述更新模块进一步被配置为：
[0183]
在所述初始游戏数据中提取第一二进制数据和第二二进制数据，并将所述第一二进制数据向用户进行展示；接收所述用户针对所述第一二进制数据提交的调整指令，根据所述调整指令将所述第一二进制数据转换为第三二进制数据；根据所述冲突处理策略将所述第二二进制数据转换为第四二进制数据；基于所述第三二进制数据和所述第四二进制数据组成所述目标二进制数据。
[0184]
一个可选的实施例中，所述数据处理装置，还包括：
[0185]
备份模块，被配置为提取所述主服务器对应的数据库中的第一数据，以及所述从服务器对应的数据库中的第二数据；将所述第一数据和所述第二数据分别写入备份数据库。
[0186]
一个可选的实施例中，所述数据处理装置，还包括：
[0187]
还原模块，被配置为在合并处理结果为合并失败的情况下，读取合并处理操作对应的业务日志；根据所述业务日志确定合并失败信息，基于所述合并失败信息在所述备份数据库中提取所述第一数据和所述第二数据；将所述第一数据写入所述主服务器对应的数据库，以及将所述第二数据写入所述从服务器对应的数据库。
[0188]
一个可选的实施例中，所述合并模块408进一步被配置为：
[0189]
基于所述服务器合并信息将所述从服务器对应的数据库中的数据合并到所述主服务器对应的数据库。
[0190]
本实施例提供的数据处理装置，在接收针对目标游戏中的至少两个服务器提交的合并请求后，可以根据合并请求读取预设的数据信息配置表，以获得目标游戏对应的服务器合并信息，实现通过数据信息配置表存储大量游戏的服务器合并信息，达到高复用的效率，并且节省运维人员的额外操作；在确定服务器合并信息后，可以在至少两个服务器中确定主服务器和从服务器，并确定二者分别对应的数据库，最后按照服务器合并信息对主服务器和从服务器对应的数据库中的数据进行合并处理即可，实现了不仅可以支持多游戏的合服处理，还能够提高游戏的合服处理操作，从而能够减少游戏维护周期，以在较短的时间内继续向玩家提供游戏服务。
[0191]
上述为本实施例的一种数据处理装置的示意性方案。需要说明的是，该数据处理装置的技术方案与上述的数据处理方法的技术方案属于同一构思，数据处理装置的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。此外，装置实施例中的各组成部分应当理解为实现该程序流程各步骤或该方法各步骤所必须建立的功能模块，各个功能模块并非实际的功能分割或者分离限定。由这样一组功能模块限定的装置权利要求应当理解为主要通过说明书记载的计算机程序实现该解决方案的功能模块构架，而不应当理解为主要通过硬件方式实现该解决方案的实体装置。
[0192]
图5示出了根据本技术一实施例提供的一种计算设备500的结构框图。该计算设备500的部件包括但不限于存储器510和处理器520。处理器520与存储器510通过总线530相连接，数据库550用于保存数据。
[0193]
计算设备500还包括接入设备540，接入设备540使得计算设备500能够经由一个或多个网络560通信。这些网络的示例包括公用交换电话网(pstn)、局域网(lan)、广域网(wan)、个域网(pan)或诸如因特网的通信网络的组合。接入设备540可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(nic))中的一个或多个，诸如ieee802.11无线局域网(wlan)无线接口、全球微波互联接入(wi
‑
max)接口、以太网接口、通用串行总线(usb)接口、蜂窝网络接口、蓝牙接口、近场通信(nfc)接口，等等。
[0194]
在本技术的一个实施例中，计算设备500的上述部件以及图5中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图5所示的计算设备结构框图仅仅是出于示例的目的，而不是对本技术范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。
[0195]
计算设备500可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或pc的静止计算设备。计算设备500还可以是移动式或静止式的服务器。
[0196]
其中，处理器520用于执行如下计算机可执行指令：
[0197]
接收针对目标游戏中的至少两个服务器提交的合并请求；
[0198]
根据所述合并请求读取预设的数据信息配置表，获得所述目标游戏对应的服务器合并信息；
[0199]
在所述至少两个服务器中确定主服务器和从服务器，并分别确定所述主服务器和所述从服务器对应的数据库；
[0200]
基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理。
[0201]
上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的数据处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。
[0202]
本技术一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时以用于：
[0203]
接收针对目标游戏中的至少两个服务器提交的合并请求；
[0204]
根据所述合并请求读取预设的数据信息配置表，获得所述目标游戏对应的服务器合并信息；
[0205]
在所述至少两个服务器中确定主服务器和从服务器，并分别确定所述主服务器和所述从服务器对应的数据库；
[0206]
基于所述服务器合并信息对所述主服务器和所述从服务器分别对应的数据库中的数据进行合并处理。
[0207]
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的数据处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述数据处理方法的技术方案的描述。
[0208]
上述对本技术特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
[0209]
所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
[0210]
需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本技术所必须的。
[0211]
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
[0212]
以上公开的本技术优选实施例只是用于帮助阐述本技术。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本技术的内容，可作很多的修改和变化。本技术选取并具体描述这些实施例，是为了更好地解释本技术的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本技术。本技术仅受权利要求书及其全部范围和等效物的限制。