一种订单处理方法及装置与流程

本发明涉及订单处理技术，尤其涉及一种订单处理方法及装置。

背景技术：

随着互联网技术的发展，互联网电商推出一种秒杀营销模式，秒杀就是大量用户同时抢购同一种商品，在短时间内大量用户同时进行购买，造成服务器的访问量瞬间变大，很容易出现“超卖”现象。

目前有关秒杀的技术大多是采用虚拟库存方式进行分库处理，具体方案是：首先，将库存数据按照库存分配策略划分为一个预留仓和多个虚拟仓；系统接收到用户创建的订单请求后，当订单队列监控以及动态虚拟库存分仓模块判断需要对虚拟仓的数量进行调整时，调用数据库存存储过程功能模块的相关存储过程实现对虚拟仓数量的调整；接下来，根据订单明细中是否包含紧缺产品和当前系统是否启用了虚拟库存方案，确定当前订单处理是扣减预留仓库存还是扣减虚拟仓库存；若虚拟仓库存足够，则选择扣减虚拟仓库存，由虚拟仓选择计数器以轮询方式为每个订单分配虚拟仓，订单根据分配的虚拟仓进行库存扣减处理，扣减库存成功后，将订单创建成功的消息返回用户。由上述可知，采用虚拟库存方式进行分库处理的方法并不能解决在秒杀瞬间高并发的购买请求造成的“超卖”现象，同时，虚拟仓的库存扣减处理需要对数据库进行直接操作，而频繁对数据库的进行直接操作容易对数据库的性能产生不良影响。

因此，如何在秒杀过程中解决高并发的购买请求造成的“超卖”现象，同时，在订单处理过程中，避免频繁对数据库进行直接操作是目前待解决的问题。

技术实现要素：

为解决上述技术问题，本发明实施例期望提供一种订单处理方法及装置， 能够解决在秒杀过程中高并发的购买请求导致的“超卖”现象，同时，在订单处理过程中避免频繁对数据库进行直接操作，以免对数据库的性能产生不良影响。

本发明的技术方案是这样实现的：

第一方面，本发明实施例提供了一种订单处理的方法，所述方法包括：

当接收到的购买请求满足预设的验证条件时，按照显示库存数，对全部满足所述验证条件的购买请求数量进行第一级限制，得到第一级限制后的所述购买请求；

按照扣减库存数，对第一级限制后的所述购买请求数量进行第二级限制，得到不超过真实库存数量的所述购买请求；

按照不超过真实库存数量的所述购买请求，对数据库中的库存数进行更新处理。

在上述方案中，所述购买请求，包括：

所述购买请求的发送源地址标识、所述购买请求的访问时间和所述购买请求的用户标识。

在上述方案中，所述购买请求满足预设的验证条件，包括：

所述购买请求满足购买条件，且所述购买请求通过权限验证。

在上述方案中，所述购买请求满足购买条件，包括：

当使用同一发送源地址标识的购买请求的访问次数不超过阈值，且所述购买请求的访问时间离抢购开始时间的间隔小于一分钟时，所述购买请求满足抢购条件；

或，当使用同一发送源地址标识的购买请求的访问次数超过两次，但所述两次购买请求的访问时间的间隔大于五分钟时，所述购买请求满足购买条件。

在上述方案中，所述购买请求通过权限验证，包括：

当所述购买请求中的用户标识与预存的具有参与抢购权限的用户标识相匹配时，所述购买请求通过权限验证；

当所述购买请求中的用户标识与所述预存的具有参与抢购权限的用户标识 不匹配时，所述购买请求没有通过权限验证。

在上述方案中，所述按照显示库存数，对全部满足所述验证条件的购买请求数量进行第一级限制，得到第一级限制后的所述购买请求，包括：

将全部满足所述验证条件的购买请求放入第一缓存，并获取所述第一缓存中所述购买请求数量；

当显示库存数大于0时，按照所述第一缓存中所述购买请求数量，对所述显示库存数进行扣减处理；

得到扣减处理成功的所述购买请求，并更新所述显示库存数。

在上述方案中，所述按照扣减库存数，对第一级限制后的所述购买请求数量进行第二级限制，得到不超过真实库存数量的所述购买请求，包括：

将在第一缓存中扣减处理成功的所述购买请求放入第二缓存，并获取所述第二缓存中所述购买请求数量；

当扣减库存数大于0时，按照所述第二缓存中所述购买请求数量，对所述扣减库存数进行扣减处理；

得到不超过真实库存数量的所述购买请求，并更新所述扣减库存数。

第二方面，本发明实施例提供了一种订单处理的装置，包括：第一限制单元、第二限制单元和更新单元；其中，

所述第一限制单元，用于当接收到的购买请求满足预设的验证条件时，按照显示库存数，对全部满足所述验证条件的购买请求数量进行第一级限制，得到第一级限制后的所述购买请求；

所述第二限制单元，用于按照扣减库存数，对所述第一限制单元处理后的所述购买请求数量进行第二级限制，得到不超过真实库存数量的所述购买请求；

所述更新单元，用于按照不超过真实库存数量的所述购买请求，对数据库中的库存数进行更新处理。

在上述方案中，所述购买请求，包括：

所述购买请求的发送源地址标识、所述购买请求的访问时间和所述购买请求的用户标识。

在上述方案中，所述购买请求满足预设的验证条件，包括：

所述购买请求满足购买条件，且所述购买请求通过权限验证。

在上述方案中，所述装置还包括：验证单元；其中，

验证单元用于当使用同一发送源地址标识的购买请求的访问次数不超过阈值，且所述购买请求的访问时间离抢购开始时间的间隔小于一分钟时，所述购买请求满足抢购条件；

或，当使用同一发送源地址标识的购买请求的访问次数超过两次，但所述两次购买请求的访问时间的间隔大于五分钟时，所述购买请求满足购买条件。

在上述方案中，所述验证单元，具体用于

当所述购买请求中的用户标识与预存的具有参与抢购权限的用户标识相匹配时，所述购买请求通过权限验证；

当所述购买请求中的用户标识与所述预存的具有参与抢购权限的用户标识不匹配时，所述购买请求没有通过权限验证。

在上述方案中，所述第一限制单元，具体用于

将全部满足所述验证条件的购买请求放入第一缓存，并获取所述第一缓存中所述购买请求数量；

当显示库存数大于0时，按照所述第一缓存中所述购买请求数量，对所述显示库存数进行扣减处理；

得到扣减处理成功的所述购买请求，并更新所述显示库存数。

在上述方案中，所述第二限制单元，具体用于

将在第一缓存中扣减处理成功的所述购买请求放入第二缓存，并获取所述第二缓存中所述购买请求数量；

当扣减库存数大于0时，按照所述第二缓存中所述购买请求数量，对所述扣减库存数进行扣减处理；

得到不超过真实库存数量的所述购买请求，并更新所述扣减库存数。

本发明实施例提供了一种订单处理方法及装置，通过在订单处理过程中对高并发的购买请求数量依次进行第一级限制和第二级限制，降低购买请求的并 发量，进而解决高并发的购买请求导致的“超卖”现象；同时，大部分的订单处理均在内存中完成，这样能够避免频繁对数据库进行直接操作，以免对数据库的性能产生不良影响。

附图说明

图1为本发明实施例提供的一种订单处理方法的流程示意图；

图2为本发明实施例提供的另一种订单处理方法的流程示意图；

图3为本发明实施例提供的再一种订单处理方法的流程示意图；

图4为本发明实施例提供的又一种订单处理方法的流程示意图；

图5为本发明实施例提供的第五种订单处理方法的流程示意图；

图6为本发明实施例提供的一种订单处理系统的结构示意图；

图7为本发明实施例提供的一种订单处理系统的流程示意图；

图8为本发明实施例提供的一种订单处理装置的一种结构示意图；

图9为本发明实施例提供的一种订单处理装置的另一种结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

实施例一

参见图1，其示出了本发明实施例提供的一种订单处理方法，该方法可以包括：

s101：接收购买请求，确定该购买请求是否满足预设的验证条件；

需要说明的是，购买请求满足预设的验证条件包括该购买请求满足抢购条件，且该购买请求通过权限验证；其中，购买请求包括该购买请求的发送源地址标识、该购买请求的访问时间和该购买请求的用户标识。

其中，s101的实现过程具体可以包括：

s1011：接收购买请求，确定该购买请求是否满足抢购条件；

需要说明的是，在确定购买请求是否满足抢购条件之前，需要在前端页面上显示商品的显示库存数并确定该显示库存数是否大于0；其中，在前端页面上显示的显示库存数用于向用户展示商品当前的剩余库存。当显示库存数大于0时，购买请求进入下一个抢购流程；当显示库存数等于0时，表示商品已经售完，终止该抢购请求的抢购流程。由于从用户角度来看，商品的库存数小于0不符合常识，因此，显示库存数必须大于或等于0。

在具体实施过程中，在确定购买请求是否满足抢购条件之前，还需要设置一个阈值，用来限制使用同一发送源地址标识的购买请求的访问次数；其中，购买请求的发送源地址标识具体可以是购买请求使用的ip地址。当使用同一ip地址的购买请求的数量不超过该阈值，且该购买请求的访问时间距离抢购开始时间的间隔小于一分钟时，该抢购请求满足抢购条件；或者，当使用同一ip地址的购买请求的数量超过两次，但两次购买请求的访问时间的间隔大于五分钟时，该购买请求满足抢购条件。这样，可以防止用户使用秒杀工具发起高并发的购买请求。

若购买请求满足抢购条件，则该购买请求获取系统发放的正确的令牌，凭借正确的令牌可以进入下一步的抢购流程；若否，则该购买请求无法获得系统发放的令牌或获得系统发放的令牌为错误令牌，从而导致该购买请求无法进入下一步的抢购流程，此时，终止该购买请求的抢购流程。

s1012：当该购买请求满足抢购条件时，对该购买请求进行权限验证。

需要说明的是，在对购买请求进行权限验证之前，需要预设具有参与抢购权限的用户标识；其中，用户标识具体可以用相关字节中的1或0来表示。

在具体实施过程中，通过与大数据精确营销平台对接来获取购买请求的用户标识，比如黑名单、4g用户、中高端用户、每用户平均收入(arpu，averagerevenueperuser)等。当购买请求中的用户标识与预存的具有参与抢购权限的用户标识相匹配时，该购买请求通过权限验证，进入下一步的抢购流程；当购买请求中的用户标识与预存的具有参与抢购权限的用户标识不匹配时，该购买请求没有通过权限验证，终止该购买请求的抢购流程。

s102：按照显示库存数，对全部满足该验证条件的购买请求数量进行第一级限制，得到第一级限制后的该购买请求；

其中，s102的实现过程具体可以包括：

s1021：将全部满足该验证条件的购买请求放入第一缓存，并获取该第一缓存中该购买请求的数量；

在具体实施过程中，将全部满足抢购条件且通过权限验证的购买请求放入第一缓存区的队列，并获取第一缓存区的队列中购买请求的数量；其中，第一缓存区的大小可以根据实际情况设定。当抢购请求数量过大时，可能会超过第一缓存区的容纳限度，此时，会有部分满足抢购条件且通过权限验证的购买请求被挤出，导致这部分购买请求的抢购流程被终止。

需要说明的是，为了获取第一缓存区的队列中购买请求数量，需要对第一缓存区的队列中购买请求数量进行统计处理。在统计第一缓存区的队列中购买请求数量时，对同一个购买请求的统计处理只能进行一次。因为第一缓存区的队列中购买请求是滚动更新的，新的购买请求进入第一缓存区的队列的同时，已经经过后续全部处理后的购买请求也在退出第一缓存区的队列，这样在进行统计处理时，有些已经包含在上一次统计处理的统计结果中的购买请求可能还没有来得及退出第一缓存区的队列，导致在此次统计处理中，对已经包含在之前的统计处理的统计结果中的购买请求进行了二次统计。因此，为了保证购买请求数量的准确性，对一个购买请求只能进行一次统计处理。

s1022：当显示库存数大于0时，按照该第一缓存中所述购买请求数量，对该显示库存数进行扣减处理；

在具体实施过程中，需要先确定显示库存数是否大于0；若显示库存数大于0，则根据第一缓存中购买请求的数量，对显示库存数进行扣减处理；若否，则终止该购买请求的抢购流程。

s1023：得到扣减处理成功的该购买请求，并更新该显示库存数。

在具体实施过程中，还需要在前端页面上将更新后的显示库存数作为商品当前的剩余库存数展示给用户。由于显示库存数必须大于或等于0，因此，即 使更新后的显示库存数小于0，为了顾及用户的感受，显示库存数仍旧显示为0。

需要说明的是，对第一缓存区的队列的扣减处理采用锁机制，在扣减处理之前，使用同步锁进行锁定，在扣减处理完成并更新库存数后，解除锁定。这样，能够避免多个扣减处理并发执行，影响购买请求数量的准确性。

s103：按照扣减库存数，对第一级限制后的该购买请求的数量进行第二级限制，得到不超过真实库存数量的该购买请求；

其中，s103的实现过程具体可以包括：

s1031：将在第一缓存中扣减处理成功的购买请求放入第二缓存，并获取第二缓存中购买请求数量；

s1032：当扣减库存数大于0时，根据该第二缓存中购买请求数量，对该扣减库存数进行扣减处理；

在具体实施过程中，需要先确定扣减库存数是否大于0；若扣减库存数大于0，则根据所述第二缓存中所述购买请求的数量，对所述扣减库存数进行扣减处理；若否，则终止所述购买请求的抢购流程。

具体来说，对第二缓存区的队列中的扣减处理采用排队机制和锁机制，每次的扣减处理只针对一个购买请求，在对一个购买请求进行扣减处理时，其他购买请求在排队等候，这样依次对第二缓存区的队列中的购买请求进行扣减处理，以保证数据的安全性。同时，在每次扣减处理之前，需要使用同步锁锁定，本次扣减处理完成之后，再解除锁定，这样，能够防止多个购买请求同时进行扣减处理，影响购买请求数量的准确性。

s1033：得到不超过真实库存数量的该购买请求，并更新该扣减库存数。

在具体实施过程中，扣减库存数只用于在第二缓存中进行扣减控制，不会显示在前端页面上，因此，扣减库存数可以小于0，并且当扣减库存数小于0时不会影响正常的抢购流程。

s104：按照不超过真实库存数量的该购买请求，对数据库中的库存数进行更新处理。

其中，s104的实现过程具体可以包括：

s1041：将不超过真实库存数量的购买请求放入物理库请求队列；

s1042：按照不超过真实库存数量的所述购买请求，对数据库中的库存数进行更新处理。

在具体实施过程中，mysql数据库根据物理库请求队列中购买请求，采用updatea＝a-1wherea>0的基本控制方式对数据库中的库存数进行更新处理，并根据mysql数据库的处理结果判断是否执行成功，抢购流程结束。

需要说明的是，本发明方案中涉及三个库存数，分别是内存中的显示库存数和扣减库存数，以及数据库中的库存数，这三个库存数的初始数值均相同，但在订单处理过程中互不影响。在订单处理过程中的s101～s103中只对内存中的显示库存数和扣减库存数进行扣减，在s104中才会对数据库中的库存数进行扣减。当对内存中的扣减库存数和显示库存数进行初始化时，需要先将数据库中的库存数读取到内存中的扣减库存数中，在从扣减库存数中读取到显示库存数。另外，在第一缓存区的队列中，显示库存数不仅用于限制购买请求数量，还用于在前端页面向用户显示商品当前的剩余库存，因此，显示库存数必须大于或等于0；而在第二缓存区的队列中，扣减内存数只用于限制购买请求的数量，因此，扣减库存数可以小于0。

还需要说明的是，在订单处理过程中，除了s104以外，其他处理过程都是在内存中执行的。这样，能够减少对数据库直接操作的次数，避免对数据库的性能产生不良影响，同时，加快前端页面显示商品当前的剩余库存数的速度，提升用户体验。

另外，针对第一缓存区的队列和第二缓存区的队列，需要进一步说明的是，由于数据库在处理高并发购买请求时，很容易出现“超卖”现象。因此，在对数据库中的库存数进行更新处理之前，先依次使用两个队列来实现对高并发购买请求的数量限制，逐层降低购买请求的并发量；其中，两个队列具体可以为第一缓存区中的队列和第二缓存中的队列。在具体实施过程中，依次使用显示库存数和扣减库存数分别对第一缓存区的队列中的购买请求的数量和第二缓存区的队列中的购买请求的数量进行限制，这样，当抢购流程进行到数据库处理 库存数这一步时，购买请求的并发量已经降到最低。

具体来说，在抢购时的高并发场景下，由于大量购买请求瞬间涌入第一缓存区中的队列，很容易因库存数更新不及时而导致的多扣库存数现象，也就是说，在高并发场景下，在第一缓存区的队列中扣减处理成功的购买请求数量可能已经超过了商品真实的库存数量；接下来，将第一缓存中的队列中扣减处理成功的购买请求放入第二缓存区中的队列，在第二缓存区的队列中再次对购买请求数量进行限制；其中，第一缓存区的队列和第二缓存区的队列分别使用了独立的库存数来计算购买请求数量。这样，即使第一缓存区的队列没有限制住部分购买请求，允许部分已经超过商品真实的库存数量的购买请求进入了第二缓存区的队列，但是，在第二缓存区的队列的扣减处理中，能够滤出该部分“多余的”购买请求，使得抢购请求的数量在数据库更新库存数之前，限制在商品真实的库存数量范围内，最大程度降低购买请求的并发量。如此，不仅解决了高并发的购买请求导致的“超卖”现象，同时提高了抢购结果的准确性，为用户提供更佳的购物体验。

在具体实施过程中，实施例一可以由一种订单处理系统来实现：该订单处理系统由前端控制层、内存控制层和数据库控制层这三个部分组成；其中，前端控制层包括访问控制单元、库存显示单元、权限验证单元和第一缓存队列，内存控制层包括第一扣减单元、第二扣减单元和第二缓存队列，数据库控制层包括物理库请求队列和数据库扣减单元；其中，该订单处理系统的结构如图6所示，图中的箭头表示订单处理的流程顺序，在具体应用中，需要根据接收到的购买请求，循环执行订单处理的流程，因此图中箭头的指向将该订单处理系统组合成了一个循环系统。

在该订单处理系统中，各个单元或队列的功能如图7所示，包括：

s701：库存显示单元用于在前端页面向用户显示当前的显示库存数；

s702：访问控制单元用于确定接收的购买请求是否满足抢购条件；

在具体实施过程中，当使用同一ip地址的购买请求的数量不超过该阈值，且该购买请求的访问时间距离抢购开始时间的间隔小于一分钟时，该抢购请求 满足抢购条件；或者，当使用同一ip地址的购买请求的数量超过两次，但两次购买请求的访问时间的间隔大于五分钟时，该购买请求满足抢购条件。

当接收到的购买请求满足抢购条件时，向该购买请求发放正确的令牌，该购买请求凭借正确的令牌可以进入下一步的抢购流程。

s703：权限验证单元用于对购买请求进行权限验证；

需要说明的是，当购买请求中的用户标识与预存的具有参与抢购权限的用户标识相匹配时，该购买请求通过权限验证，进入下一步的抢购流程。

s704：第一缓存队列用于放置通过权限验证的购买请求；

s705：第一扣减单元用于按照显示库存数，对第一缓存队列中的购买请求数量进行第一级限制，得到第一级限制后的购买请求，同时，更新显示库存数；

在具体实施过程中，需要在前端页面上将更新后的显示库存数作为商品当前的剩余库存数展示给用户。由于显示库存数必须大于或等于0，因此，即使更新后的显示库存数小于0，为了顾及用户的感受，显示库存数仍旧显示为0。

s706：第二缓存队列用于放置在第一缓存区的队列中扣减处理成功的购买请求；

s707：第二扣减单元用于按照扣减库存数，对第二缓存区的队列中购买请求数量进行第二级限制，得到不超过真实库存数量的购买请求；

在具体实施过程中，需要先确定扣减库存数是否大于0；若扣减库存数大于0，则根据所述第二缓存中所述购买请求的数量，对所述扣减库存数进行扣减处理；若否，说明商品已经售完，扣减失败，并将扣减结果返回给用户。

具体来说，对第二缓存区的队列中的扣减处理采用排队机制和锁机制，每次的扣减处理只针对一个购买请求，在对一个购买请求进行扣减处理时，其他购买请求在排队等候。同时，在每次扣减处理之前，需要使用同步锁锁定，本次扣减处理完成之后，再解除锁定。

s708：物理库请求队列用于放置不超过真实库存数量的购买请求；

s709：数据库扣减单元用于按照不超过真实库存数量的所述购买请求，对数据库中的库存数进行更新处理。

在具体实施过程中，mysql数据库根据物理库请求队列中购买请求，采用updatea＝a-1wherea>0的基本控制方式对数据库中的库存数进行更新处理，并根据mysql数据库的处理结果判断是否执行成功，抢购流程结束。

实施例二

基于上述实施例相同的技术构思，参见图8，其示出了本发明实施例提供的一种装置80，该装置80包括：第一限制单元801、第二限制单元802以及更新单元803；其中，

第一限制单元801，用于当接收到的购买请求满足预设的验证条件时，按照显示库存数，对全部满足所述验证条件的购买请求数量进行第一级限制，得到第一级限制后的所述购买请求；

第二限制单元802，用于按照扣减库存数，对第一限制单元801处理后的所述购买请求数量进行第二级限制，得到不超过真实库存数量的所述购买请求；

更新单元803，用于按照不超过真实库存数量的所述购买请求，对数据库中的库存数进行更新处理。

在上述方案中，所述购买请求，包括：所述购买请求的发送源地址标识、所述购买请求的访问时间和所述购买请求的用户标识。

在上述方案中，所述购买请求满足预设的验证条件，包括：所述购买请求满足购买条件，且所述购买请求通过权限验证。

如图9所示，移动终端80还包括：验证单元804；其中，所述验证单元804，用于当使用同一发送源地址标识的购买请求的访问次数不超过阈值，且所述购买请求的访问时间离抢购开始时间的间隔小于一分钟时，所述购买请求满足抢购条件；或，当使用同一发送源地址标识的购买请求的访问次数超过两次，但所述两次购买请求的访问时间的间隔大于五分钟时，所述购买请求满足购买条件。

在上述方案中，所述验证单元804，用于当所述购买请求中的用户标识与预存的具有参与抢购权限的用户标识相匹配时，所述购买请求通过权限验证；当所述购买请求中的用户标识与所述预存的具有参与抢购权限的用户标识不匹 配时，所述购买请求没有通过权限验证。

在上述方案中，所述第一限制单元801，用于将全部满足所述验证条件的购买请求放入第一缓存，并获取所述第一缓存中所述购买请求数量；当显示库存数大于0时，按照所述第一缓存中所述购买请求数量，对所述显示库存数进行扣减处理；得到扣减处理成功的所述购买请求，并更新所述显示库存数。

在上述方案中，所述第二限制单元802，用于将在第一限制单元801中扣减处理成功的所述购买请求放入第二缓存，并获取所述第二缓存中所述购买请求数量；当扣减库存数大于0时，按照所述第二缓存中所述购买请求数量，对所述扣减库存数进行扣减处理；得到不超过真实库存数量的所述购买请求，并更新所述扣减库存数。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、程序实施例、或结合程序和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使 得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。