事务处理方法和装置与流程

1.本技术涉及事务处理领域，具体涉及事务处理方法和装置。


背景技术：

2.不论是日常生活还是在互联网上，人们需要处理各种事务；进行中的事务往往具有多个节点，事务可以在这些节点之间流转；所述多个节点可以代表该事务的多个状态，或者，可以表示多个步骤或行为。事务在节点之间的流转可以指事务的状态从一种状态变化到另一种状态，或从执行的第n步骤变化到第n 1步骤。一个事务是否可以从一个节点变化到下一个节点，例如，根据情况是否允许事务从第n个步骤变化到底n 1个步骤，这个过程称为流向调整，或者叫做节点流转，或者称为分支流向的选择。所谓分支流向，即针对某个具体事项，选择“是”这个分支还是选择“否”这个分支。
3.为了对事务在节点之间的流转进行控制和管理，需要对是否能够进行节点流转进行判断和设置。
4.例如，对于某个商品，在获得该商品的销售预测的状态下，可以通过对商品的状态信息进行分析，确定是否将销售预测状态转换为销售计划状态，即是否将该销售预测作为该商品的销售计划，从而，确定是否需要进行补货，并确定是否需要对相关人员的工作安排进行调整，以实现该销售计划。
5.当前的通常技术下，上述节点流转的判断和设置都是通过人工进行，具体而言，由负责管理的人员对事务相关的信息进行分析，从而判断事务是否可以从当前所处的节点转移到另一个节点，即是否进行流向调整，这种方式对于一般性的事务处理没有问题，但是，在互联网的事务处理领域，例如，互联网销售网络，可能会在短时间内需要对成千上万种类的商品sku的事务分别进行判断和设置，依靠人工处理不可能迅速处理完成。因此，如何实现对节点流转的机器干预成为一个需要解决的问题。


技术实现要素：

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.图1是本技术实施例提供的一种事务处理方法的示意性流程图；
43.图2是本技术实施例提供的另一种事务处理方法的示意性流程图；
44.图3是本技术实施例提供的又一种事务处理方法的示意性流程图；
45.图4是本技术实施例提供的一种策略配置信息的示意图；
46.图5是本技术实施例提供的一种商品的流转管理的策略示意图；
47.图6是本技术实施例提供的一种数据库更新方法的示意性流程图；
48.图7是本技术实施例提供的一种事务处理装置的示意性结构图；
49.图8是本技术实施例提供的另一种事务处理装置的示意性结构图。
keeping unit，sku)进行各种事务处理的分支流向的判断；如图5所示，该销售平台作为策略消费者，可能需要使用具体的目标策略，在以下事项进行分支流向判断：销售预测是否可以转为销售计划的判断，或者判断某个sku是否可以将销售预测实时转计划(即随时将销售预测转为销售计划)，或者针对某个sku判断是否可以将计划实时转换为实际的补货操作。
61.所述策略中心102用于根据策略消费者发出的策略请求，以及与策略规则相关的状态信息，在当前策略规则中确定相匹配的目标策略，所述目标策略中包含根据何种场景进行何种分支流向选择的策略。
62.所述数据库103可以称为策略数据库，用于接收和存储对策略规则的更新，并将更新的策略规则作为更新数据，供所述策略中心102读取。所述数据库103的作用在于作为策略规则暂时的存储位置，联结策略规则的创制和策略规则的分发。本技术实施例侧重于策略规则的自动分发问题。
63.示例性地，数据库103中存储有至少一个策略规则集合。每个策略规则集合包括多个策略的策略配置信息。不同的策略规则集合对应于不同的点集，不同的点集中的节点可以用于表示事务不同类型的状态或不同的步骤、行为等。不同的节点也可以理解为事务处于的不同场景。
64.应当理解，策略消费者101、策略中心102、数据库103可以位于相同或不同的设备中。示例性地，策略消费者101、策略中心102可以是相同或不同的终端设备，数据库103可以是云设备。策略消费者101、策略中心102、数据库103之间可以通过有线或无线的方式进行通信。
65.具体的，可以参见图1所示的该实现事务处理的系统的时序图，请注意其中的步骤s101至s106。
66.为了使得策略中心本地存储的策略规则集合及时得到更新，可以进行s101至s102。
67.策略中心102可以存储有策略规则集合。
68.s101，策略中心102周期性或者在被特定动作触发的情况下，向数据库发送更新请求信息。
69.所谓特定动作触发，例如，数据库103向策略中心102发出策略规则存在更新的提示。
70.s102，数据库103向策略中心102发送更新数据。
71.更新数据用于指示数据库103当前存储的策略规则集合中各个策略规则。
72.策略规则集合中策略规则的数量可以为多个。每个策略规则可以包括匹配规则表和策略的配置内容等信息。匹配规则表包括至少一个状态参数的取值范围。策略的配置内容可以称为策略的内容或者策略，用于表示节点的流向。
73.策略规则具体表现为如图4所示的策略配置信息。
74.策略中心102在接收更新数据后，可以利用更新数据，对本地的策略规则集合进行更新。
75.以策略中心102周期性发送更新请求为例，数据库103发送的更新数据可以包括上一个周期中数据库103策略规则集合的操作日志，也可以包括数据库103中当前存储的该策略规则集合。
76.在更新数据包括上一个周期内数据库103中策略规则集合的操作日志的情况下，根据该操作日志，策略中心102可以确定上一个周期内策略规则集合各个策略规则的变化情况，从而策略中心102可以根据该变化情况对本地的策略规则集合进行更新。
77.在更新数据包括数据库103中当前存储的策略规则集合的情况下，策略中心102对更新数据中的策略规则集合进行存储，也可以实现对策略中心102本地的策略规则集合的更新。
78.通过s101至s102，定期更新策略规则集合，使得策略中心102后续的处理更加具有时效性，处理结果更为准确。经过更新后策略中心102本地存储的策略规则集合中的策略规则即为当前策略规则。
79.一般情况下，对于图5所示的商品的流转管理场景，一个策略规则集合中，策略的数量不会太多(例如可以是百级别)，并且对于策略规则集合，读取策略规则集合进行处理的频率远远高于策略规则集合被修改的频率。示例性地，需要利用策略规则集合进行处理的数据量可以是百万级别。
80.更新策略规则集合的周期可以是秒级的，例如该周期可以是1秒(s)、3s、5s等。
81.从而，数据库中更新策略规则集合的变更，可以及时传输至策略中心，使得策略中心根据最新的策略规则集合进行处理，使得策略中心的后续处理结果更加准确。
82.s103，策略消费者101向策略中心102发送策略请求。
83.策略请求包括请求事项。
84.s104，策略中心102根据与策略判断相关的状态信息以及请求事项，在当前策略规则中确定相匹配的目标策略。
85.与策略判断相关的状态信息可以是根据请求事项确定的。
86.示例性地，策略中心102可以获取全部的状态信息，在全部的状态信息中选择与策略判断相关的状态信息，之后，将选择的与策略判断相关的状态信息与各个策略的匹配规则表进行匹配。
87.或者，策略中心102可以根据请求事项，获取与策略判断相关的状态信息。之后，将获取的与策略判断相关的状态信息与各个策略的匹配规则表进行匹配。
88.与策略判断相关的状态信息包括多个参数值。将该多个参数值与策略规则集合中各个策略规则的匹配规则表中各个参数的数值范围进行比较，以确定该多个参数值是否在匹配规则表中各个参数的数值范围内。状态信息的各个参数值均在某个策略规则的匹配规则表的参数数值范围内的情况下，可以认为状态信息与该策略规则相匹配，该策略规则对应的策略即为目标策略。
89.示例性地，在同一时间点，同一事务可能处于两个不同的点集中。两个点集用于表示事务不同的状态或步骤、动作等。不同的点集可以对应于不同的策略规则集合。每个策略规则集合可以包括至少一个策略规则。
90.不同的策略消费者可以对应于不同的点集。也就是说，不同的策略消费者可以对应于不同的策略规则集合。策略中心接收某个策略消费者发送的策略请求之后，可以在该策略消费者对应的策略规则集合中根据与策略判断相关的状态信息进行匹配。
91.或者，不同的事项可以对应于不同的点集。也就是说，不同的事项可以对应于不同的策略规则集合。应当理解，每个点集可以对应于一个或多个事项。可以在策略消费者发送
的策略请求中的请求事项对应的策略规则集合中，根据与策略判断相关的状态信息进行匹配。
92.示例性地，策略请求可以与当前的节点相关。也就是说，策略请求可以用于指示当前节点，例如，用于指示当前的状态、步骤或动作等。作为当前节点，多个节点可以对应于多个策略。策略中心可以在策略请求指示的当前节点对应的至少一个策略中，根据与策略判断相关的状态信息进行匹配。
93.示例性地，策略请求还可以与下一个节点相关。策略请求可以用于指示下一个节点。作为下一个节点，多个节点可以对应于多个策略。策略中心可以在策略请求指示的下一个节点对应的至少一个策略中，根据与策略判断相关的状态信息进行匹配。
94.应当理解，策略请求指示的当前节点对应的策略、策略请求指示的下一个节点对应的策略，均可以理解为策略请求对应的策略。
95.策略规则还可以包括策略的优先级。在策略请求对应的策略的数量为多个的情况下，可以根据该多个策略的优先级顺序，根据与策略判断相关的状态信息进行匹配。
96.示例性地，策略中心102或数据库103可以根据策略规则变更的先后顺序按照倒序排列确定所述策略规则的优先级顺序。
97.s105，策略中心102向策略消费者101发送目标策略。
98.目标策略可以用于表示分支流向结果，用于指示节点流转。例如，对于某个具体实现，目标策略可以用于指示选择“是”这个分支还是选择“否”这个分支。
99.s106，策略消费者101执行该目标策略。
100.策略消费者101执行目标策略指示的分支流向结果。即策略消费者101控制和调整事务在节点之间的流转。
101.通过s103至s106，根据策略规则集合对分支流向策略进行自动的选择匹配，从而确定流向，并实现事务在节点之间的跳转。
102.图2是本技术实施例提供的一种事务处理方法的示意性流程图。本实施例提供的事物理方法具体可以应用于实现事务处理功能的电子设备，该电子设备可以是终端设备、服务器等，在其他实施例中，电子设备还可以采用其他设备实现，本实施例此处不做具体限定。示例性地，该电子设备可以是图1中的策略中心102。
103.图2所示的方法包括s201至s203。
104.在s201之前，可以周期性或者在触发下获取更新数据。更新数据可以用于对策略规则进行更新。当前策略规则可以是根据最后一个获取的更新数据进行更新后得到的策略规则。
105.通过周期性或在触发下获取更新数据，可以实现对策略规则的更新，使得当前策略规则为最新的策略规则，对当前策略规则进行实时调整，使得确定的目标策略更加准确。
106.示例性地，可以向数据库周期性发送更新请求。数据库在接收更新请求后，可以发送更新数据。也就是说，数据库发送更新数据可以是对接收的更新请求的响应。
107.当前策略规则的数量可以是多个，其中，全部或部分策略规则可以是根据更新数据新增加的策略规则。
108.当前策略规则可以包括根据更新数据新增加的参数信息类型，策略判断相关的状态信息可以包括属于所述参数类型的参数值。
109.也就是说，提供了一种灵活的方式对策略规则进行修改。可以增加新的策略规则，也可以在策略规则中增加新的参数类型。
110.示例性地，可以根据策略规则更新的先后顺序按照倒序排列确定所述策略规则的优先级顺序。
111.根据更新时间的倒序确定各个的策略规则的优先级，可以使得后续步骤的处理结果更加符合最新的需求。
112.s201，获取策略请求，以及与策略判断相关的状态信息，所述策略请求至少包括请求方的请求事项。
113.请求事项可以与事务所处场景相关，状态信息对与事务所处的场景变化产生影响。
114.在请求事项为与商品的流转管理相关的事项的情况下，状态信息可以用于指示商品的销售场景。
115.状态信息包括以下参数中的至少一个：销售平台、销售活动、经营状态等。也就是说，商品的销售场景可以包括销售平台、销售活动、经营状态等。
116.销售活动可以包括营销活动、促销活动等。
117.经营状态，可以是以下几种状态中的一个：正常状态、新品试销状态、中长期缺货状态、清仓状态等。
118.与策略判断相关的状态信息可以是请求方发送的，也可以从其他用于对商品的状态进行监控的装置处获取。示例性地，执行图2所示方法的装置可以用于对商品的状态进行监控，则在进行s201时，可以从存储装置中读取与策略判断相关的状态信息。
119.在进行s201时，可以获取与事务相关的全部类型的状态参数，并在全部类型的状态参数中选择与策略判断相关的状态信息。
120.多个的事项可以对应于当前策略规则中多个的策略规则。在进行s201时，可以确定与请求事项对应的策略规则。之后，可以获取与请求事项对应的策略规则进行匹配所需的事务的参数类型的状态参数，作为与策略判断相关的状态信息。
121.数据库的修改方式可以包括在策略规则中增加新的参数类型。在进行s201时，可以根据请求事项进行状态信息的获取，使得获取的状态信息包括新增加的参数类型的参数值，从而使得后续步骤的处理结果更加准确。
122.s202，根据所述策略请求以及所述状态信息，在当前策略规则中确定相匹配的目标策略。
123.当前策略规则的数量可以是多个。
124.每个策略规则可以包括至少一个状态参数类别以及每个状态参数类别的范围。状态信息可以包括事务的该至少一个状态参数类别的参数值。通过对策略规则中各个状态参数类别下状态信息中的参数值是否符合策略规则的范围，对状态信息与策略规则进行匹配。
125.在事务的该至少一个状态参数类别的参数值符合某个策略规则的各个状态参数类别的范围的情况下，该策略规则对应的策略为目标策略。
126.该多个当前策略规则的优先级可以相同或不同。在多个当前策略规则对应于多个优先级的情况下，在s202，可以按照优先级顺序在该多个当前策略规则中进行匹配。
127.通过为多个当前策略规则设置多个优先级，可以使得得到的目标策略更加符合需求，提高处理效率。
128.在当前策略规则的数量为多个的情况下，多个事项可以对应于当前策略规则中多个策略规则。每个事项对应的策略规则可以是一个或多个，不同的事项对应的策略规则可以是相同或不同的。从而，在s202，可以根据所述状态信息，在所述请求事项对应的至少一个策略规则中确定所述目标策略。
129.通过设置每个当前策略规则对应的事项，从而可以仅在请求事项对应的策略规则进行匹配，提高处理效率，降低所需的时间。
130.s203，向所述策略请求的请求方发送所述相匹配的目标策略，所述目标策略用于指示针对所述请求事项的选择结果。
131.请求事项的选择结果可以用于指示分支流向。进行中的事务往往具有多个节点，事务可以在这些节点之间流转。不同的节点可以用于表示事务不同的状态、步骤、动作等。
132.请求事项可以与当前节点相关，目标策略可以与流向的节点，即下一个节点相关。流向的节点可以是与当前节点相同或不同的节点。示例性地，对请求事项的选择结果可以用于指示下一个节点。
133.或者，分支流向的策略请求中，请求事项可以指示当前节点和下一个节点，分支流向的选择结果可以为“是”或“否”，即表示允许从当前节点跳转至下一个节点，或不予许从当前节点跳转至下一个节点。
134.目标策略可以针对具体的商品最小存货单元(stock keeping unit，sku)。sku也可以称为库存量单位，是库存进出计量的单位。
135.目标策略针对具体的商品最小存货单元，可以使得目标策略更为精细，更加符合销售场景的需求。
136.通过s201至s203，可以根据策略请求方的请求事项，利用相关的状态条件，在当前策略规则中获取相匹配的目标策略；在策略消费者，会根据自身所处的场景发出策略请求，并在获得目标策略后，根据所述目标策略，以目标策略为依据，进行对相关请求事项的选择。
137.从而，使得策略设计与策略分发相互独立，避免了由人工进行具体的策略选择，降低人工成本。
138.图3是本技术实施例提供的一种事务处理方法的示意性流程图。
139.图3所示的事务处理方法包括s301至s302，可以应用于策略消费者。
140.在s301，根据所处于的场景的情况，发出策略请求，所述策略请求至少包括请求事项。
141.事务所处的场景，可以理解为事务的状态、正在进行的步骤或行为等。不同的场景也可以通过不同的节点表示。请求事项可以是根据所处于的场景确定规定。
142.在s302之前，还可以发送与策略判断相关的状态信息，状态信息可以用于策略请求接收方对目标策略的确定。
143.策略请求用于指示被请求方根据所述策略请求以及与策略判断相关的状态信息，在当前策略规则中确定相匹配的目标策略。
144.也就是说策略请求可以用于指示被请求方启动进行匹配，以确定目标策略。
145.被请求方可以在s301之前或之后获取与策略判断相关的状态信息。
146.策略请求可以发送至策略中心。策略中心可以执行图2所示的方法，或执行图1中策略中心102执行的各个步骤。
147.在s302，接收目标策略，并根据所述目标策略，针对所述策略请求涉及的请求事项，进行分支流向的选择。
148.请求事项的选择结果可以用于指示分支流向。进行中的事务往往具有多个节点，事务可以在这些节点之间流转。不同的节点可以用于表示事务不同的状态、步骤、动作等。
149.请求事项可以与当前节点相关，分支流向的选择结果可以与流向的节点，即下一个节点相关。流向的节点可以是与当前节点相同或不同的节点。示例性地，对请求事项的选择结果可以用于指示下一个节点。
150.或者，分支流向的策略请求中，请求事项可以指示当前节点和下一个节点，分支流向的选择结果可以为“是”或“否”，即表示允许从当前节点跳转至下一个节点，或不予许从当前节点跳转至下一个节点。
151.目标策略可以针对具体的商品最小存货单元(stock keeping unit，sku)。sku也可以称为库存量单位，是库存进出计量的单位。也就是说，请求事项可以针对具体的商品sku。
152.目标策略针对具体的商品最小存货单元，可以使得目标策略更为精细，更加符合销售场景的需求。
153.图4是本技术实施例提供的一种策略配置信息的示意图。
154.策略的配置信息可以包括策略的匹配规则表(hit rules)和策略的配置内容(configcontent)。匹配规则表也可以理解为策略规则，策略的配置内容也可以理解为策略的内容。
155.策略的配置信息还可以包括以下信息中的一个或多个：策略的标识(identification，id)、名称(name)、描述(desc)、策略状态(strategystatus)、优先级(priority)、创建者id(creator id)、创建者姓名(creator name)、创建时间(gmtcreate)、修改时间(gmtmodified)、操作日志表(operatelogs)等。
156.其中，策略的id的格式可以是长整型(long)，策略的名称、描述、配置内容、创建者id、创建者姓名的格式可以是字符串(string)，策略的策略状态、优先级的格式可以是整型(int)，策略的修改时间、操作日志的格式可以是数据(data)，策略的匹配规则表和操作日志表可以通过列表表示。
157.不同的策略可以通过策略的id、名称或配置内容等表示。
158.策略的匹配规则表可以包括至少一个匹配项。每个匹配项包括参数以及该参数的取值范围，不同的参数可以表示为不同的类型(type)，参数的取值范围可以表示为集合(set)。类型的格式可以是整型(int)，集合(set)可以包括一个或多个数，例如，该一个或多个数可以包括最大值、最小值等，该一个或多个数的格式可以是字符串(string)。
159.操作日志表中可以包括至少一条操作日志。每条操作日志可以包括操作者id(operator id)、操作者姓名(operator name)、操作类型(operate type)、修改内容(modify content)、创建时间(gmtcreate)。其中，操作者id、操作者姓名、修改内容的格式可以是字符串(string)，操作类型的格式可以是整型(int)，创建时间的格式可以是数据
(data)。
160.应当理解，策略的配置信息中的创建时间可以是指该策略的创建时间。而操作日志中的创建时间可以是指该条操作日志的创建时间。策略的配置信息中的修改时间，可以是该策略的最后一次修改时间，或者，可以包括最后一次以及之前的一次或多次修改的时间。
161.策略的配置信息中的各个信息也可以采用其他格式，本技术实施例对此不做限定。
162.策略的配置信息可以通过表格或其他形式表示。策略的配置信息中的各个信息可以对应于多个字段。
163.例如，对如图5所示商品的流转管理，某个策略的配置内容可以指示销售预测转销售计划，销售预测实时转销售计划，或者，销售计划转补货建议等。销售预测、销售计划、补货建议表示商品的流转管理中不同的节点。对于商品的流转管理，某个策略的匹配规则可以包括对商品的销售平台、活动、经营状态等商品的状态参数中的一个或多个的限制。
164.由于消费者的消费能力的变化，商品的流转管理中节点之间流转的条件可能发生变化，及策略的匹配规则可能改变。可以对数据库中存储的策略规则集合进行调整。具体的，可以参见图6的说明。
165.图5是本技术实施例提供的一种商品的流转管理的策略示意图。
166.商品的流转管理包括预测数据流转。在预测数据流转中，多个策略的配置内容可以分别是销售预测转销售计划、销售预测实时转销售计划、销售计划实时转补货建议。
167.销售预测实时转销售计划，也可以理解为，全量任务时销售预测转销售计划。销售计划实时转补货建议，也可以理解为，全量计算销售计划转补货建议。
168.不同策略具有不同的匹配规则表。在商品的流转管理中，各个策略的匹配规则表中，参数的类型可以包括平台、活动、经营状态等中的一个或多个。
169.匹配规则表还可以包括各个类型的参数的数值范围等。
170.图6是本技术实施例提供的一种数据库更新方法的示意性流程图。本实施例提供的数据处理方法具体可以应用于实现数据库更新功能的电子设备，该电子设备可以是终端设备、服务器等，在其他实施例中，电子设备还可以采用其他设备实现，本实施例此处不做具体限定。
171.图6所示的方法包括s601至s603。
172.在s601之前，操作者可以修改策略的匹配规则表、描述、策略状态、优先级、配置内容等。创建者id、创建者姓名、创建时间、修改时间、操作日志表等信息可以是自动生成的。
173.操作者可以增加匹配规则表中参数的类型，也可以增加策略，还可以增加策略规则集合。
174.在s601，获取操作者进行提交保存的操作。
175.操作者进行保存的操作可以是在显示界面显示的选项卡中点击“保存”，也可以是通过键盘输入的特定字符串流等。
176.在s602，保存操作者的输入数据，以得到修改后的数据库。
177.在操作者进行提交保存操作之前，操作者可以输入数据。从而，在s602，可以对输入数据进行保存。操作者的输入数据可以用于对数据库进行修改。
178.数据库可以包括多个策略中每个策略的配置信息。
179.策略的配置信息可以参见图4的说明。操作者可以对其中的全部或部分内容进行修改。
180.在s603，记录修改日志，以得到修改后的操作日志表。
181.示例性地，策略的配置信息可以包括该策略的修改日志表。对于需要进修改的策略的配置信息，在s602可以是对策略的修改日志表之外的其他信息进行修改，在s603可以是对策略的修改日志表进行修改。也就是说，数据库可以存储除修改日志表之外策略的配置信息中的其他信息。
182.修改后的数据库和/或修改后的操作日志表，可以用于对策略中心本地存储的策略规则集合进行更新。
183.示例性地，操作者可以增加策略规则集合中参数的类型，操作者也可以增加策略，操作者还可以增加策略规则集合。
184.增加策略，可以理解为新建策略的配置信息。
185.利用增加的策略规则集合，能够对事务新的状态、步骤或动作的变化进行管理。策略中心可以通过更新数据获取增加的策略规则集合，从而具有对更多类型的事务流转的控制和管理能力，提高应该的广泛性。
186.应当理解，操作者也可以修改策略的配置信息中的优先权等信息。
187.上文结合图1至图6描述了本技术实施例提供的事务处理方法，下面结合图7至图8，描述本技术实施例的装置实施例。应理解，事务处理方法的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见上文的描述。
188.图7是本技术实施例提供的一种事务处理装置的示意性结构图。
189.图7所示的事务处理装置包括：收发单元701和处理单元702。
190.在一些实施例中，收发单元701用于，获取策略请求，以及与策略判断相关的状态信息，所述策略请求至少包括请求方的请求事项；
191.处理单元702用于，根据所述策略请求以及所述状态信息，在当前策略规则中确定相匹配的目标策略；
192.收发单元701还用于，向所述策略请求的请求方发送所述相匹配的目标策略，所述目标策略用于指示针对所述请求事项的选择结果。
193.可选的，收发单元701还用于，周期性或者在触发下，获取更新数据，所述更新数据用于对策略规则进行更新，所述当前策略规则为根据最后获取的更新数据更新后的策略规则。
194.可选的，所述当前策略规则的数量为多个，其中，根据策略规则更新的先后顺序按照倒序排列确定所述策略规则的优先级顺序。
195.可选的，当前策略规则包括根据所述更新数据新增加的参数信息类型，所述策略判断相关的状态信息包括属于所述参数类型的参数值。
196.可选的，所述当前策略规则的数量为多个，多个所述当前策略规则对应于多个优先级；
197.处理单元702具体用于，按照优先级顺序在所述多个当前策略规则中进行匹配。
198.可选的，所述当前策略规则的数量为多个；
199.处理单元702具体用于，根据所述状态信息，在所述请求事项对应的策略规则中确定所述目标策略。
200.可选的，所述请求事项与商品的流转管理相关，所述状态信息用于指示所述商品的销售场景。
201.可选的，所述状态信息包括以下参数中的至少一个：销售平台、销售活动、经营状态。
202.可选的，所述目标策略针对具体的商品最小存货单元。
203.在另一些实施例中，收发单元701用于，根据所处于的场景的情况，发出策略请求，所述策略请求至少包括请求事项，所述策略请求用于指示被请求方根据所述策略请求以及与策略判断相关的状态信息，在当前策略规则中确定相匹配的目标策略。
204.收发单元701还用于，接收目标策略。
205.处理单元702用于，根据所述目标策略，进行针对所述策略请求涉及的请求事项的选择。
206.图8是本技术实施例提供的一种事务处理装置的示意性结构图。
207.图8所示的事务处理装置包括：处理器801和存储器802。
208.所述存储器802用于存储程序，处理器801用于调用存储器存储的程序，以执行上述推荐算法的评估方法。
209.本技术实施例还提供一种存储介质，所述存储介质存储有程序，所述程序被处理器执行，用于实现上述事务处理方法。
210.本技术实施例还提供一种事务处理系统，包括策略消费者、策略中心、以及策略数据库。
211.所述策略消费者，用于根据所处于的场景的情况，发出策略请求，以及与策略判断相关的状态信息，所述策略请求至少包括策略消费者的请求事项；以及，接收所述策略中心提供的目标策略，并根据所述目标策略进行针对所述策略请求涉及的请求事项的选择。
212.所述策略中心，用于获取策略请求，以及与策略判断相关的状态信息，所述策略请求至少包括请求方的请求事项；根据所述策略请求以及所述状态信息，在当前策略规则中确定相匹配的目标策略；向所述策略请求的请求方发送所述对应的目标策略，所述目标策略用于指示针对所述请求事项的选择结果；以及，从所述策略数据库获取更新数据，所述更新数据用于对策略规则进行更新。
213.所述策略数据库，用于接收和存储对策略规则的更新，并将更新的策略规则作为更新数据，供所述策略中心读取。
214.具体的，策略消费者可以用于执行图3所述的方法，或可以用于执行图1中策略消费者101执行的步骤。策略中心可以用于执行图2所述的方法，或可以用于执行图1中策略中心102执行的步骤。策略数据库可以用于执行图5所述的方法，或用于执行图1中数据库103执行的步骤。
215.需要说明的是，尽管在上文详细描述中提及了用于动作执行的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本技术的具体实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
216.此外，尽管在附图中以特定顺序描述了本技术中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
217.应当注意，本技术的实施方式可以通过硬件、软件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现；软件部分可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的设备和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、cd或dvd-rom的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本技术的设备及其模块可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合例如固件来实现。
218.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，凡在本技术的精神和原则之内所作的任何修改、等同替换和改进等，都应涵盖在本技术的保护范围之内。