本申请涉及信息技术领域，尤其涉及一种业务量的预测方法及装置。
背景技术：
在网络业务飞速发展的当代，业务提供商的服务器负荷也越来越重，对实时的确定业务量已经变的尤为重要。
在现有技术中，确定某个业务的业务量时，一般需要统计单位时间内生成的业务结果的数量，作为当前时刻的业务量，如果某一时刻生成的业务结果的数量达到峰值，则确定该时刻即为业务高峰的到来时刻。
但是，在实际应用场景中，服务器的负荷主要是在业务执行的过程中产生，并不是在生成业务结果时产生，也就是说，实际的业务量产生时刻应该在业务开始执行的时刻，而不是执行结束时产生业务结果的时刻，实际的业务高峰到来时刻应该是大量的业务开始执行的时刻，而不是执行结束时产生业务结果的时刻。
而且，不同种类的业务的执行时间也有所不同，或者说，用户在执行不同种类的业务时，用户需要操作的时间有所不同，那么，对于执行时间较短的业务，可以较快的生成业务结果，通过现有技术中统计业务量的方法，统计出的业务量相对于实际的业务量不会过于偏低，统计出的业务高峰到来时刻相对于实际的业务高峰到来时刻也不会过于滞后，可能尚在可接受范围内，而对于执行时间较长的业务，则会使确定出的业务量相对于实际业务量过于偏低，确定出的业务高峰到来时刻相对于实际的业务高峰到来时刻也存在较大的滞后。
例如，对于简单的登录来说，服务器接收到登录请求的时刻即为业务开始执行的时刻，而服务器接收到登录请求后，只要验证用户名和密码正确，即可执行登录并生成登录结果，按照现有技术的方法，将登录结果的生成数量作为当前时刻的业务量是可以接受的。但是，对于订火车票这种业务来说，用户需要进行大量的查询，还需要提交订单、支付等过程，如果将当前时刻统计出的支付结果生成数量作为当前时刻的业务量，则显然会使确定出的业务量低于实际的业务量，这是因为当前时刻尚有很多用户已经在执行查询、提交订单等订票的业务过程，但尚未完成支付，也就不会产生支付结果，如果将支付结果生成数量峰值的到来时刻确定为业务高峰到来时刻，则也会使确定出的业务高峰到来时刻滞后很多。
即便是对于同类但执行方式不同的业务来说，也是如此。例如，对于快递业务a和快递业务b来说，用户在使用快递业务a运送货物时，需要先支付运费，再进行快递运输，相应地，服务器会根据快递员上传的支付成功的支付结果，统计其业务量，而用户在使用快递业务b运送货物时，可直接通过电话、短信等方式联系快递员，以指示其上门取货后进行快递运输，待快递送达至接收方后，由接收方进行支付，支付成功后，快递员可将支付结果提交到服务器。显然，若以当前时刻接收到支付结果的数量作为业务量，则对于快递业务b来说，现有技术确定出的业务量明显低于实际的业务量，若以接收到支付结果的数量达到峰值的时刻确定业务峰值的到来时刻，则对于快递业务b来说也是滞后的。
可见，现有技术中确定的当前时刻业务量的准确性较低，这无疑对服务器的运维和管理是非常不利的。
技术实现要素：
本申请实施例提供一种业务量的预测方法及装置，用于解决现有技术中确定出的当前时刻业务量不准确，不利于服务器运维的问题。
本申请实施例采用下述技术方案：
一种业务量的预测方法，包括：
确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻；
根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值；
根据所述历史峰值，预测所述第二业务在所述指定时刻的业务量，其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
一种业务量的预测方法，包括：
接收针对第一类餐馆的各支付信息；
根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付次数达到峰值的时刻，作为指定时刻；
根据保存的历史记录，确定历史上针对第二类餐馆的支付次数峰值，作为历史峰值；
根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务。
一种业务量的预测装置，包括：
时刻确定模块，确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻；
历史峰值模块，根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值；
业务量模块，预测所述第二业务在所述指定时刻的业务量，其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
一种业务量的预测装置，包括：
接收模块，接收针对第一类餐馆的各支付信息；
时刻确定模块，根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付次数达到峰值的时刻，作为指定时刻；
历史峰值模块，根据保存的历史记录，确定历史上针对第二类餐馆的支付次数峰值，作为历史峰值；
业务量模块，根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务。
本申请服务器会将第一业务的支付次数达到峰值的时刻确定为指定时刻，并根据历史上记录的第二业务的支付次数的峰值，确定在当前时刻下第二业务可能的业务量。相较于现有技术而言，即使对于支付次数达到峰值的时刻较为滞后的业务，本申请也能够较为准确地确定出该业务在当前时刻的业务量，从而为服务器的运维过程提供较为准确的参考。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例提供的业务量的预测过程；
图2a为本申请实施例提供的餐馆业务量的预测过程所基于的架构；
图2b为本申请实施例提供的餐馆业务量的预测过程；
图3为本申请实施例提供的在实际应用中业务量的示意图；
图4为本申请实施例提供的一种业务量的预测装置结构示意图；
图5为本申请实施例提供的另一种业务量的预测装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
正如前述，针对同种类、但执行方式不同的业务，在统计其业务量的过程中，存在对当前时刻业务量确定不准确的现象，基于此，本申请实施例提供一种业务量的预测方法，以尽量准确地确定执行方式不同的业务在当前时刻的业务量，为了便于后续描述，将执行方式不同的业务分别称为第一业务和第二业务。以下结合附图，详细说明本申请各实施例提供的技术方案。
实施例一
图1为本申请实施例提供的业务量的预测过程，具体包括以下步骤：
s101：确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻。
在实际应用场景中，对第一业务的支付次数的确定，可以由相应的业务提供方的服务器所实现，其中，所述的业务提供方，包括但不限于：网站、银行、电信运营商等。
用户可以通过向业务提供方的服务器(以下简称为：服务器)发出业务请求的方式，使用该业务提供方所提供的某项业务(也即，第一业务)，相应地，用户使用了该项业务通常会支付相应的业务代价(如：支付相应的款项)，服务器则会针对用户所支付的业务代价进行记录。例如：用户在使用快递业务的过程中，支付了运费，由相应的快递员将支付结果提交给快递网站服务器，在服务器上，便会记录本次支付。
显然，随着用户的使用，该第一业务的支付次数将在某一时刻(即，指定时刻)达到峰值，其中，所述的峰值，应理解为在某一设定的时间段之内业务量的最大值，在实际应用中，在全时段内，所述的峰值可以有多个。这里并不构成对本申请的限定。
s102：根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值。
所述第二业务，同样由相应的业务提供方所提供，如前述示例中的快递业务b，与前述的第一业务属于同类业务，但两种业务的执行方式不同。在本申请实施例中，对于该第二业务而言，确定出该第二业务的业务高峰到来的时刻，相较于该第二业务实际的业务高峰存在较大的滞后。
换言之，由于第一、第二业务之间的执行方式不同，服务器对第一业务的支付次数的峰值的统计较为及时，但服务器针对第二业务的支付次数的峰值的统计较为滞后。
考虑到在实际应用场景下，服务器通常会针对其所执行或完成的业务均会进行记录，具体可记录不同的业务在各时刻所的支付次数，作为历史记录，那么，根据历史记录，也就可以确定出第二业务在历史上的支付次数的峰值。
根据第二业务的支付次数的历史峰值，可针对指定时刻第二业务的业务量进行预估，也即，执行下述步骤s103。
s103：根据所述历史峰值，预测所述第二业务在所述指定时刻的实际业务量。
其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
所述的业务量，可认为是服务器根据已接收到的业务请求，正在执行且并未产生支付结果的业务的数量。
对于第二业务而言，由于服务器确定出第二业务的支付次数的时刻较为滞后，也就是说，在服务器统计出第二业务的支付次数之前，该第二业务的实际量可能已达到峰值，所以，可根据第二业务历史上的支付次数的峰值，作为指定时刻第二业务可能的业务量，为后续操作(如：服务器维护操作)作为参考。
当然，所述的预设时长，用于量化上述第一业务和第二业务所需的执行之间，对于不同的业务场景，预设时长的设定通常不同，具体可以根据实际业务场景的需要进行设定，这里并不构成对本申请的限定。
由上述过程可见，当不同用户使用业务提供方所提供的第一业务及第二业务时，由于第一业务与第二业务的执行方式不同，使得第一业务执行时间短于第二业务执行时间，在此情况下，对于第一业务而言，其支付次数将优先达到峰值，而对于第二业务而言，由于第二业务的执行时间较长，导致对第二业务的支付次数的统计较为滞后，但实际上，第二业务的业务量可能已达到峰值，那么，为了较为准确地确定出第二业务实际的业务量，故在本申请实施例中，服务器会将第一业务的支付次数达到峰值的时刻确定为指定时刻，并根据历史上记录的第二业务的支付次数的峰值，确定在当前时刻下第二业务可能的业务量。
相较于现有技术而言，即使对于支付次数达到峰值的时刻较为滞后的业务，本申请也能够较为准确地预测出该业务在当前时刻的业务量，从而为服务器的运维过程提供较为准确的参考。
对于前述确定业务量的过程，具体来说，根据所述历史峰值，预测所述第二业务在所述指定时刻的业务量，包括：确定在所述指定时刻针对所述第二业务的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二业务的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，确定所述第二业务在所述指定时刻的业务量。
以前述快递业务为例进行详细说明，对于快递业务b(即，第二业务)来说，由于快递运输的运费在接收方接收到快递后才进行支付，故在该场景下，服务器接收到的支付次数达到峰值的时刻较为滞后(这里，从快递运输开始至接收方完成支付的过程，便可看作是第二业务正在执行的过程)，显然，在支付次数达到峰值前，正在执行的业务量可能已达到峰值。故可采用历史峰值的方式确定快递业务b的在12:00时的业务量：
在此假设，以12:00作为指定时刻，通过历史记录，可确定前一天快递业务b的中午时段的支付次数出现在12:30，数值为500(次)，故可以将该历史峰值确定为12:00时快递业务b的支付次数峰值。
需要说明的是，采用上述方法所确定出的第二业务在指定时刻的业务量，实质上是一种根据历史记录得到的预估值，但是，历史上第二业务的支付次数的历史峰值的大小并不一致，换言之，历史峰值有可能高于当前时刻第二业务业务量，也有可能低于当前时刻第二业务业务量。那么，为了更加准确地对确定第二业务的业务量，故可以针对确定的历史峰值进行数值上的调整，具体而言：根据比较结果以及所述历史峰值，确定所述第二业务在所述指定时刻的业务量，包括：确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重以及所述历史峰值预测所述第二业务在所述指定时刻的业务量。
沿用上例，假设在12:00，针对快递业务b，服务器已统计出的支付次数为500(即，前述的当前次数)，并假设前一天在12:00时，服务器已统计出的支付次数为400(即，前述的历史次数)，显然，在12:00时，前一天服务器已统计出的支付次数小于当前服务器已统计出的支付次数，故可确定差值为100，那么，也就表明在当天，快递业务b正在进行快递运输的业务量有可能多于前一天的业务量，所以，可确定权重假设为0.2，那么，在此基础上，也就可以针对历史峰值进行调整，即，500*(1+0.2)＝600，从而，确定当天12:00时快递业务b正在快递运输过程中的数量为600(即，后续服务器可统计出支付次数为600)。
上述示例仅是为了说明本申请实施例中所述的业务量的预测方法，并不应理解为对本申请的限定。
除了上述的场景，目前，餐馆推荐类的应用(后续简称为：推荐应用)广泛被用户使用，通过推荐应用，用户可获知各类餐馆的基本信息以及就餐情况，并可使用该推荐应用进行支付。
在实际应用中，餐馆分为不同类型：快餐类餐馆以及正餐类餐馆，其中，快餐餐馆的就餐方式为先支付后就餐，而正餐餐馆的就餐方式为先就餐后支付，由此，推荐应用后台的服务器可接收不同类型的餐馆发送的支付信息，并以此来统计各餐馆的就餐情况，然而，正是由于两种餐馆的就餐方式不同，那么，对于正餐餐馆而言，用户在就餐完成后进行支付，所以，推荐应用后台服务器获得正餐餐馆的支付信息通常是滞后的，这样一来，对于使用推荐应用的用户来说，也就不能准确地获知正餐餐馆当前的就餐情况。
因此，本申请实施例中所提供的业务量的预测方法还适用于对餐馆就餐情况统计的场景。具体地，如图2a所示，为本场景下的架构示意图，推荐应用后台的服务器(以下简称：服务器)接收不同类型餐馆发送的支付信息，并以此生成相应的就餐情况。
基于如图2a所示的架构，在该场景下的业务量的预测方法如图2b所示，具体包括以下步骤：
s201：接收针对第一类餐馆对应的各支付信息。
其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，如：快餐类餐馆，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务，如：正餐类餐馆。
可见，对于第一类餐馆，由于其就餐方式为先支付后就餐，故服务器将及时地接收到第一类餐馆的支付信息。
s202：根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付次数达到峰值的时刻，作为指定时刻。
在实际应用中，通常可以在某些设定的时段内确定第一类餐馆对应的支付次数达到峰值的时刻，这里的设定时段，可以如：午餐时段(11:30～13:30)、晚餐时段(17:00～20:00)等，第一类餐馆对应的支付次数达到峰值的时刻，可以如：午餐时段内的12:00时，支付次数达到峰值。当然，这里并不构成对本申请的限定。
显然，第一类餐馆的支付次数达到峰值，也就表明该第一类餐馆的就餐情况(如：就餐人气)达到峰值。
s203：根据保存的历史记录，确定历史上针对第二类餐馆的支付次数峰值，作为历史峰值。
由于与第一类餐馆的就餐方式不同，服务器针对第二类餐馆的支付次数的统计，通常只能在用户就餐结束后，也即，对支付次数的统计出现了滞后，所以，为了确定出指定时刻(如：上例中的12:00)针对第二类餐馆的支付次数，将确定历史上的支付次数峰值，以作为参考，例如：以前一天午餐时段中第二类餐馆的支付次数峰值作为历史峰值。
s204：根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量。
沿用上例，在12:00时，对于第二餐馆而言，用户可能正处于就餐状态(但并未支付)，当前正在就餐的用户在就餐结束后，可能能够使得该第二类餐馆的支付次数达到峰值，那么，也就可以根据前一天的历史峰值作为当天实际的就餐情况(即，业务量)。
根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量之前，所述方法还包括：接收针对第二类餐馆对应的各支付信息，那么，根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，具体包括：根据所述第二类餐馆对应的各支付信息，确定在所述指定时刻针对所述第二类餐馆的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二类餐馆的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量。
更为具体地，根据比较结果以及所述历史峰值，确定所述第二类餐馆在所述指定时刻的业务量，具体包括：确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重以及所述历史峰值预测所述第二类餐馆在所述指定时刻的业务量。
例如：如图3所示，示出了服务器对第一类餐馆a和第二类餐馆b的支付次数的统计值，假设，在dn天(可理解为当天)的午餐时段，餐馆a的支付次数在12:00达到峰值500，同一时刻，餐馆b的支付次数为100(当前次数)，显然，考虑到餐馆b的就餐方式，可以还有一定数量的用户处于正在就餐的状态而并未进行支付，所以，为了确定出该餐馆b在12:00时的业务量，可参考餐馆b在dn-1天午餐时段的支付次数峰值，从图3中可见，餐馆b在dn-1天12:30的支付次数达到峰值450。
为了更加准确地估计餐馆b在dn天12:00时的支付次数峰值，则可确定餐馆b在dn-1天12:00时的支付次数，即为120(历史次数)。那么，当前次数与历史次数的差值为-20，进而可确定出该差值对应的权重，假设，差值在[-1，-20]区间内的权重为-0.2，所以，便可以确定在dn天12:00时，餐馆b的支付次数峰值为：450*(1-0.2)＝360。
故在本示例下，将餐馆b在dn天12:00时的业务量确定为360，即表示餐馆b在dn天的午餐时段的支付次数峰值预计为360。
在实际应用场景下，服务器可基于确定出的业务量，向使用推荐应用的用户展示各餐馆的人气值，所述方法还包括：根据确定出的所述业务量，以及预设的规则，确定所述第二类餐馆在所述指定时刻的人气值，展示所述人气值。
作为本申请实施例中的一种方式，可以在业务量的基础上，结合人气系数确定餐馆的人气值，当然，人气值还可以采用星级的方式进行展示，如：业务量超过150，则展示五星的人气值，以上方式并不构成对本申请实施例的限定。
本申请实施例中所述支付涉及的技术载体，例如可以包括近场通信(nearfieldcommunication，nfc)、wifi、3g/4g/5g、pos机刷卡技术、二维码扫码技术、条形码扫码技术、蓝牙、红外、短消息(shortmessageservice，sms)、多媒体消息(multimediamessageservice，mms)等。
以上为本申请实施例提供的业务量的预测方法，基于同样的思路，本申请还提供了相应的业务量的预测装置，如图4、图5所示。
图4为本申请实施例提供的业务量的预测装置结构示意图，具体包括：
时刻确定模块401，确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻；
历史峰值模块402，根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值；
业务量模块403，预测所述第二业务在所述指定时刻的业务量，其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
所述业务量模块403，确定在所述指定时刻针对所述第二业务的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二业务的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二业务在所述指定时刻的业务量。
所述业务量模块403，确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重以及所述历史峰值预测所述第二业务在所述指定时刻的业务量。
图5为本申请实施例提供的另一种业务量的预测装置结构示意图，具体包括：
接收模块501，接收针对第一类餐馆对应的各支付信息；
时刻确定模块502，根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付次数达到峰值的时刻，作为指定时刻；
历史峰值模块503，根据保存的历史记录，确定历史上针对第二类餐馆的支付次数峰值，作为历史峰值；
业务量模块504，根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务。
所述接收模块501，接收针对第二类餐馆对应的各支付信息，所述业务量模块504，根据针对所述第二类餐馆的各支付信息，确定在所述指定时刻针对所述第二类餐馆的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二类餐馆的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量。
所述业务量模块504，确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重以及所述历史峰值预测所述第二类餐馆在所述指定时刻的业务量。
所述装置还包括：展示处理模块505，根据预测出的所述业务量，以及预设的规则，确定所述第二类餐馆在所述指定时刻的人气值，并展示。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。