一种数据处理方法、系统、存储介质及电子设备与流程

1.本技术涉及数据处理技术领域，更具体地说，涉及一种数据处理方法、系统、存储介质及电子设备。


背景技术：

2.目前，对于消息的存储有多种方式实现，主要为了实现未读消息功能、已读消息功能、最新消息功能、消息未读数功能和消息存储时间功能等。
3.对于消息的未读消息功能和已读消息功能，一般会采用两个队列来实现；对于消息未读数功能，则采用一个独立的标识做加减运算来实现；对于最新消息功能，则在标识上控制消息的过期；对于消息存储时间功能，则采用一个独立的集群来存储来实现。
4.现有技术中，消息的存储和读取存在如下缺点，一是采用两个队列来存储已读和未读，会导致标识的数量增加，会增加集群的存储，占用空间，且未读消息变为已读消息，需要移动数据，增加消息读取的压力；二是消息的未读数采用一个独立的标识，同样会增加标识的数量；三是在标识上控制过期，就需要在标识的维度上加上时间维度，如果7天过期，就会有7个标识，同样会增加标识的数量，占用空间。
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.图1为本技术实施例公开的一种数据处理方法的流程示意图；
39.图2为本技术实施例公开的单队列的数据结构示意图；
40.图3为本技术实施例公开的集群存储的架构图；
41.图4为本技术实施例公开的通过预设分布式算法将各个业务通知消息分散存储至各自对应集群中的流程示意图；
42.图5为本技术实施例公开的通过单队列对各个业务通知消息进行无锁化处理的流程示意图；
43.图6为本技术实施例公开的一种数据处理系统的结构示意图；
44.图7为本技术实施例公开的一种电子设备的结构示意图。
具体实施方式
45.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
46.在本技术中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过
程、方法、物品或者设备中还存在另外的相同要素。
47.由背景技术可知，现有技术中的消息存储和读取的方式，降低了消息的存储性能和消息的读取效率。
48.为了解决上述问题，本技术实施例公开了一种数据处理方法、系统、存储介质及电子设备，通过单队列无锁化的数据结构实现消息的已读状态和未读状态，不会导致消息的标识的数量增加，当未读状态的消息通过单队列的分割标志符变为已读消息的业务通知消息时，只需要把原来的处于未读状态的业务通知消息的分数值加上负号，处于已读状态的业务通知消息就会被分到分割标志位的消息已读区域，无需数据删除和移动，提高读取消息的效率。具体实现方式通过下述实施例具体进行说明。
49.参考图1所示，为本技术实施例公开的一种数据处理方法的流程示意图，该数据处理方法主要包括如下步骤：
50.s101：获取各个业务通知消息；业务通知消息用于表征业务类型的通知消息。
51.其中，业务类型包括贷款业务类型、还款业务类型、还款计划生成业务等。
52.各个业务通知消息的消息类型，本技术不做具体限定。
53.s102：将各个业务通知消息存储至单队列中，并确定各个业务通知消息的消息状态；消息状态至少包括已读状态和未读状态。
54.在s102中，通过单队列对各个业务通知消息进行无锁化处理，实现各个业务通知消息的已读、未读、最新消息的统计、未读消息数量统计、过期消息的删除等操作。具体无锁化处理参考下述s103和s104所述。
55.消息状态包括已读状态、未读状态、未读消息数量、过期消息状态等。
56.对于单队列的设计采用redis的zset结构，利用单队列的排序功能，存储每条业务通知消息，采用long类型的时间戳作为业务通知消息的score值的排序标准，越早进入单队列的业务通知消息的分数score值越小，默认将score值最小的业务通知消息排在单队列的队尾。
57.s103：当消息状态为未读状态时，通过单队列的分割标志符将处于未读状态的各个业务通知消息分割至消息未读区域，并通过第一预设顺序对所述消息未读区域的各个业务通知消息进行排序；第一预设顺序用于表征进入消息未读区域的时间先后顺序。
58.其中，在单队列中插入一个隔板元素，这个隔板元素作为已读消息和未读消息的分割标志位，并且分割标志位的score的值用特殊值0来填充。
59.第一预设顺序即为进入消息未读区域的时间先后顺序。最早进入消息未读区域的未读消息排在消息未读区域的最底端。
60.s104：当消息状态从未读状态变化为已读状态时，通过单队列的分割标志符将处于已读状态的各个业务通知消息分割至消息已读区域，并通过第二预设顺序对消息已读区域的各个业务通知消息进行排序；第二预设顺序用于表征进入消息已读区域的时间先后顺序。
61.其中，第二预设顺序即为进入消息已读区域的时间先后顺序。最早进入消息已读区域的已读消息排在消息已读区域的最底端。
62.有了分割标志位，在操作处于未读状态的业务通知消息变为已读消息的业务通知消息时，只需要把原来的处于未读状态的业务通知消息的score值加上负号，处于已读状态
的业务通知消息就会被分到分割标志位的消息已读区域，无需数据删除和移动，提高效率。
63.具体单队列的数据结构图，可参考图2所示。
64.图2中，单队列的数据结构包括消息已读区域、分割标识符和消息未读区域。key：zset为zset结构的单队列，消息已读区域包括已读消息(处于已读状态的业务通知消息)，消息未读区域包括未读消息(处于未读状态的业务通知消息)。
65.消息已读区域中的已读消息须按照第一预设顺序进行排序，即，将已读消息进入已读区域的时间先后顺序进行排序。
66.消息未读区域中的未读消息须按照第二预设顺序进行排序，即，将未读消息进入未读区域的时间先后顺序进行排序。
67.其中，已读消息包括221132：-timestamp、121133：-timestamp、421135：-timestamp和621134：-timestamp。
68.未读消息包括021132：timestamp、021133：mestamp、021135：timestamp和021134：timestamp；021132：timestamp为最新消息4，021133：mestamp为最新消息3，021135：timestamp为最新消息2，021134：timestamp为最新消息1。
69.当监测到单队列中处于已读状态的业务通知消息(621134：-timestamp)的停留时间，当停留时间大于预设时间时，确定单队列中处于已读状态的业务通知消息为过期消息并删除。
70.其中，预设时间可以是2小时，也可以是1天等，具体预设时间的确定由技术人员根据实际情况进行设置，本技术不做具体限定。
71.消息过期设置在key上，有新的消息写入更新key的过期，具体消息过期，通过新消息的插入触发，最先要删除的过期消息在分割标识符上方的消息已读区域的末位(621134-timestamp所处的位置)，通过预设时间对621134-timestamp的停留时间进行判断是否过期，当621134-timestamp的停留时间大于预设时间时，确定621134-timestamp已过期并删除。
72.当处于未读状态的最新消息1(021134：timestamp)被执行已读操作后，该最新消息1(021134：timestamp)，将021134：timestamp添加负号，即021134：-timestamp，021134：-timestamp被分到分割标志位的消息已读区域。
73.通过以上数据处理方法，可满足金融app消息中心的消息存储和读取，以及push离线消息存储等的业务。
74.可选的，通过预设分布式算法将各个业务通知消息分散存储至各个集群中；预设分布式算法用于提高业务数据的存取性能。
75.通过预设分布式算法对各个业务通知消息进行处理，得到各个业务通知消息对应的业务标识key，基于业务标识key(businesskey)将各个业务通知消息分散存储至各自对应的集群中，并通过路由表返回集群地址。
76.由于现有技术中是采用独立集群存储业务通知消息，在并发高时会产生热点key的问题，对集群产生压力。因此通过预设分布式算法将各个业务通知消息分散存储至各个集群中，降低对集群产生压力。
77.预设分布式算法可以是murmurhash算法，也可以是djbhash算法等，具体预设分布式算法的确定由技术人员根据实际情况进行设置，本技术不做具体限定。本技术的预设分
布式算法优选murmurhash算法。
78.具体通过预设分布式算法将各个业务通知消息分散存储至各自对应的集群中的过程，可结合图3进行说明。图3为集群存储的架构图。
79.图3中，businesskey为业务标识key，通过murmurhash算法对各个业务key进行处理，使各个业务标识key对应的业务通知消息分散存储至各个集群中。
80.集群包括id、运行实例、已用内存、最大内存、创建时间和内存使用率。
81.running表示集群处于运行状态中。
82.在jrm_app_push_center_02的集群中，集群的内存使用率为28.34，集群的id为2582，集群的运行实例为120/120，集群的已用内存为141115mb，集群的最大内存为498000mb，集群的创建时间为2021-01-22。
83.在jrm_app_push_center_01的集群中，集群的内存使用率为28.33，集群的id为2579，集群的运行实例为120/120，集群的已用内存为141102mb，集群的最大内存为498000mb，集群的创建时间为2021-01-22。
84.在jrm_app_push_center_03的集群中，集群的内存使用率为28.2，集群的id为2578，集群的运行实例为120/120，集群的已用内存为141104mb，集群的最大内存为500400mb，集群的创建时间为2021-01-22。
85.在jrm_app_push_center_04的集群中，集群的内存使用率为27.94，集群的id为2580，集群的运行实例为120/120，集群的已用内存为139710mb，集群的最大内存为499980mb，集群的创建时间为2021-01-22。
86.在jrm_app_push_center_05的集群中，集群的内存使用率为27.99，集群的id为2583，集群的运行实例为120/120，集群的已用内存为139389mb，集群的最大内存为498000mb，集群的创建时间为2021-01-22。
87.其中，将各个businesskey对应的业务通知消息分散存储至各个集群中，从而确保集群对业务通知消息的集群存储率的平衡，避免出现集群的内存使用率过高或者过低的情况出现。
88.具体通过预设分布式算法将各个业务通知消息分散存储至各自对应的集群中的过程如下：
89.首先，获取各个业务通知消息对应的各个业务标识key。
90.其中，业务key由用户id的哈希值与业务号构建得到。业务key包括用户的个人信息等。
91.然后，通过预设分布式算法对各个业务标识key进行分布式处理，得到各个业务标识key对应的集群index。
92.其中，通过murmurhash算法对各个业务标识key进行分布式处理，得到各个业务标识key对应的集群index。
93.最后，通过各个业务标识key对应的集群索引index，使各个业务key对应的业务通知消息分散存储至各个集群中。
94.本技术实施例中，通过单队列无锁化的数据结构实现消息的已读状态和未读状态，不会导致消息的标识的数量增加，当未读状态的消息通过单队列的分割标志符变为已读消息的业务通知消息时，只需要把原来的处于未读状态的业务通知消息的分数值加上负
号，处于已读状态的业务通知消息就会被分到分割标志位的消息已读区域，无需数据删除和移动，提高读取消息的效率。
95.可选的，通过分割标志符中的预设值对处于未读状态的业务通知消息的数量进行统计，通过统计结果得到当前时刻处于未读状态的业务通知消息的数量，并确定当前时刻处于未读状态的业务通知消息的数量为最新业务通知消息未读数量。
96.其中，当前时刻处于未读状态的业务通知消息的数量的统计，利用分割标识符的score特值0，就能准确有效的获取最新的消息未读数。
97.本技术实施例中，通过分割标志符中的预设值对处于未读状态的业务通知消息的数量进行统计，通过统计结果得到当前时刻处于未读状态的业务通知消息的数量，并确定当前时刻处于未读状态的业务通知消息的数量为最新业务通知消息未读数量，实现有效的获取最新的消息未读数的目的。
98.可选的，监测单队列中处于已读状态的业务通知消息的停留时间，当停留时间大于预设时间时，确定单队列中处于已读状态的业务通知消息为过期消息并删除。
99.其中，过期时间动态调整，通过过期时间戳来判断是否过期，在往单队列中插入消息时，检测已读消息中最底部的消息，当该最底部的信息停留在队列的时间戳等于过期时间戳时，对该信息进行删除。
100.预设时间的确定由技术人员根据实际情况进行设置，本技术不做具体限定。
101.本技术实施例中，监测单队列中处于已读状态的业务通知消息的停留时间，当所述停留时间大于预设时间时，实现确定单队列中处于已读状态的业务通知消息为过期消息并删除的目的。
102.参考图4所示，为上述s102中涉及到的通过预设分布式算法将各个业务通知消息分散存储至各自对应集群中的过程，主要包括如下步骤：
103.s401：获取各个业务通知消息对应的各个业务标识。
104.s402：通过预设分布式算法对各个业务标识进行分布式处理，得到各个业务标识对应的集群索引。
105.s403：通过各个业务标识对应的集群索引，使各个业务标识对应的业务通知消息分散存储至各自对应的集群中。
106.s401-s403的执行原理与上述通过预设分布式算法将各个业务通知消息分散存储至各自对应的集群中的过程的执行原理一致，可参考，此处不再进行赘述。
107.本技术实施例中，获取各个业务通知消息对应的各个业务key，通过预设分布式算法对各个业务key进行分布式处理，得到各个业务key对应的集群index，使各个业务key对应的业务通知消息分散存储至各个集群中，从而确保集群对业务通知消息的集群存储率的平衡，避免出现集群的内存使用率过高或者过低的情况出现。
108.参考图5所示，为上述s102和s103中涉及到的通过单队列对各个业务通知消息进行无锁化处理的过程，主要包括如下步骤：
109.s501：将各个集群中的业务通知消息存储至单队列中，并确定各个集群中的业务通知消息的消息状态，当消息状态为未读状态时，执行s502，当消息状态从未读状态变化为已读状态时，执行s503。
110.s502：通过单队列的分割标志符将处于未读状态的各个业务通知消息分割至消息
未读区域，并通过第一预设顺序对消息未读区域的各个业务通知消息进行排序。
111.s503：通过单队列的分割标志符将处于已读状态的各个业务通知消息分割至消息已读区域，并通过第二预设顺序对消息已读区域的各个业务通知消息进行排序。
112.s501-s503的执行原理与上述s102和s103中涉及到的通过单队列对各个业务通知消息进行无锁化处理的执行原理一致，可参考，此处不再进行赘述。
113.本技术实施例中，将各个集群中的业务通知消息存储至单队列中，并确定各个集群中的业务通知消息的消息状态，通过单队列的分割标志符对各个业务通知消息分割至消息状态对应的区域并排序的目的。
114.基于上述实施例图1公开的一种数据处理方法，本发明实施例还对应公开了一种数据处理系统，如图6所示，该数据处理系统主要包括获取单元601、确定单元602、第一分割排序单元603和第二分割排序单元604。
115.获取单元601，用于获取各个业务通知消息；业务通知消息用于表征业务类型的通知消息。
116.确定单元602，用于将各个业务通知消息存储至单队列中，并确定各个业务通知消息的消息状态；消息状态至少包括已读状态和未读状态。
117.第一分割排序单元603，用于当消息状态为未读状态时，通过单队列的分割标志符将处于未读状态的各个业务通知消息分割至消息未读区域，并通过第一预设顺序对消息未读区域的各个业务通知消息进行排序；第一预设顺序用于表征进入消息未读区域的时间先后顺序。
118.第二分割排序单元604，用于当消息状态从未读状态变化为已读状态时，通过单队列的分割标志符将处于已读状态的各个业务通知消息分割至消息已读区域，并通过第二预设顺序对消息已读区域的各个业务通知消息进行排序；第二预设顺序用于表征进入消息已读区域的时间先后顺序。
119.进一步的，还包括存储单元。
120.存储单元，用于通过预设分布式算法将各个业务通知消息分散存储至各个集群中；预设分布式算法用于提高业务数据的存取性能。
121.进一步的，存储单元包括获取模块、处理模块和存储模块。
122.获取模块，用于获取各个业务通知消息对应的各个业务标识。
123.处理模块，用于通过预设分布式算法对各个业务标识进行分布式处理，得到各个业务标识对应的集群索引。
124.存储模块，用于通过各个业务标识对应的集群索引，使各个业务标识对应的业务通知消息分散存储至各自对应的集群中。
125.进一步的，数据处理系统还包括生成单元。
126.生成单元，用于通过路由表生成各个集群的集群地址。
127.进一步的，数据处理系统还包括统计单元和第一确定单元。
128.统计单元，用于通过分割标志符中的预设值对处于未读状态的业务通知消息的数量进行统计。
129.第一确定单元，用于通过统计结果得到当前时刻处于未读状态的业务通知消息的数量，并确定当前时刻处于未读状态的业务通知消息的数量为最新业务通知消息未读数
量。
130.进一步的，数据处理系统还包括监测单元和第二确定单元。
131.监测单元，用于监测单队列中处于已读状态的业务通知消息的停留时间。
132.第二确定单元，用于当停留时间大于预设时间时，确定单队列中处于已读状态的业务通知消息为过期消息并删除。
133.本技术实施例中，通过单队列无锁化的数据结构实现消息的已读状态和未读状态，不会导致消息的标识的数量增加，当未读状态的消息通过单队列的分割标志符变为已读消息的业务通知消息时，只需要把原来的处于未读状态的业务通知消息的分数值加上负号，处于已读状态的业务通知消息就会被分到分割标志位的消息已读区域，无需数据删除和移动，提高读取消息的效率。
134.本技术实施例还提供了一种存储介质，存储介质包括存储的指令，其中，在指令运行时控制存储介质所在的设备执行上述数据处理方法。
135.本技术实施例还提供了一种电子设备，其结构示意图如图7所示，具体包括存储器701，以及一个或者一个以上的指令702，其中一个或者一个以上指令702存储于存储器701中，且经配置以由一个或者一个以上处理器703执行所述一个或者一个以上指令702执行上述数据处理方法。
136.上述各个实施例的具体实施过程及其衍生方式，均在本技术的保护范围之内。
137.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
138.专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
139.对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
140.以上所述仅是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。