时间统计规则加载方法、装置、存储介质及电子设备与流程

1.本公开涉及计算机技术领域，具体地，涉及一种时间统计规则加载方法、装置、存储介质及电子设备。


背景技术：

2.在配送系统中，为了帮助配送业务进行规范化管理，需要对骑手配送订单时的各项时间进行统计。例如，对骑手到店时间、骑手取餐时间、骑手交付时间等时间进行统计。
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.采用上述技术方案，至少能够达到如下的有益技术效果：
57.通过在缓存中加载时间统计计算脚本，使用时间统计计算脚本来替换传统的时间统计计算相关代码，由于计算脚本可以直接编辑替换计算公式，使得在确定配置数据库发生配置变更，需要修改时间统计计算规则时，只需要对缓存中的时间统计计算脚本进行更新即可，也即只需要将包括订单场景与时间统计计算脚本之间的关联关系的目标配置数据加载到缓存中，便可以迅速完成对时间统计计算规则的修改，并且由于脚本的更新过程也不需要经过标准的开发、测试、上线流程，因此，降低了时间统计方法更新维护难度，提高了时间统计计算方法的更新速度，提高了骑手使用体验。
58.本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。
附图说明
59.附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：
60.图1是根据本公开一示例性实施例示出的一种订单场景排列组合示意图。
61.图2是根据本公开一示例性实施例示出的一种时间统计规则加载方法的流程图。
62.图3是根据本公开一示例性实施例示出的一种监听变更加载过程的流程图。
63.图4是根据本公开一示例性实施例示出的一种版本比对加载过程的流程图。
64.图5是根据本公开一示例性实施例示出的一种时间统计系统的结构示意图。
65.图6是根据本公开一示例性实施例示出的一种计算引擎进行时间统计计算的流程图。
66.图7是根据本公开一示例性实施例示出的一种时间统计规则加载装置的框图。
67.图8是根据本公开一示例性实施例示出的一种电子设备的框图。
具体实施方式
68.以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。
69.需要说明的是，本公开中所有获取信号、信息或数据的动作都是在遵照所在地国家相应的数据保护法规政策的前提下，并获得由相应装置所有者给予授权的情况下进行的。
70.请参阅图1，由于存在业务线、管理模式、工作模式、服务包、预约单、商家标签等一系列类型，这些类型排列组合加起来会有上百种的订单场景，使得订单场景复杂多样，并且每一种订单对应有各自的时间统计计算规则，当存在时间统计计算规则设置不合理而不再适用的情况，即使只是一小点改动，也需要调整时间统计计算的相关代码，从而不得不经过标准的开发、测试、上线流程，将所有开发流程都走一遍，从而导致相关技术中对骑手时间统计方法的更新维护困难，耗费时间长，降低了骑手使用体验。
71.有鉴于此，本公开实施例提供一种时间统计规则加载方法、装置、存储介质及电子
设备，以解决上述问题。
72.需要提前说明的是，本公开实施例中，不同的业务线、管理模式、工作模式、服务包、预约单、商家标签等一系列类型的集合构成不同的订单场景。示例性地，如图1所示，企客、加盟、驻点、专送、预约单以及茶饮ka可以构成一个订单场景，即时配、纯众包、区域送、混合送、非预约以及尾单可以构成另一个订单场景。
73.需要进一步说明的是，一个订单场景可以包括图1中所示出的部分类型的内容，例如，订单场景a只包括业务线、管理模式、工作模式、服务包、预约单这几个类型的内容，而不包括商家标签这个类型的内容。以及，一个订单场景包括的某个类型的内容存在多个内容，例如，订单场景b包括业务线、管理模式、工作模式、服务包、预约单以及商家标签这几个类型的内容，并且，在管理模式这个类型下，同时对应加盟和城市代理这两个内容。
74.下面结合具体实施方式对本公开实施例的时间统计规则加载方法进行详细说明。
75.请参阅图2，图2是根据本公开一示例性实施例示出的一种时间统计规则加载方法的流程图，如图2所示，该时间统计规则加载方法包括以下步骤：
76.s210，确定配置数据库发生配置变更，获取目标配置数据，目标配置数据包括订单场景与时间统计计算脚本之间的关联关系。
77.s120，基于目标配置数据进行缓存加载，得到加载后的时间统计规则缓存，其中，加载后的时间统计规则缓存用于调用与目标订单场景对应的目标时间统计计算脚本，以通过执行目标时间统计计算脚本来对目标订单场景下的配送订单进行时间统计计算。
78.本公开实施例中，可以先判断当前是否需要对时间统计规则进行缓存加载，当在确定配置数据库发生配置变更时，可以确定需要对时间统计规则进行缓存加载时，此时，便可以获取包括订单场景与时间统计计算脚本之间的关联关系的目标配置数据，并对目标配置数据进行缓存加载，将目标配置数据加载到缓存中，从而得到加载后的时间统计规则缓存。
79.在缓存中加载时间统计规则缓存之后，便可以在需要对目标订单场景下的配送订单进行时间统计计算的时候，基于加载后的时间统计规则缓存调用与目标订单场景对应的目标时间统计计算脚本，以通过执行目标时间统计计算脚本来对目标订单场景下的配送订单进行时间统计计算。
80.在一些实施方式中，在执行目标时间统计计算脚本来对目标订单场景下的配送订单进行时间统计计算之后，可以得到对应的时间统计结果，该时间统计结果可以用于各项业务考核。
81.采用上述方法，通过在缓存中加载时间统计计算脚本，使用时间统计计算脚本来替换传统的时间统计计算相关代码，由于计算脚本可以直接编辑替换计算公式，使得在确定配置数据库发生配置变更，需要修改时间统计计算规则时，只需要对缓存中的时间统计计算脚本进行更新即可，也即只需要将包括订单场景与时间统计计算脚本之间的关联关系的目标配置数据加载到缓存中，便可以迅速完成对时间统计计算规则的修改，并且由于脚本的更新过程也不需要经过标准的开发、测试、上线流程，因此，降低了时间统计方法更新维护难度，提高了时间统计计算方法的更新速度，并且，由于能够及时对不合适的时间统计方式进行调整更新，以提高时间统计的合理性，进而提高了骑手使用体验。
82.在一些可能的实施场景中，在时间统计系统上线一段时间之后，骑手可以上报当
前的时间统计系统存在不合理的情况，运维人员，例如产品经理可以在web端对需要修改的订单场景以及时间统计计算脚本之间的关联关系进行修改配置，在修改配置完成之后，发送到配置数据库进行保存，配置完成变更。从而，在确定配置数据库发生配置变更时，便可以获取到目标配置数据。在一些实施方式中，目标配置数据可以是配置数据库中的全部数据，也可以是配置数据库中相较于当前时刻缓存中加载的数据进行修改或者增加的数据。
83.在一些实施方式中，时间统计计算脚本可以是aviator，aviator是一个高性能、轻量级的java语言实现的表达式求值引擎，主要用于各种表达式的动态求值。aviator支持大部分运算操作符，包括算术操作符、关系运算符、逻辑操作符、正则匹配操作符(＝～)、三元表达式？:，并且支持操作符的优先级和括号强制优先级。
84.在一些实施方式中，时间统计计算脚本包括自定义计算项以及常规统计计算项。
85.其中，常规统计计算项例如可以是与eta(用户期望送达时间)、距离等订单属性相关的计算项，自定义计算项则是一些复杂属性的计算项，例如，可以自定义一个时间属性“eta+10秒”。本公开实施例中，通过在时间统计计算脚本中定义自定义计算项，可以扩展更加丰富的时间统计方式，满足不同的时间统计需求。
86.需要说明的是，确定配置数据库发生配置变更可以有多种不同的情况，因此，在一些实施方式中，确定配置数据库发生配置变更，获取目标配置数据的步骤可以包括：
87.响应于监听到配置数据库发生配置变更的消息，确定对时间统计规则进行缓存加载，并从配置数据库获取第一增量配置数据作为目标配置数据；或者
88.每间隔第一时间间隔，进行配置变更检测，并在检测结果为发生配置变更时，确定对时间统计规则进行缓存加载，并从配置数据库获取第二增量配置数据作为目标配置数据；
89.其中，增量数据为配置数据库中相较于配置缓存中变化的配置数据。
90.本公开实施例中，确定配置数据库发生配置变更，从而进行时间统计规则加载，可以有两种方法，监听变更加载以及版本比对加载。
91.本公开实施例中，当web端发生了配置变化，例如产品经理更新了包括订单场景与时间统计计算脚本之间的关联关系，其他服务可以监听到该配置变化的消息，例如，监听服务通过前述的版本号比对或者内容变化比对的方式，从而，在监听到配置数据库发生配置变更的消息时，可以确定对时间统计规则进行缓存加载，并从配置数据库获取第一增量配置数据作为目标配置数据。本公开实施例中，考虑到监听到的通常是部分数据的更新或者增加，因此，可以从配置数据库获取相较于配置缓存中变化的第一增量数据，来进行缓存加载。其中，第一增量数据可以理解为监听到配置变化时，配置数据库中相较于配置缓存中变化的配置数据。上述过程对应的是监听变更加载。
92.本公开实施例中，考虑到监听变更加载过程可能存在监听失败的场景，而没有及时拉取到第一增量数据的补充动作，因此，可以进一步设置版本比对加载。也即可以每隔第一时间间隔，进行配置变更检测，例如校验本地版本与配置数据库的版本是否一致，若不一致，则执行增量数据加载，也即，从配置数据库获取第二增量数据作为目标配置数据进行缓存加载。其中，第二增量数据可以理解为每隔第一时间间隔时刻，配置数据库中相较于配置缓存中变化的配置数据。
93.本公开实施例中，配置是否发生变更可以有多种方式确定。可选地，可以通过比对
前后版本号确定，例如，在web端发生了配置变更之后，可以在配置数据库填写对应的变更时间戳作为版本号，此外，除了可以用时间戳表示版本号之外，还可以用其他方式表示版本号，例如v1.0、v1.1、v2.0等，若前后版本号不同，则确定前后配置数据的内容发生变化，即发生配置变更。可选地，可以通过比对前后配置数据的内容是否发生变化确定，例如，计算前后配置数据的内容的哈希值是否相同，若前后哈希值不同，则确定前后配置数据的内容发生变化，即发生配置变更。
94.此外，除了可以在确定配置数据库发生配置变更时，确定对时间考核规则进行缓存加载，从而获取目标配置数据之外，缓存加载还可以包括另外两种情况，即启动加载以及定时加载。因此，在一些实施方式中，本公开实施例的方法还可以包括以下步骤：
95.在时间统计系统启动时，从配置数据库获取第一全量配置数据作为目标配置数据；或者
96.每间隔第二时间间隔，从配置数据库获取第二全量配置数据作为目标配置数据；
97.其中，全量数据为配置数据库中所有的配置数据。
98.本公开实施例中，考虑到时间统计计算规则都依赖于缓存，所以在时间统计系统启动的时候，可以确定对时间统计规则进行缓存加载，这个时候可以从配置数据库中获取全部数据，将全部数据缓存到本地缓存中，如果缓存发生了异常，则终止时间统计系统服务的启动。其中，第一全量数据可以理解为时间统计系统启动时配置数据库中的全部数据。上述过程对应的是启动加载。
99.此外，本公开实施例中，进一步考虑到监听变更加载过程可能存在监听失败的场景，而没有及时拉取到第一增量数据的补充动作，因此，还可以进一步设置定时加载过程。也即，可以每隔第二时间间隔，均确定对时间统计规则进行缓存加载，并进行一次全量数据的更新，也即每隔第二时间间隔，都从配置数据库获取第二全量数据作为目标配置数据来进行缓存加载，做整体的ab版本替换动作。其中，第二全量数据可以理解为每隔第二时间间隔的时刻配置数据库中的全部数据。
100.本公开实施例中，考虑到监听变更加载过程只是增量加载，加载本次变更的数据，可能会监听丢失，或可能会存在脏数据的可能，因此，有必要增加定时加载过程的全量加载，全量加载会重新覆盖数据，从而保障数据一致性。
101.在一些实施方式中，可以设置第二时间间隔大于第一第一时间间隔。通过设置定时加载的第二时间间隔大于版本比对加载的第一时间间隔，可以使得定时加载过程不至于太频繁，降低系统full gc过程。示例性地，第一时间间隔可以是分钟级别，例如1分钟、2分钟等时间间隔，第二时间间隔可以是6小时、1天等时间间隔。需要注意的是，第二时间间隔尽量不要设置的太大，如此可以保证数据拉取的时效性。
102.需要说明的是，在一些实施方式中，在上述4种缓存加载情况中，即在监听变更加载、启动加载、版本比对加载以及定时加载中，任一种加载类型条件满足时，均可以确定对时间统计规则进行缓存加载，并获取目标配置数据。然而，可以理解的是，在不同的加载类型下，基于不同的考虑，获取的目标配置数据不同。
103.结合前述内容可知，缓存加载可以包括监听变更加载、启动加载、版本比对加载以及定时加载4种情况，那么在不同的加载情况下，基于不同的考虑，基于目标配置数据进行缓存加载，得到加载后的时间统计规则缓存的具体过程可以不同。
104.在一些实施方式中，在确定配置数据库发生配置变更时，基于目标配置数据进行缓存加载，得到加载后的时间统计规则缓存可以包括以下步骤：
105.获取缓存加载过程对应的锁状态，锁状态包括运行状态以及空闲状态；
106.在锁状态为运行状态的情况下，确定当前正在运行的缓存加载过程对应的加载配置数据与目标配置数据之间的差异性；
107.在加载配置数据与目标配置数据存在差异的情况下，等待缓存加载过程结束，并在缓存加载过程结束之后，基于第一增量配置数据进行缓存加载，得到加载后的时间统计规则缓存。
108.本公开实施例中，考虑到存在4种缓存加载机制，每一种都可以带来缓存加载，因此，为了防止其他缓存加载的时候触发一些并发问题，可以为缓存加载过程设置锁机制，也即，当正在执行任一缓存加载过程时，可以将缓存加载过程设置为运行状态(running)，当没有在执行任何缓存加载过程时，可以将缓存加载过程设置为空闲状态(idleing)。
109.如图3所示，在监听变更加载过程中，可以首先获取缓存加载过程对应的锁状态，若锁状态为运行状态，说明有其他线程的缓存加载过程正在进行，此时，可以进一步判断当前正在运行的缓存加载过程正进行缓存加载的配置数据，即加载配置数据与目标配置数据之间是否存在差异，若存在差异，则说明两者缓存加载的内容不同，有必要进行目标配置数据的加载，这个时候，由于正存在其他线程的缓存加载过程，因此，可以等待其他线程的缓存加载过程结束之后，例如，可以通过自旋的方式等待其他线程释放状态锁之后，再基于第一增量配置数据进行缓存加载，得到加载后的时间统计规则缓存。
110.若不存在差异，则说明两个线程缓存加载的内容相同，无需再进行目标配置数据的加载，可以直接结束本次对目标配置数据进行的监听变更加载的过程。
111.其中，确定当前正在运行的缓存加载过程对应的加载配置数据与目标配置数据之间的差异性，同样可以通过判断版本号是否存在差异来进行确定，或者通过判断前后配置数据的内容是否相同来确定。
112.此外，继续如图3所示，在获取缓存加载过程对应的锁状态时，若锁状态为空闲状态，说明没有其他线程的缓存加载过程正在进行，不会触发并发问题，此时，可以直接基于第一增量配置数据进行缓存加载，得到加载后的时间统计规则缓存。
113.此外，考虑到版本比对加载执行较为频繁，更多的功能是作为补充校验在为缓存加载过程设置锁机制的情况下，同样可以在版本比对加载的具体过程中根据锁机制状态具体确定对应的加载过程，因此，在一些实施方式中，本公开实施例中的确定配置数据库发生配置变更，获取目标配置数据，可以包括以下步骤：
114.每间隔第一时间间隔，获取缓存加载过程对应的锁状态，锁状态包括运行状态以及空闲状态；在锁状态为空闲状态的情况下，进行配置变更检测；在配置变更检测的检测结果为发生配置变更时，确定配置数据库发生配置变更，并从配置数据库获取第二增量配置数据作为目标配置数据。
115.如图4所示，本公开实施例中，在每次第一时间间隔到来的时刻，即版本比对加载过程开始，可以先获取缓存加载过程对应的锁状态，若锁状态为运行状态，说明有其他线程的缓存加载过程正在进行，由于版本比对加载本身比较频繁，因此，这种情况下便可以不再去等待其他线程执行完缓存加载过程并更新锁状态，而是可以直接结束版本比对加载过
程。若锁状态为空闲状态，说明没有其他线程的缓存加载过程正在进行，此时，便可以进一步进行配置变更检测，并且在配置变更检测的检测结果为发生配置变更时，确定配置数据库发生配置变更，并从配置数据库获取第二增量配置数据作为目标配置数据，接着便可以基于目标配置数据进行缓存加载，得到加载后的时间统计规则缓存。
116.此外，考虑到定时加载是强制的保障数据一致性的过程，在为缓存加载过程设置锁机制的情况下，同样可以在定时加载的具体过程中根据锁机制状态具体确定对应的加载过程，因此，在一些实施方式中，确定配置数据库发生配置变更，获取目标配置数据，包括：每间隔第二时间间隔，从配置数据库获取第二全量配置数据作为目标配置数据。这种情况下，本公开实施例中的在确定对时间统计规则进行缓存加载时，获取目标配置数据，还可以包括以下步骤：
117.获取缓存加载过程对应的锁状态，锁状态包括运行状态以及空闲状态；
118.在锁状态为运行状态的情况下，等待缓存加载过程结束，并在缓存加载过程结束之后，基于第二全量配置数据进行缓存加载，得到加载后的时间统计规则缓存；
119.在锁状态为空闲状态的情况下，基于第二全量配置数据进行缓存加载，得到加载后的时间统计规则缓存。
120.本公开实施例中，考虑到定时加载是强制的保障数据一致性的过程，重要性较高，因此，可以在等到当前正在进行的缓存加载过程结束之后，或者在当前不存在缓存加载过程时，基于第二全量配置数据进行缓存加载。
121.下面对上述4种缓存加载过程进行总结性说明。
122.在基于目标配置数据进行缓存加载时，可以将锁状态设置为运行状态，以防止其他线程缓存加载触发并发问题，接着可以记录配置数据库的目标版本号，该目标版本号记录的是本次缓存加载后需要将本地的版本号替换为什么版本，接着引入随机10秒延迟作为消峰时间，以减少同一时间访问带来的并发问题，接着，便可以根据具体的缓存加载过程，从配置数据库拉取全量数据或者增量数据，并将拉取到的数据解析为缓存需要用到的格式，即解析为订单场景与时间统计计算脚本之间的关联关系，接着将该关联关系更新好本地缓存中，接着，便可以将本地的版本号更新为记录的目标版本号，最后释放锁，即将锁状态设置为空闲状态，从而完整了整个缓存加载过程。
123.在一些实施方式中，从配置数据库拉取增量数据的具体操作可以是将增量时间字段传入增量更新时间戳，从而获取增量数据，从配置数据库拉取全量数据的具体操作可以是将增量时间字段传入null，从而默认拉取全量数据。
124.在一些实施方式中，可以在客户端以及服务端中均设置时间统计规则，客户端以及服务端的时间统计规则可以是相同的，也可以是不相同的，而本公开实施例的时间统计规则加载方法可以应用于对服务端的时间统计规则进行加载，也可以应用于对客户端的时间统计规则进行加载。
125.当客户端以及服务端的时间统计规则不相同时，目标配置数据可以包括第一配置文件以及第二配置文件，基于目标配置数据进行缓存加载，包括：
126.将第一配置文件加载到服务端的缓存中以及将第二配置文件加载到客户端的缓存中；
127.服务端用于响应于针对目标配送订单发起的时间统计请求，通过服务端的缓存中
的时间统计规则缓存，调用与时间统计请求中的订单场景对应的时间统计计算脚本进行执行，得到针对目标配送订单的时间统计结果。
128.本公开实施例中，服务端以及客户端均为服务器，其中客户端可以是为各方主体用户(被服务的c端用户，被服务的b端商家客户以及提供服务的骑手)提供服务的服务器，服务端则相较于客户端提供全局服务的服务器。其中，客户端提供的服务以及服务端提供的服务均可以包括时间统计计算服务。
129.其中，第一配置文件可以理解为对服务端进行缓存加载用到的配置文件，第二配置文件可以理解为对客户端进行缓存加载用到的配置文件。因此，本公开实施例中，在基于目标配置文件进行缓存加载时，可以将第一配置文件加载到服务端的缓存中以及将第二配置文件加载到客户端的缓存中，从而完成整个的目标配置文件的加载过程。
130.从而，在将第一配置文件加载到服务端的缓存中以及将第二配置文件加载到客户端的缓存中之后，服务端以及客户端均可以用于对时间统计请求进行处理。提高了对时间统计请求进行处理的可靠性。
131.也就是说，当服务端接收到针对目标配送订单发起的时间统计请求之后，可以响应于该时间统计请求，通过自身缓存中的时间统计规则缓存，调用与时间统计请求中的订单场景对应的时间统计计算脚本进行执行，得到针对目标配送订单的时间统计结果。同样地，当客户端接收到针对目标配送订单发起的时间统计请求之后，也可以响应于该时间统计请求，通过自身缓存中的时间统计规则缓存，调用与时间统计请求中的订单场景对应的时间统计计算脚本进行执行，得到针对目标配送订单的时间统计结果。
132.此外，可以设置第一配置文件包括的时间统计计算脚本对应更加明确严谨的计算公式，可以通过调用非其他服务提供的接口、缓存来完成更加精确的时间统计的计算。而第二配置文件包括的时间统计计算脚本可以对应相对简单的计算公式，可以不需要依赖其他服务的信息。这种情况下，可以将客户端的时间统计规则缓存看作是兜底计算方案，因此，在一些实施方式中，在服务端计算目标配送订单对应的时间统计结果异常，或者在确定时间统计请求中的订单场景不存在对应的时间统计计算脚本的情况下，客户端用于根据自身缓存中的时间统计规则缓存，调用与时间统计请求中的订单场景对应的时间统计计算脚本进行执行，得到针对目标配送订单的时间统计结果。
133.本公开实施例中，为了保证计算准确性，可以优先选择服务端进行时间统计计算，而在一些情况下，不排除可能出现服务端发生不可用的紧急情况，例如在服务端计算目标配送订单对应的时间统计结果异常，或者在确定时间统计请求中的订单场景不存在对应的时间统计计算脚本的情况下，这种时候，为了能够得到时间统计计算结果，可以采用客户端的兜底方案，也即，可以通知客户端根据自身缓存中的时间统计规则缓存，调用与时间统计请求中的订单场景对应的时间统计计算脚本进行执行，得到针对目标配送订单的时间统计结果。
134.可以理解的是，上述过程中，是以服务端以及客户端中的时间统计规则加载过程的时机完全相同来进行说明的，在另一些实施方式中，服务端以及客户端中的时间统计规则加载过程的时机可以不完全相同。
135.示例性地，对于监听变更加载、启动加载以及版本比对加载，服务端与客户端可以设置为同步加载，也即，在监听到配置数据库发生配置变更时，或者在时间统计系统启动
时，或者在每隔第一时间间隔时，可以同步将第一配置文件加载到服务端的缓存中以及将第二配置文件加载到客户端的缓存中。而对于定时加载，考虑到由于存在监听变更加载，所以服务端的定时时间可以不必太频繁，例如可以设置为每6小时一次，并且考虑到客户端通常为兜底方案，所以客户端的定时时间也可以不必太频繁，并且可以大于服务端的定时时间，例如设置为24小时一次。
136.需要说明的是，本公开实施例的时间统计规则加载方法的执行主体可以是服务端，也可以是客户端，甚至还可以是区别于服务端和客户端的第三端。
137.可以理解的是，在各个端之间可能存在数据发送与接收的过程，这种情况下，可以通过远程过程调用接口(rpc接口)进行相关配置数据的接收与发送。
138.例如，当目标配置数据保存在服务端时，为了将第二配置文件加载到客户端的缓存中，服务端可以通过远程调用接口将第二配置文件发送给客户端，以使客户端将第二配置文件加载到缓存中。
139.又例如，当目标配置数据保存在第三端时，为了将第一配置文件加载到服务端的缓存中，服务端可以通过远程调用接口从第三端获取第一配置文件，并将第一配置文件加载到本地缓存中，为了将第二配置文件加载到客户端的缓存中，客户端可以通过远程调用接口从第三端获取第二配置文件，并将第二配置文件加载到本地缓存中。
140.下面结合图5对本公开实施例的一种可能的实施环境进行说明。如图5所示，本公开实施例的实施环境可以为时间统计系统，时间统计系统包括web端，服务端，与服务端连接的配置数据库以及客户端，其中，服务端以及客户端可以分别设置有计算引擎。
141.其中，web端提供统计规则的基础配置及审批相关动作，从而运维人员可以在web端对统计规则，即订单场景与时间统计计算脚本之间的关联关系进行编辑或者修改更新，从而将修改后的关联关系发送到配置数据库进行保存。
142.其中，计算引擎可以用于调用与目标订单场景对应的目标时间统计计算脚本，以通过执行目标时间统计计算脚本来对目标订单场景下的配送订单进行时间统计计算。
143.在时间统计系统启动时，或者在服务端监听到配置数据库发生配置变更的消息时，或者在每间隔第一时间间隔，进行配置变更检测，并在检测结果为发生配置变更时，或者在每间隔第二时间间隔时，服务器可以通过读取配置数据库dao的方式从配置数据库中获取相关的目标配置数据(该目标配置数据可以只包括第一配置文件，或者同时包括第一配置文件以及第二配置文件)，并通过服务端中的计算引擎将获取的目标配置数据加载到服务端的计算引擎缓存中，同时，客户端可以通过调用读取配置rpc接口，也通过读取配置数据库dao的方式从配置数据库中获取相关的目标配置数据(该目标配置数据可以只包括第二配置文件，或者同时包括第一配置文件以及第二配置文件)，并通过客户端中的计算引擎将通过读取配置rpc接口获取的目标配置数据加载到客户端的计算引擎缓存中，至此，便完成了将第一配置文件加载到服务端的缓存中以及将第二配置文件加载到客户端的缓存中。
144.此外，在一些实施方式中，图5中web端的接口中可以包括写入配置http接口，服务端中可以包括保存数据冲突校验rpc接口，从而通过写入配置http接口调用保存数据冲突校验rpc接口，可以实现对配置数据库中文件进行准确性校验。
145.下面，继续结合图5所示的实施环境以及图6所示的流程示意图，对应用本公开实
施例的时间统计计算脚本对目标订单场景下的配送订单进行时间统计计算的过程进行示例性说明。
146.如图6所示，在将第一配置文件加载到服务端的缓存中以及将第二配置文件加载到客户端的缓存中之后，服务端可以接收对目标订单场景下的配送订单进行时间统计计算的请求，然后服务端中的计算引擎可以对时间统计计算请求进行参数拆解，转化为内部对象结构以及计算参数，接着，服务端中的计算引擎可以对内部对象结构进行类型识别，得到各个类型下的内容，进而可以根据各个类型下的内容确定订单场景，沿用前述示例，假设拆解并识别得到企客(企业客户)、加盟、驻点、专送、预约单以及茶饮ka，根据这几个内容得到订单场景x，接着，服务端中的计算引擎可以遍历时间统计规则缓存，假设遍历可以得到与订单场景x对应的时间统计计算脚本x(进一步假设时间统计计算脚本x包括自定义计算项以及常规统计计算项)，接着，便可以根据计算参数首先计算出自定义计算项，接着再将自定义计算项以及常规统计计算项以及对应的计算参数一起放入脚本执行器中执行，最终服务端中的计算引擎便可以获取到脚本执行器的执行结果，并将执行结果作为对目标订单场景下的配送订单进行时间统计计算的计算结果。
147.在一些情况下，上述过程中，在根据各个类型下的内容确定订单场景时，不能确定到对应的订单场景，或者，在将将自定义计算项以及常规统计计算项以及对应的计算参数一起放入脚本执行器中执行的时候，出现了执行异常，这些情况下，可以通知客户端中的计算引擎对目标订单场景下的配送订单进行时间统计计算的请求进行处理，其中，客户端中的计算引擎对目标订单场景下的配送订单进行时间统计计算的请求进行处理的过程与服务端中的计算引擎对目标订单场景下的配送订单进行时间统计计算的请求进行处理的过程大致相同，仅仅是时间统计计算脚本不同，因此，相关过程可以参考服务端中的计算引擎对目标订单场景下的配送订单进行时间统计计算的请求进行处理的过程，此处不再赘述。
148.图7是根据本公开一示例性实施例示出的一种时间统计规则加载装置的框图，如图7所示，该装置700包括：
149.目标配置数据获取模块710，被配置为用于确定配置数据库发生配置变更，获取目标配置数据，所述目标配置数据包括订单场景与时间统计计算脚本之间的关联关系；
150.缓存加载模块720，被配置为用于基于所述目标配置数据进行缓存加载，得到加载后的时间统计规则缓存，其中，加载后的时间统计规则缓存用于调用与目标订单场景对应的目标时间统计计算脚本，以通过执行所述目标时间统计计算脚本来对所述目标订单场景下的配送订单进行时间统计计算。
151.可选地，目标配置数据获取模块710，包括：
152.第一获取子模块，被配置为用于响应于监听到配置数据库发生配置变更的消息，确定所述配置数据库发生配置变更，并从所述配置数据库获取第一增量配置数据作为所述目标配置数据；
153.第二获取子模块，被配置为用于每间隔第一时间间隔，进行配置变更检测，并在检测结果为发生配置变更时，确定对所述时间统计规则进行缓存加载，并从所述配置数据库获取第二增量配置数据作为所述目标配置数据；
154.其中，所述增量数据为所述配置数据库中相较于配置缓存中变化的配置数据。
155.可选地，所述装置700还包括：
156.第三获取子模块，被配置为用于在时间统计系统启动时，确定对所述时间统计规则进行缓存加载，并从所述配置数据库获取第一全量配置数据作为所述目标配置数据；
157.第四获取子模块，被配置为用于每间隔第二时间间隔，确定对所述时间统计规则进行缓存加载，并从所述配置数据库获取第二全量配置数据作为所述目标配置数据；
158.其中，所述全量数据为所述配置数据库中所有的配置数据。
159.可选地，所述缓存加载模块720包括：
160.第一锁状态获取子模块，被配置为用于获取缓存加载过程对应的锁状态，所述锁状态包括运行状态以及空闲状态；
161.第一差异性确定子模块，被配置为用于在所述锁状态为运行状态的情况下，确定当前正在运行的缓存加载过程对应的加载配置数据与所述目标配置数据之间的差异性；
162.第一缓存加载子模块，被配置为用于在所述加载配置数据与所述目标配置数据存在差异的情况下，等待所述缓存加载过程结束，并在所述缓存加载过程结束之后，基于所述第一增量配置数据进行缓存加载，得到加载后的时间统计规则缓存；
163.第二缓存加载子模块，被配置为用于在所述锁状态为空闲状态的情况下，基于所述第一增量配置数据进行配置缓存加载，得到加载后的时间统计规则缓存。
164.可选地，目标配置数据获取模块710，还包括：
165.第五获取子模块，被配置为用于每间隔第一时间间隔，获取缓存加载过程对应的锁状态，所述锁状态包括运行状态以及空闲状态；在所述锁状态为空闲状态的情况下，进行配置变更检测；在所述配置变更检测的检测结果为发生配置变更时，配置数据库发生配置变更，并从配置数据库获取第二增量配置数据作为所述目标配置数据。
166.可选地，所述目标配置数据包括第一配置文件以及第二配置文件，缓存加载模块720，还包括：
167.第三缓存加载子模块，被配置为用于将所述第一配置文件加载到服务端的缓存中以及将所述第二配置文件加载到客户端的缓存中；
168.所述服务端用于响应于针对目标配送订单发起的时间统计请求，通过所述服务端的缓存中的时间统计规则缓存，调用与所述时间统计请求中的订单场景对应的时间统计计算脚本进行执行，得到针对所述目标配送订单的时间统计结果。
169.可选地，在所述服务端计算所述目标配送订单对应的时间统计结果异常，或者在确定所述时间统计请求中的订单场景不存在对应的时间统计计算脚本的情况下，所述客户端用于根据自身缓存中的时间统计规则缓存，调用与所述时间统计请求中的订单场景对应的时间统计计算脚本进行执行，得到针对所述目标配送订单的时间统计结果。
170.关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
171.图8是根据一示例性实施例示出的一种电子设备800的框图。例如，电子设备800可以被提供为一服务器。参照图8，电子设备800包括处理器822，其数量可以为一个或多个，以及存储器832，用于存储可由处理器822执行的计算机程序。存储器832中存储的计算机程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理器822可以被配置为执行该计算机程序，以执行上述的时间统计规则加载方法。
172.另外，电子设备800还可以包括电源组件826和通信组件850，该电源组件826可以
被配置为执行电子设备800的电源管理，该通信组件850可以被配置为实现电子设备800的通信，例如，有线或无线通信。此外，该电子设备800还可以包括输入/输出(i/o)接口858。电子设备800可以操作基于存储在存储器832的操作系统，例如windows server
tm
，mac os x
tm
，unix
tm
，linux
tm
等等。
173.在另一示例性实施例中，还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现上述的时间统计规则加载方法的步骤。例如，该计算机可读存储介质可以为上述包括程序指令的存储器832，上述程序指令可由电子设备800的处理器822执行以完成上述的时间统计规则加载方法。
174.在另一示例性实施例中，还提供一种计算机程序产品，该计算机程序产品包含能够由可编程的装置执行的计算机程序，该计算机程序具有当由该可编程的装置执行时用于执行上述的时间统计规则加载方法的代码部分。
175.以上结合附图详细描述了本公开的优选实施方式，但是，本公开并不限于上述实施方式中的具体细节，在本公开的技术构思范围内，可以对本公开的技术方案进行多种简单变型，这些简单变型均属于本公开的保护范围。
176.另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合。为了避免不必要的重复，本公开对各种可能的组合方式不再另行说明。
177.此外，本公开的各种不同的实施方式之间也可以进行任意组合，只要其不违背本公开的思想，其同样应当视为本公开所公开的内容。