脚本处理方法和脚本处理装置

摘要

本发明提供一种脚本处理方法和一种脚本处理装置。其中，脚本处理方法包括：步骤102，从脚本中解析出表达式，并根据运算性质，将表达式分类，以及获取表达式之间的依赖关系；步骤104，根据表达式的类别以及依赖关系，对表达式进行分批，并确定每批次表达式的执行顺序；步骤106，按执行顺序执行每批次表达式，取得每批次表达式的运算结果；步骤108，将所有批次表达式的运算结果返回给脚本，以获取脚本的运算结果。通过本发明，对表达进行分批，每批次表达式可以一次计算出结果，不会因需依赖其他表达式，而不能计算出结果或者增加后台实现的复杂程度。

说明书

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种脚本处理方法和一种脚本处理装置。

背景技术

在网络分布式计算的环境下，运行在一台机器的上程序需要调用运行在另外一台计算机上的子程序，这个过程被称为远端程序调用。一般发起调用的程序称为客户端，而远程计算机的程序被称为服务器。远端程序调用的时间开销，即从调用发起开始到获取到返回值所花费的时间，等于被调用程序运行所花的时间再加上数据在两台计算机之间传递所花费的时间。

根据这两项时间占总的时间开销的比例，可以把远端程序调用分成三类，一类是运算密集型，即程序运行时间占大部分比例；另一类是数据密集型，即数据传输的时间占较大比例；最后一类是平均型，即二者比例相当。

在互联网环境下，两台计算机的物理距离可能相隔遥远，其网络状况速度也往往不很理想。怎样降低上述列举的后两种类型的远端程序调用的时间开销是一个值得研究的问题。

常见的程序都存在一类需要反复被调用且返回来的数据量会比较大的远端过程。比如说：一个销售终端程序需要经常调用服务器上的商品库存情况查询程序，以得到商品的库存信息。这类反复调用且数据量又很大的远端过程都属于前述的后两种类型的远程调用。其程序运行的时间已经很难降低，所以解决问题的入口就是降低数据传输时间。

为了降低数据传输时间，一个有效的办法是在客户端做一个缓存，把调用返回来的结果保存下来。如果下次还需要调用同样的远端过程，就直接利用上次保存的结果就好了，不用再去和另外一台计算机通信了，这样提高了程序的运行效率。

但是缓存的方法存在局限性，那就是：对于不经常变化的非交易型数据，配合一些精细设计的缓存同步和更新方法，可以很好的保证数据实时性、一致性及完整性，从而有效的控制远程调用的发生，提高远端程序调用的效率。但是实际的业务场景中存在大量的交易型数据，这些数据具备两个特征：

一是会频繁的随业务发生变化，比如销售系统中的销售订单；

二是数据量非常大，比如电信系统里的用户通话明细记录。

这两个特征会导致缓存交易型的数据非常困难，如果要保证数据实时性和一致性，那么就必须频繁的做数据同步；而如果要保证数据完整性，则客户端会使用到的数据都必须进行同步，缓存的数据量会急剧增长，一般来说客户端的内存相对有限，急剧增加的缓存数据会引起内存问题，另外客户端缓存数据查询一般来说都采用的是轻量级数据库实现，所以随着数据量的增长，查询效率会急剧下降，最终导致缓存失效。

另一方面，为提高客户端界面的交互性，增加客户端界面的动态可配置性，以满足各种客户的应用需求，脚本技术常常被引入到客户端的界面配置中，可在产品实施阶段修改脚本实现业务规则的变化。这些脚本不可避免的要从服务端获取数据，产生远程调用。

因为上述原因，目前的各种技术方案中一般不会对交易型数据进行缓存，这样一来，客户端在需要查询交易型数据时就不可避免的产生远程调用，尤其是一些在客户端通过脚本方式动态组织数据的场景，远程调用次数随着业务复杂度的提高会快速增长，客户端进行远端调用的时间相应增加，导致用户体验效果不佳。

因此，需求一种适用于针对大量数据传输的处理方案，尤其适用于处理交易型数据，既不需要其在远端调用过程占用大量的时间和资源，又不必占用大量内存空间保存调用的结果数据，且能够保证所需数据的准确性。

发明内容

本发明所要解决的技术问题在于，提供一种适用于针对大量数据传输的处理方案，尤其适用于处理交易型数据，既不需要其在远端调用过程占用大量的时间和资源，又不必占用大量内存空间保存调用的结果数据，且能够保证所需数据的准确性。

有鉴于此，本发明提供一种脚本处理方法，包括：步骤102，从脚本中解析出表达式，并根据运算性质，将表达式分类，以及获取表达式之间的依赖关系；步骤104，根据表达式的类别以及依赖关系，对表达式进行分批，并确定每批次表达式的执行顺序；步骤106，按执行顺序执行每批次表达式，取得每批次表达式的运算结果；步骤108，将所有批次表达式的运算结果返回给脚本，以获取脚本的运算结果。通过该技术方案，对表达进行分批，每批次表达式可以一次计算出结果，不会因需依赖其他表达式，而不能计算出结果或者增加后台计算结果的复杂程度。

在上述技术方案中，优选地，运算性质包括：表达式是否需要进行数据查询；表达式需要进行数据查询时，数据查询是否是基于缓存进行查询。

在上述技术方案中，优选地，步骤106具体包括：对于每批次表达式，判断其中每个表达式是否需要进行数据查询，在判断结果为否时，直接计算每个表达式的运算结果，否则判断数据查询是否是基于缓存进行查询，在判断结果为是时，基于缓存进行数据查询，并根据查询结果计算每个表达式的运算结果，否则提取每个表达式的查询参数，并基于每个表达式的查询参数进行远程数据查询，并根据查询结果计算每个表达式的运算结果。

在上述技术方案中，优选地，基于每个表达式的查询参数进行远程数据查询具体包括：在每批次表达式的所有查询参数中，按预定条件进行一组或多组查询参数的合并，并基于合并后的查询参数进行远程的批量数据查询。通过该技术方案，合并查询参数进行数据查询，可以减少查询次数，提高查询效率。

在上述技术方案中，优选地，还包括：建立复合区域，以存储每批次表达式，其中，复合区域按每批次表达式的类别，将其分组存储。

本发明还提供一种脚本处理装置，包括：脚本解析模块，从脚本中解析出表达式，并根据运算性质，将表达式分类，以及获取表达式之间的依赖关系；批次处理模块，根据表达式的类别以及依赖关系，对表达式进行分批，并确定每批次表达式的执行顺序；结果计算模块，按执行顺序执行每批次表达式，取得每批次表达式的运算结果；结果返回模块，将所有批次表达式的运算结果返回给脚本，以获取脚本的运算结果。通过该技术方案，对表达进行分批，每批次表达式可以一次计算出结果，不会因需依赖其他表达式，而不能计算出结果或者增加后台计算结果的复杂程度。

在上述技术方案中，优选地，在上述技术方案中，优选地，运算性质包括：表达式是否需要进行数据查询；表达式需要进行数据查询时，数据查询是否是基于缓存进行查询。

在上述技术方案中，优选地，结果计算模块对于每批次表达式，判断其中每个表达式是否需要进行数据查询，在判断结果为否时，直接计算每个表达式的运算结果，否则判断数据查询是否是基于缓存进行查询，在判断结果为是时，基于缓存进行数据查询，并根据查询结果计算每个表达式的运算结果，否则提取每个表达式的查询参数，并基于每个表达式的查询参数进行远程数据查询，并根据查询结果计算每个表达式的运算结果。

在上述技术方案中，优选地，结果计算模块在每批次表达式的所有查询参数中，按预定条件进行一组或多组查询参数的合并，并基于合并后的查询参数进行远程的批量数据查询。通过该技术方案，合并查询参数进行数据查询，可以减少查询次数，提高查询效率。

在上述技术方案中，优选地，批次处理模块还建立复合区域，以存储每批次表达式，其中，复合区域按每批次表达式的类别，将其分组存储。

根据以上技术方案，可以实现一种脚本处理方法和一种脚本处理装置，适用于针对大量数据传输，尤其适用于处理交易型数据，既不需要其在远端调用过程占用大量的时间和资源，又不必占用大量内存空间保存调用的结果数据，且能够保证所需数据的准确性。

附图说明

图1是根据本发明的一个实施例的脚本处理方法的流程图；

图2是根据本发明的一个实施例的脚本处理装置的框图；

图3是根据本发明的一个实施例的脚本处理装置的原理示意图；

图4是根据本发明的一个实施例的脚本处理装置的单个模块的工作流程图；

图5是根据本发明的一个实施例的脚本处理装置中采用的复合区域的示意图；

图6是根据本发明的一个实施例的脚本处理装置的单个模块的工作流程图；

图7是根据本发明的一个实施例的脚本处理装置进行表达式分批处理的示意图；

图8是根据本发明的一个实施例的脚本处理装置的单个模块的工作流程图；

图9是根据本发明的一个实施例的脚本处理装置的单个模块的工作流程图；

图10是根据本发明的一个实施例的脚本处理装置的单个模块的工作流程图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明并不限于下面公开的具体实施例的限制。

图1是根据本发明的一个实施例的脚本处理方法的流程图。

如图1所示，本发明提供一种脚本处理方法，包括：步骤102，从脚本中解析出表达式，并根据运算性质，将表达式分类，以及获取表达式之间的依赖关系；步骤104，根据表达式的类别以及依赖关系，对表达式进行分批，并确定每批次表达式的执行顺序；步骤106，按执行顺序执行每批次表达式，取得每批次表达式的运算结果；步骤108，将所有批次表达式的运算结果返回给脚本，以获取脚本的运算结果。通过该技术方案，对表达进行分批，每批次表达式可以一次计算出结果，不会因需依赖其他表达式，而不能计算出结果或者增加后台计算结果的复杂程度。

在上述技术方案中，运算性质包括：表达式是否需要进行数据查询；表达式需要进行数据查询时，数据查询是否是基于缓存进行查询。

在上述技术方案中，步骤106具体包括：对于每批次表达式，判断其中每个表达式是否需要进行数据查询，在判断结果为否时，直接计算每个表达式的运算结果，否则判断数据查询是否是基于缓存进行查询，在判断结果为是时，基于缓存进行数据查询，并根据查询结果计算每个表达式的运算结果，否则提取每个表达式的查询参数，并基于每个表达式的查询参数进行远程数据查询，并根据查询结果计算每个表达式的运算结果。

在上述技术方案中，基于每个表达式的查询参数进行远程数据查询具体包括：在每批次表达式的所有查询参数中，按预定条件进行一组或多组查询参数的合并，并基于合并后的查询参数进行远程的批量数据查询。通过该技术方案，合并查询参数进行数据查询，可以减少查询次数，提高查询效率。

在上述技术方案中，还包括：建立复合区域，以存储每批次表达式，其中，复合区域按每批次表达式的类别，将其分组存储。

图2是根据本发明的一个实施例的脚本处理装置的框图。

如图2所示，本发明还提供一种脚本处理装置200，包括：脚本解析模块202，从脚本中解析出表达式，并根据运算性质，将表达式分类，以及获取表达式之间的依赖关系；批次处理模块204，根据表达式的类别以及依赖关系，对表达式进行分批，并确定每批次表达式的执行顺序；结果计算模块206，按执行顺序执行每批次表达式，取得每批次表达式的运算结果；结果返回模块208，将所有批次表达式的运算结果返回给脚本，以获取脚本的运算结果。通过该技术方案，对表达进行分批，每批次表达式可以一次计算出结果，不会因需依赖其他表达式，而不能计算出结果或者增加后台计算结果的复杂程度。

在上述技术方案中，在上述技术方案中，优选地，运算性质包括：表达式是否需要进行数据查询；表达式需要进行数据查询时，数据查询是否是基于缓存进行查询。。

在上述技术方案中，结果计算模块206对于每批次表达式，判断其中每个表达式是否需要进行数据查询，在判断结果为否时，直接计算每个表达式的运算结果，否则判断数据查询是否是基于缓存进行查询，在判断结果为是时，基于缓存进行数据查询，并根据查询结果计算每个表达式的运算结果，否则提取每个表达式的查询参数，并基于每个表达式的查询参数进行远程数据查询，并根据查询结果计算每个表达式的运算结果。

在上述技术方案中，结果计算模块206在每批次表达式的所有查询参数中，按预定条件进行一组或多组查询参数的合并，并基于合并后的查询参数进行远程的批量数据查询。通过该技术方案，合并查询参数进行数据查询，可以减少查询次数，提高查询效率。

在上述技术方案中，批次处理模块204还建立复合区域，以存储每批次表达式，其中，复合区域按每批次表达式的类别，将其分组存储。

图3是根据本发明的一个实施例的脚本处理装置的原理示意图。

如图3所示，从本实施例中的脚本处理装置的工作流程上看，其主要包含以下4个部分：

1.客户端脚本解析器302：负责解析客户端脚本，形成表达式，分析表达式间的依赖关系，根据表达式性质(本地运算、缓存运算或者需要远程调用)及依赖关系对表达式进行分批。

2.客户端批量调用代理模块304：根据依赖关系按顺序执行分批过的表达式，并负责各批次表达式间变量的传递管理。对于一般运算表达式(即不需要执行数据查询的表达式)直接在客户端执行即可，对于可以在前台缓存查询的数据，则在前台缓存查询，这两种情况均可不进行批量处理；关键是对于那些需要从服务端查询的表达式，需要准备好批量调用参数，实现批调用。

3.服务端批量调用实现模块306：可根据准备好的调用参数，适配到持久层进行批量查询。

4.运算结果合并模块308：将各批次表达式执行结果分发到脚本执行引擎中，从脚本引擎的层面来看，批量远程调用的过程是透明的。

以下对上述各模块进行详细说明：

1.客户端脚本解析器302：

脚本的基本构成元素：表达式，常量，变量，函数，操作符；

例如，对于下面的一段脚本：

1)VAR_A＝VAR_N1+FUN_L1(“234.12”)；

2)VAR_B＝FUN_QUERY(“gl_voucher”，“creditmny”，“voucher_code”，VAR_A)+“元”；

3)VAR_C＝FUN_R2(VAR_B)+FUN_R3(VAR_B，VAR_A)；

4)VAR_D＝FUN_QUERY(“bd_person”，“personname”，“personcode”，VAR_PCODE)；

其中，每一行整体称作表达式；

VAR_A，VAR_N1，VAR_B，VAR_C，VAR_PCODE均为变量；

“gl_voucher”，“creditmny”，“voucher_code”，“元”为常量；

FUN_L1()，FUN_QUERY()，FUN_R2()，FUN_R3()均为函数；

“+”为操作符。

依赖关系分析：

上面的脚本包含的四个表达式，假设其对应序号依次为：E1，E2，E3，E4。

E2里引用了VAR_A变量，我们称E2依赖了E1，同理E3依赖了E1和E2，E4则不依赖其他表达式。

图4详细介绍了客户端脚本解析器302的工作原理。

如图4所示，在步骤402，客户端脚本解析器302接受客户端脚本，通过脚本相关的解析器进行解析，可以将每个表达式都解析为树形结构，并最终得到树形结构的表达式集合。

步骤404，脚本解析器302循环处理表达式集合里的每一个表达式，判断其是否为一般运算表达式，即不需要进行数据查询，如果是，则加入到前台运算队列；如果否，则判断该表达式涉及到的查询运算是否都可以通过缓存查询，如果是，则一样加入到前台运算队列，如果判断结果为否，则将该表达式加入到远程运算队列。

步骤406，成功得到前台运算队列及远程运算队列之后，脚本解析器302需要分析表达式的依赖关系。此处理流程中依赖分析是关键，根据依赖关系的复杂程度，最终得到的可分批运算队列可能为2批，也可能为n批，其中(n＞2)。在客户端脚本中，确定前台运算队列及远程运算队列后，依赖情况一般分为三种情况：

1)无依赖关系：

前台运算队列里的所有表达式和远程运算队列里的表达式之间没有直接的依赖关系，此时得到的分批队列直接分为两个批次即可；

2)简单依赖(无交叉)：

前台运算队列里的表达式和远程运算队列里的表达式之间存在简单的依赖关系，即前台运算队列里的表达式依赖远程运算队列里的表达式，或者远程运算队列里的表达式依赖前台运算队列里的表达式，此时根据其依赖关系确定分批表达式的顺序即可；

3)交叉依赖：

前台运算队列里的表达式和远程运算队列里的表达式之间存在交叉依赖，即前台运算队列的表达式依赖远程运算队列表达式的同时，远程运算队列的表达式也依赖前台运算队列里的表达式，此时需要拆分为多个批次，分批按顺序执行。

为解决交叉依赖，我们引入复合区域，如图5所示，复合区域包含两个子区域，分别用于存放来自前台队列里的表达式以及来自远程队列里的表达式。交叉依赖的场景最终会得到多个有顺序的复合区域。

脚本解析器302根据复合区域进行依赖分析以对表达式分析的流程图如图6所示。

步骤602，首先得到前台运算队列和远程运算队列，要初始化第一个复合区域，位置为1，如前所述，复合区域上半部存放远程运算队列的表达式，下半部存放前台运算队列的表达式。

步骤604，将前台运算队列和远程运算队列中的每一个表达式，记为Ei，根据表达式中的变量，获取该表达式所依赖的所有表达式。

对Ei依赖的每一个表达式，在已经建立的复合区里搜索，判断是否已经存在，如果已经存在则记录下所属复合区域的位置，记为topN，否则可直接略过继续处理下一个依赖的公式。

Ei所有依赖的表达式处理完毕后，如果Ei属于前台运算队列，则加入到第topN个复合区域的下半部，如果不是，则在topN之上再新创建一个复合区域，位置为topN+1，并将Ei加入到新区域的上半部。

步骤606，最后根据复合区域的顺序，得到所有分批的运算表达式。

根据以上步骤的一个示例如下：

假如现在前台运算队列里有表达式E1、E2、E5，远程运算队列里有表达式E3、E4、E6、E7。依赖关系为：

E2→E6

E3→E1

E6→E5

E5→E2

则根据图6所示的依赖关系分析过程，复合区域形成的过程可以如如图7所示。

2.客户端批量调用代理模块304：

如图8所示，客户端批量调用代理模块304根据已经分批的表达式，需要按批进行处理。

步骤802，首先对其中的每一个表达式，判断其是否无数据查询，如果是，则直接调用脚本引擎的一般运算，否则判断是否可以从缓存查询，如果是，则基于缓存查询数据，这在引擎实现上还是一个一般性运算；如果以上都不是，则延迟引擎计算，提取查询参数。

步骤804，一次批次收集完，需要进行参数合并，对具有相同查询条件，相同表的查询进行合并。

步骤806，基于合并完的参数进行批量远程调用，得到该批次的远程调用结果。

步骤808，将该批次的远程调用结果更新到引擎的变量表。

按照以上逻辑，循环运算各个批次的表达式。

3.批量调用服务端实现模块306：

批量调用服务端实现模块306实现的远程调用如图9所示。该模块在服务端，根据不同的容器，比如Spring IOC，EJB，普通java，web打包应用等，相应的实现一个简单的无侵害的查询模块。

步骤902，首先根据合并后的参数形成适合特定容器持久层接口的查询；

步骤904，调用相应持久层接口进行查询，得到批量查询结果。

4.查询结果分发模块308：

查询结果分发模块308主要负责将各批次表达式执行结果分发到脚本执行引擎中，从脚本引擎层面来看，批量远程调用是透明的。流程图如图10所示。

步骤1002，首先从服务端得到批量执行的结果，然后对每一个查询结果，找到关联的表达式；

步骤1004，替换相应的在客户端批量调用代理装置被延迟运算的函数节点；

步骤1006，调用引擎进行一般性的运算，得到表达式的值，更新引擎变量表，循环完毕，最终得到脚本运算结果。

以上技术方案在实际应用中，效果如下：

经过大型ERP软件产品的验证，采用本发明技术后，客户端的调用次数明显下降，客户端业务操作效率明显提高。

值得一提的是，上表显示的效率优化结果是在前台缓存数据量较低的情况下取得的，更加凸显本发明的技术方案所带来的优化效果。

根据本发明的技术方案，可以实现一种脚本处理方法和一种脚本处理装置，可以有效地改进有实时性要求的数据密集型远程调用的效率，有效的解决了非交易型数据在无法缓存的情况下频繁产生远程调用的问题。其中，本发明的技术方案提供了用于客户端脚本解析和分析的方法和模块，不要求对客户端脚本做任何修改，大量存在的客户端脚本可保持不变，另外服务端只需外用于加批量调用执行的模块，对原有代码无任何侵入性，因此本发明的技术方案可迅速在各种客户端/服务端架构中应用。另外，本发明的技术方案能有效的分析出可合并的非交易型数据查询，客户端和服务端之间的远程调用数量急剧减少，提高了客户端操作的响应速度，给用户带来更流畅的体验效果。再者，本发明有广泛的适用性。只要客户端脚本符合本发明提到的脚本模型结构，本发明的技术方案都可以适用。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。