一种集群式服务系统、方法、介质和计算设备与流程

1.本公开涉及计算机技术领域，更具体地，本公开涉及一种集群式服务系统、方法、介质和计算设备。


背景技术：

2.本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
3.商品的销量预测对于生产排期、采购补货、仓间调拨、活动运营等众多场景都起到了非常重要的作用，做好销量预测带来的是全链路的优化。并且基于电商自身特点，相较于传统实体零售业，电商场景下的用户数量更加庞大，积累的数据也更为丰富。而海量数据一方面给销量预测准确率提升提供了更多的机会，另一方面也对预测系统的性能带来了更大的挑战。因此，如何提升预测性能成为亟待解决的技术问题。


技术实现要素：

4.本公开提供了一种集群式服务系统、方法、介质和计算设备，至少能提高销量预测效率。
5.本公开实施例的第一方面提供一种集群式服务系统，包括入口节点、n个服务节点、缓存层和数据层，n为大于1的整数；其中，
6.所述入口节点，用于将销量预测任务分成m个子任务，并将所述m个子任务分发至所述n个服务节点中的m个服务节点；根据所述m个服务节点返回的任务执行结果，确定所述销量预测任务的销量预测结果；m为大于1的整数，m小于或等于n；
7.所述m个服务节点，用于执行所述入口节点为其分配的子任务，并向所述入口节点返回所述任务执行结果；
8.所述缓存层，用于缓存所述m个服务节点之间实现信息协同的元数据；
9.所述数据层，用于存储所述m个服务节点预测时所需的基础数据。
10.在本公开的一个实施例中，所述销量预测任务包括对k件商品销量的预测任务；k为大于1的整数；其中，所述入口节点，还用于：
11.按照所述k件商品分别对应的商品标识，将所述销量预测任务分成m个子任务，不同子任务中包括的商品标识不同；或者
12.根据所述k件商品分别对应的商品类目，将所述k件商品分成m个任务组；其中，每个任务组对应一个子任务。
13.在本公开的一个实施例中，所述元数据包括：表征服务节点是否处于空闲状态的第一状态数据；其中，所述入口节点，还用于：从所述缓存层获取所述n个服务节点中每个服务节点的第一状态数据；基于所述第一状态数据选择当前处于空闲状态的m个服务节点。
14.在本公开的一个实施例中，所述入口节点，还用于：将所述m个子任务按顺序分发至所述m个服务节点中的每个服务节点；或者
15.根据所述m个服务节点中每个服务节点支持的预测类型，为所述m个服务节点中的每个服务节点分发与其预测类型相适应的子任务。
16.在本公开的一个实施例中，所述元数据包括表征服务节点是否占用全局锁的第二状态数据，其中，占用所述全局锁的服务节点能对所述缓存层的当前数据进行更改操作；
17.所述m个服务节点中的各个服务节点，还用于：在占用所述全局锁的情况下，基于所述第二状态数据对所述缓存层存储的第一状态数据进行更改；或者
18.在占用所述全局锁的情况下，基于所述第二状态数据对所述缓存层存储的销量数据进行更新。
19.在本公开的一个实施例中，所述缓存层还用于存储多个预设数据索引；所述m个服务节点，还用于：基于接收到的子任务确定待拉取的数据清单，其中，所述数据清单包括商品标识以及所述商品标识对应的字段范围和时间范围；基于所述多个预设数据索引从所述缓存层查询所述数据清单中能完成预测的第一类商品的标识，以及所述第一类商品的标识所对应的字段范围值和时间范围值；基于所述第一类商品的标识所对应的所述字段范围值和所述时间范围值，从所述数据层拉取所述第一类商品对应的预测所需商品销量数据。
20.在本公开的一个实施例中，所述缓存层还用于存储商品标识与类目标识的对应关系；所述m个服务节点，还用于：统计预测时需要用到类目的p个第二类商品；p为大于等于1的整数；从所述缓存层拉取所述p个第二类商品的类目标识；对所述p个第二类商品的类目标识进行聚合，得到q个目标类目标识；q为大于等于1的整数，q小于或等于p；从所述缓存层拉取所述q个目标类目标识对应的类目数据；基于所述q个目标类目标识对应的类目数据，从所述数据层拉取所述q个目标类目标识对应的预测所需类目销量数据。
21.在本公开的一个实施例中，服务节点包括服务层和模型层，所述模型层包括多个预测模型；其中，所述服务层，用于接收所述入口节点发送的子任务，并向所述模型层中的目标预测模型发送所述子任务；接收所述目标预测模型返回的任务执行结果；向所述入口节点返回经封装处理后的所述任务执行结果；所述模型层，能与所述数据层和所述缓存层通信，所述模型层中的所述目标预测模型用于：获取执行所述子任务所需的目标数据；基于所述目标数据执行预测，得到任务执行结果。
22.在本公开的一个实施例中，所述入口节点，还用于：接收基于超文本传输协议(hyper text transfer protocol，http)发送的所述销量预测任务；基于所述http返回所述销量预测任务的所述销量预测结果。
23.在本公开的一个实施例中，所述入口节点的基础架构与所述n个服务节点的基础架构相同；所述缓存层的基础架构与所述数据层的基础架构不同。
24.在本公开的一个实施例中，所述缓存层以键值对的形式存储数据。
25.本公开实施例的第二方面提供一种销量预测方法，应用于集群式服务系统，所述方法包括：
26.将销量预测任务分成m个子任务，并将所述m个子任务分发至m个服务节点；m为大于1的整数；
27.根据所述m个服务节点返回的任务执行结果，确定所述销量预测任务的销量预测结果；其中，所述集群式服务系统，包括入口节点、n个服务节点、缓存层和数据层，n为大于1的整数，m小于或等于n；所述缓存层，用于缓存所述m个服务节点之间实现信息协同的元数
据；所述数据层，用于存储所述m个服务节点预测时所需的基础数据。
28.在本公开的一个实施例中，其中，所述销量预测任务包括对k件商品销量的预测任务；k为大于1的整数；
29.其中，所述将销量预测任务分成m个子任务，包括：
30.按照所述k件商品分别对应的商品标识，将所述销量预测任务分成m个子任务，不同子任务中包括的商品标识不同；
31.或者
32.根据所述k件商品分别对应的商品类目，将所述k件商品分成m个任务组；其中，每个任务组对应一个子任务。
33.在本公开的一个实施例中，所述元数据包括：
34.表征服务节点是否处于空闲状态的第一状态数据；
35.其中，所述方法还包括：
36.从所述缓存层获取所述n个服务节点中每个服务节点的第一状态数据；
37.基于所述第一状态数据选择当前处于空闲状态的m个服务节点。
38.在本公开的一个实施例中，所述将所述m个子任务分发至m个服务节点，包括：
39.将所述m个子任务按顺序分发至所述m个服务节点中的每个服务节点；
40.或者
41.根据所述m个服务节点中每个服务节点支持的预测类型，为所述m个服务节点中的每个服务节点分发与其预测类型相适应的子任务。
42.在本公开的一个实施例中，所述元数据包括表征服务节点是否占用全局锁的第二状态数据，其中，占用所述全局锁的服务节点能对所述缓存层的当前数据进行更改操作；其中，所述方法还包括：
43.所述m个服务节点中占用所述全局锁的服务节点，基于所述第二状态数据对所述缓存层存储的第一状态数据进行更改；
44.或者
45.所述m个服务节点中占用所述全局锁的服务节点，基于所述第二状态数据对所述缓存层存储的销量数据进行更新。
46.在本公开的一个实施例中，所述缓存层还用于存储多个预设数据索引；所述方法还包括：
47.基于接收到的子任务确定待拉取的数据清单，其中，所述数据清单包括商品标识以及所述商品标识对应的字段范围和时间范围；
48.基于所述多个预设数据索引从所述缓存层查询所述数据清单中能完成预测的第一类商品的标识，以及所述第一类商品的标识所对应的字段范围值和时间范围值；
49.基于所述第一类商品的标识所对应的所述字段范围值和所述时间范围值，从所述数据层拉取所述第一类商品对应的预测所需商品销量数据。
50.在本公开的一个实施例中，所述缓存层还用于存储商品标识与类目标识的对应关系；所述方法还包括：
51.统计预测时需要用到类目的p个第二类商品；p为大于等于1的整数；
52.从所述缓存层拉取所述p个第二类商品的类目标识；
53.对所述p个第二类商品的类目标识进行聚合，得到q个目标类目标识；q为大于等于1的整数，q小于或等于p；
54.从所述缓存层拉取所述q个目标类目标识对应的类目数据；
55.基于所述q个目标类目标识对应的类目数据，从所述数据层拉取所述q个目标类目标识对应的预测所需类目销量数据。
56.在本公开的一个实施例中，所述方法还包括：
57.接收基于超文本传输协议(http)发送的所述销量预测任务；
58.基于所述http返回所述销量预测任务的所述销量预测结果。
59.本公开实施例的第三方面提供一种介质，其存储有计算机程序，该程序被处理器执行时实现如前述实施例的方法。
60.本公开实施例的第四方面提供一种计算设备，包括：
61.一个或多个处理器；
62.存储装置，用于存储一个或多个程序；
63.当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如前述实施例的方法。
64.根据本公开实施方式的集群式服务系统、方法、介质和计算设备，将销量预测任务分成m个子任务，并将m个子任务分发至m个服务节点；根据m个服务节点返回的任务执行结果，确定所述销量预测任务的销量预测结果。如此，充分利用多机或多个服务节点的计算资源，将单机/单节点任务迁移到多机系统或多个服务节点上，可用计算资源成倍增加，计算耗时成倍减少，不仅可以在更短时间内完成更多更庞大的计算任务，还能提升销量的预测效率。
附图说明
65.通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：
66.图1为根据本公开一实施方式的集群式服务系统的架构图；
67.图2为根据本公开一实施方式的基于python的elasticsearch库的整体实现链路示意图；
68.图3为根据本公开一实施方式的单个服务节点与缓存层和数据层之间的关系示意图；
69.图4为根据本公开一实施方式的销量预测方法流程图；
70.图5为根据本公开一实施方式的介质示意图；
71.图6为根据本公开一实施方式的计算设备结构示意图；
72.在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
73.下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何
方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
74.本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
75.根据本公开的实施方式，提出了一种集群式服务系统、方法、介质和计算设备。
76.在本文中，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。
77.下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。
78.发明概述
79.本申请人发现，销量预测业务场景普遍采用单机离线计算，即所有数据汇总到单台计算机节点上，并由这台节点完成全部的模型计算工作，经过一段时间的计算之后，输出总体的计算结果。这种计算方式至少具有以下缺点：
80.1、计算时间长：由于只用到单台计算机的计算资源，当计算量大(如商品数量较多或时间跨度较大等情况)时，往往需要数小时的计算时间才能得到结果，时效性很差。
81.2、数据量有限：受限于单机的计算资源，单机能处理的数据量是非常有限的，特别是在电商场景中，数据量往往非常巨大，单机往往难以处理。
82.3、资源瓶颈影响准确率：计算资源的缺少还会导致模型的复杂度难以提升，特别是以各种机器学习算法为代表的复杂模型，提升预测准确率的同时计算量也指数级上升，在大数据量时单机更加难以胜任，因此单节点下的预测准确率瓶颈也是十分明显的。
83.4、可用性差：相关技术中，预测是以“离线计算流程”的形式存在的，没有一套框架来实现预测的服务化，不同模型之间也缺少统一的标准，内外部使用的可用性较差。
84.有鉴于此，本公开提供一种集群式服务系统、方法、介质和计算设备。该集群式服务系统，包括入口节点、n个服务节点、缓存层和数据层，n为大于1的整数；其中，
85.所述入口节点，用于将销量预测任务分成m个子任务，并将所述m个子任务分发至所述n个服务节点中的m个服务节点；根据所述m个服务节点返回的任务执行结果，确定所述销量预测任务的销量预测结果；m为大于1的整数，m小于或等于n；
86.所述m个服务节点，用于执行所述入口节点为其分配的子任务，并向所述入口节点返回所述任务执行结果；
87.所述缓存层，用于缓存所述m个服务节点之间实现信息协同的元数据；
88.所述数据层，用于存储所述m个服务节点预测时所需的基础数据。
89.如此，本公开给出了一套用于销量预测的集群式服务系统，将单机/单节点的计算迁移到多机系统或多个服务节点上，能获取更多的计算资源，从根本上解决相关技术方案存在的各种问题。
90.在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。
91.示例性系统
92.本公开提供了一种集群式服务系统，该集群式服务系统可以应用于服务器，使其至少可以对接收到的销量预测请求进行处理。参考图1所示，示出了集群式服务系统的架构
示意图，如图1所示，集群式服务系统100可以包括入口节点110、n个服务节点120、缓存层130和数据层140，其中，n为大于1的整数；
93.所述入口节点110，用于将销量预测任务分成m个子任务，并将所述m个子任务分发至所述n个服务节点120中的m个服务节点120；根据m个服务节点120返回的任务执行结果，确定所述销量预测任务的销量预测结果；m为大于1的整数，m小于或等于n；
94.所述m个服务节点120，用于执行所述入口节点110为其分配的子任务，并向所述入口节点110返回所述任务执行结果；
95.所述缓存层130，用于缓存m个服务节点120之间实现信息协同的元数据；
96.所述数据层140，用于存储m个服务节点120预测时所需的基础数据。
97.本实施例中，入口节点110可以是服务器或服务器侧的设备。服务节点120可以是服务器或服务器侧的设备。服务器包括但不限于云服务器、普通服务器等服务器。缓存层130可以是用于存储数据的集群。数据层140可以是用于存储数据的集群。
98.本实施例中，入口节点110的基础架构与服务节点120的基础架构可以相同。示例性地，将入口节点110的基础架构与服务节点120的基础架构均记为第一架构，该第一架构可以是tornado。当然，第一架构可根据实际情况进行设定或调整。
99.本实施例中，缓存层130的基础架构与数据层140的基础架构可以不同。示例性地，将缓存层130的基础架构记为第二架构，将数据层140的基础架构记为第三架构，该第二架构可以是redis集群，该第三架构可以是elasticsearch集群。当然，第二架构和第三架构均可根据实际情况进行设定或调整。
100.根据本实施例所述集群式服务系统，充分利用多机或多个服务节点的计算资源，将单机/单节点任务迁移到多机系统或多个服务节点上，使得可用的计算资源成倍增加，计算耗时成倍减少，不仅可以在更短时间内完成更多、更庞大的计算任务，还能提升销量的预测效率，大大提升预测性能。
101.在一些实施例中，所述销量预测任务包括对k件商品销量的预测任务；k为大于1的整数。
102.其中，本实施例不对商品的种类进行限定。示例性地，k件商品可以是同类但不同型号的商品；比如，k件商品均属于电子产品类，但是电子产品型号不同。又示例性地，k件商品是不同类的商品；比如，k件商品中包括服装、电子产品、书籍、健身器材、床上用品等商品。
103.其中，所述销量预测任务还可包括k件商品分别对应的预测时间范围、采用的模型参数等信息。示例性地，预测时间范围可根据实际需求进行设定。如预测时间范围具体到某一个月、或某一周、或某一天、或某一小于24小时的时间段、或是某一个时间点。这里，模型参数是指期望采用的服务节点中的预测模型的模型参数，单个服务节点可包括多个预测模型，每个预测模型的模型参数可以不同。当然，单个服务节点也可包括一个预测模型，不同服务节点包括的预测模型的模型参数可以不同。实际应用中，销量预测任务还可根据用户需求包含更多的控制信息，本实施例不做穷举。
104.基于图1所示集群式服务系统，在一些实施例中，所述入口节点110，还用于：
105.按照所述k件商品分别对应的商品标识，将所述销量预测任务分成m个子任务，不同子任务中包括的商品标识不同。
106.其中，m小于或等于k。
107.示例性地，k件商品对应的商品标识各不相同，将销量预测任务分成k个子任务。
108.又示例性地，k件商品中有2件商品的商品标识相同，将销量预测任务分成m＝k
‑
1个子任务。
109.如此，将包括k件商品的销量预测任务按照商品标识分成m个子任务，进而将m个子任务分配给m个服务节点，相对于单个服务节点执行销量预测任务而言，能充分利用多机或多个服务节点的计算资源，把单机/单节点任务迁移到多机系统或多个服务节点上，可用计算资源成倍增加，计算耗时成倍减少，可以在更短时间内完成更多、更庞大的计算任务。
110.基于图1所示集群式服务系统，在一些实施例中，所述入口节点110，还用于：
111.根据所述k件商品分别对应的商品类目，将所述k件商品分成m个任务组；其中，每个任务组对应一个子任务。
112.其中，类目可以理解为分类，分类是为了更好的管理商品。示例性地，类目包括但不限于手机、电脑、家居、母婴、视频、图书等类目。类目的具体划分标准可根据用户需求进行设定或调整。
113.进一步地，类目可分为一级类目、二级类目、三级类目、
…
、x级类目等多级类目，x为大于3的整数。示例性地，手机为一级类目，手机配件为二级类目，充电器为三级类目。又示例性地，图书为一级类目，文学为二级类目，小说为三级类目。
114.如此，按类目级别划分任务组，使得每个任务组中的子任务都属于同一类目级别，进而有助于为单个服务节点分配同一类目级别的子任务，提高子任务的计算效率。
115.在一些实施例中，所述元数据包括：表征服务节点是否处于空闲状态的第一状态数据；
116.其中，所述入口节点110，还用于：
117.从所述缓存层130获取n个服务节点120中每个服务节点120的第一状态数据；
118.基于所述第一状态数据选择当前处于空闲状态的m个服务节点120。
119.其中，第一状态数据用于表征服务节点120是否处于空闲状态。
120.其中，第一状态数据还可用于表征服务节点120的任务执行状态。这里，任务执行状态包括执行进度、预计完成时间等信息。
121.如此，能够在多个服务节点之间实现信息的协同，从而有助于快速完成销量预测任务。
122.在一些实施例中，所述入口节点110，还用于：
123.将m个子任务按顺序分发至m个服务节点120中的每个服务节点120。
124.示例性地，将第1个子任务分发至m个服务节点中的第1个服务节点，将第2个子任务分发至m个服务节点中的第2个服务节点，将第3个子任务分发至m个服务节点中的第3个服务节点，
…
，将第m个子任务分发至m个服务节点中的第m个服务节点。
125.如此，能够实现对各个子任务的快速分配，从而有助于提高销量预测效率。
126.在一些实施例中，所述入口节点110，还用于：
127.根据m个服务节点120中每个服务节点120支持的预测类型，为m个服务节点120中的每个服务节点120分发与其预测类型相适应的子任务。
128.示例性地，若第1个子任务属于第1预测类型的任务，第2个子任务属于第2预测类
型的任务，第3个子任务属于第3预测类型的任务；m个服务节点中第1个服务节点支持第2预测类型，m个服务节点中第2个服务节点支持第3预测类型，m个服务节点中第3个服务节点支持第1预测类型，那么，将第1个子任务分配给m个服务节点中第3个服务节点，将第2个子任务分配给m个服务节点中第1个服务节点，将第3个子任务分配给m个服务节点中第2个服务节点。
129.如此，通过为每个服务节点分配其支持的预测类型的相关子任务，能够充分发挥每个服务节点的计算性能，从而有助于销量预测任务的快速完成，节省预测时间，提高预测效率。
130.在一些实施例中，所述元数据包括表征服务节点是否占用全局锁的第二状态数据，其中，占用所述全局锁的服务节点能对所述缓存层的当前数据进行更改操作。
131.示例性地，为m个服务节点分配一个全局锁，在同一时间点只允许一个服务节点占用该全局锁，而占用该全局锁的服务节点能对缓存层的当前数据进行更改操作。
132.在一些实施例中，m个服务节点120中的各个服务节点120，还用于：
133.在占用所述全局锁的情况下，基于所述第二状态数据对所述缓存层130存储的所述第一状态数据进行更改。
134.其中，该更改操作包括但不限于增加操作、删除操作、修改操作、查询操作。
135.示例性地，m个服务节点中的第3个服务节点占用全局锁，那么，该第3个服务节点能对缓存层的当前数据进行更改操作，其他未占用全局锁的服务节点不能对缓存层的当前数据进行更改操作。
136.如此，通过全局锁可以防止因各个服务节点同时向缓存层更改数据而导致数据异常的情况发生，保证集群式服务系统中各服务节点的数据一致性，从而使缓存层能够为实现系统中多服务节点之间的协同与数据同步提供技术支撑。
137.在一些实施例中，m个服务节点120中的各个服务节点120，还用于：
138.在占用所述全局锁的情况下，基于所述第二状态数据对所述缓存层130存储的销量数据进行更新。
139.示例性地，m个服务节点中的第2个服务节点占用全局锁，那么，该第2个服务节点能基于所述第二状态数据对所述缓存层存储的销量数据进行更新。
140.如此，通过全局锁可以防止因各个服务节点同时向缓存层写入数据而导致数据异常的情况发生，保证集群式服务系统中各服务节点的数据一致性，从而使缓存层能够为实现系统中多服务节点之间的协同与数据同步提供技术支撑。
141.缓存层130负责一些小规模热数据的缓存，主要实现两种功能：
142.1)存储一些基本的数据索引，一方面可以优化数据的查询性能，同时能保证多节点间的数据一致性。
143.2)用于在多个服务节点之间实现信息的协同，存储一些节点状态、任务状态等元数据信息；
144.基于缓存层的功能需求，需要支持小规模数据的增删改查，并且有较高的性能要求，可选择redis集群作为缓存层的基础框架。
145.下面，对缓存层进行详细说明。
146.缓存层基于redis框架实现，所有的缓存数据都是以key
‑
value的形式存储在内存
中，具有非常优秀的读写性能。缓存层主要存储两部分数据：预设数据索引与元数据。
147.预设数据索引如下表1所示：
148.索引名功能field
‑
unit索引根据字段名查询包含该字段下可用的unit列表field
‑
time索引根据字段名查询包含该字段下可用的日期范围索引unit
‑
field索引根据unit列表，查询可用字段名的索引time
‑
field索引根据时间范围，查询可用字段名的索引
149.表1
150.需要说明的是，预设数据索引可以根据设计需求或用户需求进行设定或调整。
151.基于上述预设数据索引，服务节点每次执行查询动作时，先与缓存层进行交互，以减少不必要的全表搜索。
152.例如，当需要批量查询100件商品的历史销量时，可以先从缓存层确认存在有历史销量的商品，以及每件商品历史销量数据可用的时间范围(这一步查询因为是在缓存层中执行的，速度会很快)，然后再根据这些可用范围，来生成"可以精确匹配"的elasticsearch查询语句，可以减少不必要的全表搜索，大大提高在elasticsearch中检索数据的效率。同时，缓存层保存了唯一的一份索引，可以保障不同节点之间的数据一致性。
153.元数据主要包括表征各服务节点是否处于空闲状态的第一状态数据以及表征服务节点是否占用全局锁的第二状态数据。
154.第一状态数据：每个服务节点需要定时写入当前的健康状态，其中，健康状态是指节点当前是否可用，可包括：节点ip、节点端口、上报时间戳三个字段。入口节点等外部调用方可以通过各个节点的健康状态来获取系统当前可用的节点情况。示例性地，入口节点根据各个服务节点的健康状态统计系统中当前可用的节点。
155.第二状态数据：基于redis分布式锁算法，可以跨节点实现类似线程锁的功能。凭借全局redis锁，可以保证多服务节点的数据一致性。
156.基于销量预测业务的特点，服务节点的输入数据具有以下特点：
157.1)时序性
158.销量预测业务需要解决的问题是“预测未来一段时间或某个时间点的销量”，具有明确的时间属性，因此相关预测模型的输入数据往往也都是各种时序数据，例如历史数据中每天的销量、流量等。其中，流量是指在一定时间内打开网站地址的人气访问量。
159.2)时效性
160.不同于传统零售场景，电商网站的商品迭代更快，促销活动更多，网站策略调整频繁，自身发展也更快，种种原因导致电商场景下的商品销量波动很大。因此要预测好电商销量，历史数据是具有时效性的——近期数据具有更高价值，越是久远的数据，参考性越弱。
161.3)单元性
162.预测销量除了时间以外，另一个核心维度就是商品。虽然商品数量众多，但是每件商品可用的历史数据字段是一致的，同一个预测模型对k件商品的计算过程，可以抽象为对k份“结构相同，数值不同”数据分别做了k次重复的计算，最终产生了k份结果。可以把每一次“输入
‑
计算
‑
输出”过程视为一个完整的计算单元，计算单元之间往往互不干扰、互不依赖，可以独立的进行。
163.综上所述，使用预测数据时，会具有以下特点：
164.1)基于数据的时序性和时效性，用到的数据往往会有明确的时间范围。
165.2)基于单元性，计算时只会用到需要的商品范围内的数据。
166.因此，数据层至少需要支持按时间、按商品id的数据拉取。
167.数据层主要用于存储销量预测用到的各种基础数据，根据销量预测业务特点，一条数据的描述可以抽象成以下几个维度中的一种或几种：
168.1)单元：电商数据很多都是围绕商品的，每个商品都会具有相同的一批数据字段，因此可以抽象出“单元”的概念来描述数据的归属。
169.2)时间：很多数据都是时间序列(如每天的销量)，因此数据需要有时间属性来标识对应时间点。
170.3)版本：同一份数据，还可能存在多种不同版本(例如商品的活动计划，不同时期会有不同的版本，实际使用时可能多个版本都会用到)
171.4)字段名：数据的唯一标识，用来描述不同的数据(如区分数据是销量、流量、折扣等)
172.5)数据值：具体的数据的值，只要可以序列化与反序列化的数据类型都可以作为数据的值。
173.下面举例说明：
[0174][0175]
表2
[0176]
其中，表中“sales”表示销量，“act_level”表示活动等级，“holiday”表示节日，“sku_1001”表示单元编码，“global”表示全局配置。
[0177]
可以理解，上述表格中内容仅仅是示意性的，实际应用中，可根据设计需求或用户需求进行设定或调整。
[0178]
数据层140用于存储预测时需要用到的各种基础输入数据(如各商品的历史销量、折扣、流量等信息)，支持较大规模数据的增删改查，并且考虑到电商销量预测场景特点，会尤其侧重“查”操作，因此可选择elasticsearch集群作为数据层的基础框架。基于上述数据模型抽象，考虑到实际使用过程中的查询性能，建立的索引如
[0179]
表3所示：
[0180]
[0181][0182]
表3
[0183]
可以理解，上述索引名和功能都是示意性的，这里不做穷举。实际应用中，索引可根据用户需求或设计需求增加或减少。
[0184]
在elasticsearch集群建立好索引之后，需要在python中封装es(elasticsearch的简称)操作类，可以基于python的elasticsearch库实现，基于python的elasticsearch库的整体实现链路如图2所示，实现以下核心功能：
[0185]
1)数据序列化：python内置的pickle可以实现大部分对象的序列化与反序列化，但是原生的pickle序列化结果中可能包含特殊字符串(如"\t"、","等)。这些特殊字符串在用于es数据上传时，会产生兼容性的问题。因此在pickle序列化的基础上，需要再进行一次base64编码(即编码到只包含a
‑
z、a
‑
z、0
‑
9、+、/共64个字符)，这样序列化的结果就具有了较好的传输兼容性。基于这一方法，可以实现大部分python对象在es的跨平台跨语言读写。
[0186]
2)数据读写模块：基于数据类型的定义，把python内的数据对象翻译成es所支持的文档形式，再进行相应的读写操作(如更新、插入等)。
[0187]
应理解，图2所示的实现链路图为一种可选的具体实现方式，本领域技术人员可以基于图2的例子进行各种显而易见的变化和/或替换，得到的技术方案仍属于本公开实施例的公开范围。
[0188]
在一些实施例中，m个服务节点120，还用于：
[0189]
基于接收到的子任务确定待拉取的数据清单，其中，所述数据清单包括商品标识以及所述商品标识对应的字段范围和时间范围；
[0190]
基于所述多个预设数据索引从所述缓存层查询所述数据清单中能完成预测的第一类商品的标识，以及所述第一类商品的标识所对应的字段范围值和时间范围值；
[0191]
基于所述第一类商品的标识所对应的所述字段范围值和所述时间范围值，从所述数据层拉取所述第一类商品对应的预测所需商品销量数据。
[0192]
如此，各服务节点根据缓存索引中查到的数据可用情况，向数据层拉取需要的数据。因为已经经过了缓存层过滤，一方面减少了无效的查询，另一方面缓存层提供了索引信息，可以更快速的定位到需要的数据。
[0193]
在一些实施例中，所述缓存层130还用于存储商品标识与类目标识的对应关系；
[0194]
m个服务节点120，还用于：
[0195]
统计预测时需要用到类目的p个第二类商品；p为大于等于1的整数；
[0196]
从所述缓存层拉取所述p个第二类商品的类目标识；
[0197]
对所述p个第二类商品的类目标识进行聚合，得到q个目标类目标识；q为大于等于1的整数，q小于或等于p；
[0198]
从所述缓存层拉取所述q个目标类目标识对应的类目数据；
[0199]
基于所述q个目标类目标识对应的类目数据，从所述数据层拉取所述q个目标类目
标识对应的预测所需类目销量数据。
[0200]
如此，各服务节点根据缓存索引中查到的数据可用情况，向数据层拉取需要的数据，能够减少拉取类目销量数据的次数，节省单独拉取类目销量数据所耗费时间，从而有助于提升预测效率。
[0201]
在一些实施例中，服务节点120包括服务层1201和模型层1202，所述模型层1202包括多个预测模型；其中，
[0202]
所述服务层1201，用于接收所述入口节点110发送的子任务，并向所述模型层1202中的目标预测模型发送所述子任务；接收所述目标预测模型返回的任务执行结果；向所述入口节点110返回经封装处理后的所述任务执行结果；
[0203]
所述模型层1202，能与所述数据层140和所述缓存层130通信，所述模型层1202中的所述目标预测模型用于：获取执行所述子任务所需的目标数据；基于所述目标数据执行预测，得到任务执行结果。
[0204]
图3示出了单个服务节点与缓存层和数据层之间的关系示意图，如图3所示，作为完成销量预测计算的承载实体的服务节点，包括服务层1201和模型层1202两部分，服务层1201实现了http服务的各种基本功能，如请求的接收、计算结果的输出、健康状态上报等，基于tornado实现。服务层1201会监听节点上指定的端口，来接受各种请求。接收到请求后，将请求参数透传给模型层1202。模型层1202负责完成各种解析、计算工作，得到相应的计算结果上报到服务层1201，再由服务层1201封装并进行返回。模型层1202实现了各种具体的销量预测计算逻辑。对于不同的计算模型，模型层1202定义了统一的输入输出格式，只要能对输入输出格式进行兼容即可。在实现上，不同模型是"可插拔"的，模型可以任意增减而不影响系统的运行。模型层1202可以直接与数据层140、缓存层130进行通信，在执行预测计算之前，需要获取计算需要用到的数据。而基于前面数据层的定义以及销量预测服务的特点，模型层1202拉取数据时需要提供以下信息：商品id列表、字段列表、时间范围。
[0205]
如此，上述服务节点的结构设计使得更多复杂模型的使用成为了可能，进而支持的特征数量更多，从而能大大提升预测性能。
[0206]
在一些实施例中，所述入口节点110，还用于：
[0207]
接收基于http发送的销量预测任务；
[0208]
基于所述http返回所述销量预测任务的销量预测结果。
[0209]
实际应用中，入口节点110对外提供统一的服务接口，接收预测任务的输入，并对其拆解和分发，可以视为是一个简单的节点，这个节点的模型层可以只包含一个模型，该模型负责基于用户终端的输入，拆解成具体的子任务，然后分发到各个服务节点上完成计算，收集各个服务节点的计算结果，最后封装到一起返回给用户终端。入口节点同样可以基于tornado进行实现。
[0210]
如此，销量预测结果由入口节点根据接收到的各个服务节点返回的任务执行结果确定出后返回用户终端，即不做落地，将销量预测结果直接返回用户终端而不在入口节点做存储，既能减少对入口节点内存资源的占用，又能提高数据的安全性。
[0211]
在一些实施例中，所述缓存层130以键值对(key
‑
value)的形式存储数据。其中，key表示索引，value表示该索引对应的值。
[0212]
如此，所有的数据都拉平到同一个key
‑
value层级上进行存储，能够提升缓存层的
读取性能，进而有助于提升预测速率。
[0213]
综上，本公开提出的集群式的销量预测服务系统，至少具有以下优势：
[0214]
1、充分利用多机或多个服务节点的计算资源，把由单机或单个服务节点负责的计算任务迁移到多机系统或多个服务节点上，可用的计算资源成倍增加，计算耗时成倍减少，可以在更短时间内完成更多更庞大的计算任务；
[0215]
2、提升预测效率，使得更多复杂模型的使用成为了可能，由于每个模型支持的特征可能不同，使系统支持的模型特征数量更多，进而提升预测准确率；
[0216]
3、电商网站、app后台，往往都存在众多复杂的、实时性的线上系统，而销量预测的效率提升与服务化，能让预测数据更好的与其他线上系统联动，接入更多的线上决策流程，创造更多价值。
[0217]
示例性方法
[0218]
在介绍了本公开示例性实施方式的系统之后，接下来，对本公开示例性实施方式的方法进行说明。
[0219]
本公开提供了应用于上文所述的集群式服务系统的销量预测方法，如图4所示，包括：
[0220]
s401：将销量预测任务分成m个子任务，并将所述m个子任务分发至m个服务节点；m为大于1的整数；
[0221]
s402：根据所述m个服务节点返回的任务执行结果，确定所述销量预测任务的销量预测结果。
[0222]
在s401中，所述销量预测任务可以是对多件商品的销量预测任务。
[0223]
在s402中，所述销量预测结果可以包括各个商品在预设时间段内的销量预测值。
[0224]
根据本实施例所述方法，充分利用多个服务节点的计算资源，将由单机或单个服务节点负责的计算任务迁移到多机系统或多个服务节点上，可用的计算资源成倍增加，计算耗时成倍减少，不仅可以在更短时间内完成更多更庞大的计算任务，还能提升销量的预测效率。
[0225]
在一些实施例中，所述销量预测任务包括对k件商品销量的预测任务；k为大于1的整数。
[0226]
其中，k的值可根据用户需求进行设定或调整。
[0227]
基于图4所示销量预测方法，在一些实施例中，将销量预测任务分成m个子任务，包括：
[0228]
按照所述k件商品分别对应的商品标识，将所述销量预测任务分成m个子任务，不同子任务中包括的商品标识不同。
[0229]
其中，m小于或等于k。
[0230]
示例性地，k件商品对应的商品标识各不相同，将销量预测任务分成k个子任务。
[0231]
又示例性地，k件商品中有2件商品的商品标识相同，将销量预测任务分成m＝k
‑
1个子任务。
[0232]
如此，将包括k件商品的销量预测任务按照商品标识分成m个子任务，进而将m个子任务分配给m个服务节点，相对于单个服务节点执行销量预测任务而言，能充分利用多机或多个服务节点的计算资源，把单机/单节点任务迁移到多机系统或多个服务节点上，可用计
算资源成倍增加，计算耗时成倍减少，可以在更短时间内完成更多、更庞大的计算任务。
[0233]
基于图4所示销量预测方法，在一些实施例中，所述将销量预测任务分成m个子任务，包括：
[0234]
根据所述k件商品分别对应的商品类目，将所述k件商品分成m个任务组；每个任务组对应一个子任务。
[0235]
其中，类目可以理解为分类，分类是为了更好的管理商品。示例性地，类目包括但不限于手机、电脑、家居、母婴、视频、图书等类目。类目的具体划分标准可根据用户需求进行设定或调整。
[0236]
进一步地，类目可分为一级类目、二级类目、三级类目、
…
、x级类目等多级类目，x为大于3的整数。示例性地，手机为一级类目，手机配件为二级类目，充电器为三级类目。又示例性地，图书为一级类目，文学为二级类目，小说为三级类目。
[0237]
如此，按照类目划分任务组，使得每个任务组中的子任务都属于同一类目，进而有助于为单个服务节点分配同一类目的子任务，提高子任务的计算效率。
[0238]
在一些实施例中，所述元数据包括：
[0239]
表征服务节点是否处于空闲状态的第一状态数据；
[0240]
其中，所述方法还可包括：
[0241]
步骤s403：从所述缓存层获取所述n个服务节点中每个服务节点的第一状态数据；基于所述第一状态数据选择当前处于空闲状态的m个服务节点。
[0242]
在一些实施例中，所述将所述m个子任务分发至m个服务节点，包括：
[0243]
将所述m个子任务按顺序分发至所述m个服务节点中的每个服务节点。
[0244]
如此，能够实现对各个子任务的快速分配，从而有助于提高销量预测效率。
[0245]
在一些实施例中，所述将所述m个子任务分发至m个服务节点，包括：
[0246]
根据所述m个服务节点中每个服务节点支持的预测类型，为所述m个服务节点中的每个服务节点分发与其预测类型相适应的子任务。
[0247]
如此，通过为每个服务节点分配其支持的预测类型的相关子任务，能够充分发挥每个服务节点的计算性能，从而有助于销量预测任务的快速完成，节省预测时间，提高预测效率。
[0248]
在一些实施例中，所述元数据包括表征服务节点是否占用全局锁的第二状态数据，其中，占用所述全局锁的服务节点能对所述缓存层的当前数据进行更改操作。
[0249]
在一些实施例中，所述方法还可包括：
[0250]
所述m个服务节点中占用所述全局锁的服务节点，基于所述第二状态数据对所述缓存层存储的所述第一状态数据进行更改。其中，该更改操作包括但不限于增加操作、删除操作、修改操作、查询操作。
[0251]
示例性地，m个服务节点中的第3个服务节点占用全局锁，那么，该第3个服务节点能对缓存层的当前数据进行更改操作，其他未占用全局锁的服务节点不能对缓存层的当前数据进行更改操作。
[0252]
如此，通过全局锁可以防止因各个服务节点同时向缓存层更改数据而导致数据异常的情况发生，保证集群式服务系统中各服务节点的数据一致性，从而使缓存层能够为实现系统中多服务节点之间的协同与数据同步提供技术支撑。
[0253]
在一些实施例中，所述方法还可包括：
[0254]
所述m个服务节点中占用所述全局锁的服务节点，基于所述第二状态数据对所述缓存层存储的销量数据进行更新。
[0255]
如此，通过全局锁可以防止因各个服务节点同时向缓存层写入数据而导致数据异常的情况发生，保证集群式服务系统中各服务节点的数据一致性，从而使缓存层能够为实现系统中多服务节点之间的协同与数据同步提供技术支撑。
[0256]
在一些实施例中，所述缓存层还用于存储多个预设数据索引；所述方法还可包括：
[0257]
基于接收到的子任务确定待拉取的数据清单，其中，所述数据清单包括商品标识以及所述商品标识对应的字段范围和时间范围；
[0258]
基于所述多个预设数据索引从所述缓存层查询所述数据清单中能完成预测的第一类商品的标识，以及所述第一类商品的标识所对应的字段范围值和时间范围值；
[0259]
基于所述第一类商品的标识所对应的所述字段范围值和所述时间范围值，从所述数据层拉取所述第一类商品对应的预测所需商品销量数据。
[0260]
如此，各服务节点根据缓存索引中查到的数据可用情况，向数据层拉取需要的数据。因为已经经过了缓存层过滤，一方面减少了无效的查询，另一方面缓存层提供了索引信息，可以更快速的定位到需要的数据。
[0261]
在一些实施例中，所述缓存层还用于存储商品标识与类目标识的对应关系；所述方法还可包括：
[0262]
统计预测时需要用到类目的p个第二类商品；p为大于等于1的整数；
[0263]
从所述缓存层拉取所述p个第二类商品的类目标识；
[0264]
对所述p个第二类商品的类目标识进行聚合，得到q个目标类目标识；q为大于等于1的整数，q小于或等于p；
[0265]
从所述缓存层拉取所述q个目标类目标识对应的类目数据；
[0266]
基于所述q个目标类目标识对应的类目数据，从所述数据层拉取所述q个目标类目标识对应的预测所需类目销量数据。
[0267]
如此，各服务节点根据缓存索引中查到的数据可用情况，向数据层拉取需要的数据，能够减少拉取类目销量数据的次数，节省单独拉取类目销量数据所耗费时间，从而有助于提升预测效率。
[0268]
在一些实施例中，所述方法还可包括：接收基于http发送的所述销量预测任务；基于所述http返回所述销量预测任务的所述销量预测结果。
[0269]
如此，销量预测结果由入口节点根据接收到的各个服务节点返回的任务执行结果确定出后返回用户终端，即不做落地，将销量预测结果直接返回用户终端而不在入口节点做存储，即能减少对入口节点内存资源的占用，又能提高数据的安全性。
[0270]
本公开销量预测方法所涉及的集群式服务系统中各模块参见上述集群式服务系统中的对应描述，在此不再赘述。
[0271]
基于图1所示销量预测系统，在一些实施例中，销量预测流程如下：
[0272]
1、用户终端发送预测请求到入口节点，包括需要进行预测的商品列表、日期范围、模型参数等必要信息；
[0273]
2、入口节点与缓存层交互，查询当前可用的服务节点数量m；
[0274]
3、入口节点收到预测请求后，按照商品id，把整个预测任务拆解为m个子任务。并且，在拆解的过程中，由于不同商品可能属于不同类目、具有不同销售特性，可以使用不同的模型进行计算。因此，除了均匀拆分，还可以按照需要对商品进行分组，同一组内的商品使用相同的模型和参数，然后将整组任务分发到同一个服务节点上。
[0275]
4、m个子任务分发到m个可用服务节点上，m个服务节点并行的开始计算过程；
[0276]
5、各服务节点根据任务输入，以及相应的模型、参数，拉取计算所需的数据清单，其中，数据清单包括需要哪些字段、哪段时间、哪些商品等数据。
[0277]
6、各服务节点向缓存层的索引进行查询，快速确认(字段、时间、商品)数据需求哪些能被满足(即哪些商品能具备有需要的字段、并且字段满足时间范围，商品由于售卖时间不同，上架时间不同，未必能满足模型计算需要的历史数据长度)，确认能完成计算的商品id列表，以及对应数据的具体字段范围、时间范围、存放索引。
[0278]
7、对于不同粒度的单元，保证同一个计算节点对同一个单元只保有一份数据，例如：预测时要用到商品自身销量，同时也会用到商品的类目销量。对于多件商品，可能共享同一份类目数据。因此，在拉取数据的时候，不需要对每个商品id都拉一份类目数据，而是根据类目关系映射，汇总好本节点计算时总共需要哪些类目id对应的数据，然后一次性把需要的类目id数据拉取回来，后续计算过程中引用同一份数据进行计算。
[0279]
8、各服务节点根据缓存索引中查到的数据可用情况，向数据层拉取需要的数据。因为已经经过了缓存层过滤，一方面减少了无效的查询，另一方面缓存层提供了索引信息，可以更快速的定位到需要的数据。
[0280]
9、各服务节点拿到需要的数据时，开始执行销量预测的计算过程。
[0281]
10、服务节点完成子任务的计算后，将结果返回给入口节点；
[0282]
11、入口节点将各服务节点对不同商品进行预测得到的结果，汇总封装成一份数据，返回给用户终端。
[0283]
举例说明，假设当前需要预测1000件商品在2021年1月1日～2021年1月30日每一天的销量(求1000件*30天的销量数值)，用户将相关参数发送给入口节点；入口节点查询到当前可用10个服务节点，因此，可以将计算任务拆分成至少10份。在拆分的过程中，考虑到1000件商品的属于不同类目，具有不同的数据特点，可以采用不同的模型进行计算(具体的映射关系可以进行人工配置)。因此，按照商品特性，适用同一种模型的商品放入同一个任务组当中。假设1000件商品中包括5个类目，每个类目200件商品，最终被拆分成以下10组任务：
[0284]
任务1(商品1～100，类目1，模型1)
[0285]
任务2(商品101～200，类目1，模型1)
[0286]
任务3(商品201～300，类目2，模型2)
[0287]
任务4(商品301～400，类目2，模型2)
[0288]
任务5(商品401～500，类目3，模型3)
[0289]
…………
[0290]
每组任务由入口节点分别分发到10个服务节点上，每个服务节点对应一个计算任务。
[0291]
每个服务节点接收到计算任务后，服务节点开始调用模型并行预测计算，计算过
程中先从缓存层拉取每件商品可用的字段以及字段对应的时间范围，然后根据模型的需求(例如模型1需要近30天的历史销量数据，那么上架不足30天的商品就无法在模型1的计算中得到计算结果)，确认满足计算条件的商品列表，以及所有商品计算需要用到的特征数据清单和索引(例如商品1～商品100中，仅有商品1～商品90具有足够长的历史数据，那么需要用到的特征数据就是商品1～商品90近30天的历史销量等)，如果要用到其他粒度的数据，需要模型层对数据需求进行汇总，再执行拉取动作(例如还需要类目的销量数据，经汇总发现商品1～商品90都属于类目1，那就只要执行一次类目粒度数据的拉取，拉取目标为类目1的销量)。
[0292]
服务节点获取到需要的特征输入数据后开始执行计算，得到结果后，返回给入口节点。入口节点将所有结果拼装在一起，得到最终的计算结果，返回给用户终端。
[0293]
显然，在上述10个节点的例子中，因为利用到了10倍于单机的计算资源，显然最终计算的耗时也将是单机计算的1/10，并且每个节点上所需要用到的数据量也将缩减为原本的1/10。这样，很多在单机计算无法完成(时间或空间超出限制)的庞大预测任务，都可以在这个集群式系统很好的完成。同时所有的数据按照实际模型的计算需要(按商品id范围、按时间范围、类目数据复用)进行拉取，保证不会占用多余的存储空间和传输时间。
[0294]
示例性介质
[0295]
在介绍了本公开示例性实施方式的方法之后，接下来，参考图5对本公开示例性实施方式的介质进行说明。
[0296]
在一些可能的实施方式中，本公开的各个方面还可以实现为一种计算机可读介质，其上存储有程序，当程序被处理器执行时用于实现本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的销量预测方法中的步骤。
[0297]
具体地，上述处理器执行上述程序时用于实现如下步骤：
[0298]
将销量预测任务分成m个子任务，并将所述m个子任务分发至m个服务节点；m为大于1的整数；
[0299]
根据所述m个服务节点返回的任务执行结果，确定所述销量预测任务的销量预测结果。
[0300]
需要说明的是：上述的介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于：电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(random access memory，ram)、只读存储器(read
‑
only memory，rom)、可擦式可编程只读存储器(erasable programmable read
‑
only memory，eprom)或闪存、光纤、便携式紧凑盘只读存储器(compact disc read
‑
only memory，cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
[0301]
如图5所示，描述了根据本公开的实施方式的介质500，其可以采用便携式紧凑盘只读存储器(cd
‑
rom)并包括程序，并可以在设备上运行。然而，本公开不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
[0302]
可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于：电磁信号、光信
independent disks，raid)系统、磁带驱动器以及数据备份存储系统等。
[0314]
应当注意，尽管在上文详细描述中提及了文本分类装置的若干单元/模块或子单元/子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
[0315]
此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
[0316]
虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。