处理请求的方法和装置与流程

文档序号:15819275发布日期:2018-11-02 22:56阅读:131来源:国知局
处理请求的方法和装置与流程

本申请涉及计算机领域,尤其涉及一种处理请求的方法和调度装置。

背景技术

在计算机网络中,例如,在分布式存储系统中,请求的输入/输出(input/output,io)路径包括网络和存储等多个阶段,每个阶段均存在一个请求队列,该请求队列中的请求按照某种次序被处理。

当前,服务器接收到不同客户端发送的请求时按照先来先服务(firstcomefirstservice,fcfs)或者轮询调度(roundrobin)的方式对请求进行处理,其中,fcfs即服务器记录请求到达服务器的时刻,并优先处理到达服务器的时刻较早的请求,轮询调度即服务器轮流处理来自不同客户端的请求。

由于网络和磁盘io的服务时间抖动以及排队时间等因素的影响,请求在各个阶段均会存在一定的延迟,若按照fcfs或者轮询调度对同一个应用生成的不同请求进行处理时,当一个请求在某个阶段的延迟较高时,则该请求在后续阶段的延迟会越来越高,形成长尾延迟(longtaillatency),导致该应用的不同请求之间时延波动增大,对该应用的性能造成不利影响。

因此,对于请求队列中的同一个应用生成的请求来说,当这些请求来自不同客户端时,如何减小不同请求之间的时延波动是一个亟需解决的问题。



技术实现要素:

有鉴于此,本申请提供了一种处理请求的方法和装置,能够减小来自不同客户端的同一个应用生成的不同请求的时延波动,增强计算机网络的稳定性。

一方面,提供了一种处理请求的方法,包括:接收端确定第一发送时刻和第二发送时刻,其中,该第一发送时刻为第一发送端发送第一请求的时刻,该第二发送时刻为第二发送端发送第二请求的时刻,该第一请求与该第二请求为同一个应用程序生成的不同的请求,该第一发送端与该第二发送端相异;该接收端根据该第一发送时刻和该第二发送时刻在同一时间基准下的时序处理该第一请求和该第二请求,其中,该第一发送时刻和该第二发送时刻在同一时间基准下的时序与该第一请求和该第二请求的处理顺序相同。

本申请提供的处理请求的方法能够减小来自不同客户端的同一个应用生成的不同请求的时延波动,增强计算机网络的稳定性。

可选地,该接收端根据该第一发送时刻和该第二发送时刻在同一时间基准下的时序确定该第一请求和该第二请求的待处理顺序,包括:该接收端根据该第一发送时刻和该第二发送时刻在同一时间基准下的时序确定该第一请求和该第二请求在请求队列中的位置,该请求队列包括至少一个待处理请求,该第一请求在该请求队列中的位置位于该至少一个待处理请求在该请求队列中的位置之后,且位于该第二请求在该请求队列中的位置之前;该接收端根据该第一请求和该第二请求在该请求队列中的位置确定该第一请求和该第二请求的待处理顺序,其中,该第一请求和该第二请求在该请求队列中的位置的顺序与该第一请求和该第二请求的待处理顺序相同。

根据本申请提供的方法,接收端可以根据请求在队列中的位置确定请求的待处理顺序。

可选地,该方法还包括:该接收端根据第一平均发送时刻、第一平均到达时刻、第一平均往返时间和该第一发送时刻确定第一同步发送时刻,其中,该第一平均发送时刻为该第一发送端在第一周期内发送请求的时刻的平均值,该第一平均到达时刻为该第一发送端在该第一周期内发送的请求到达该接收端的时刻的平均值,该第一平均往返时间为在该第一周期内请求往返该接收端和该第一发送端所需的时间,该第一同步发送时刻为该第一发送时刻在该接收端的时间参考系中的时刻;该接收端根据第二平均发送时刻、第二平均到达时刻、第二平均往返时间和该第二发送时刻确定该第二同步发送时刻,其中,该第二平均发送时刻为该第二发送端在第二周期内发送请求的时刻的平均值,该第二平均到达时刻为该第二发送端在该第二周期内发送的请求到达该接收端的时刻的平均值,该第二平均往返时间为在该第二周期内请求往返该接收端和该第二发送端所需的时间,该第二同步发送时刻为该第二发送时刻在该接收端的时间参考系中的时刻;该接收端根据该第一同步发送时刻和该第二同步发送时刻确定该第一发送时刻和该第二发送时刻在同一时间基准下的时序。

本申请提供的方法可以确定第一发送时刻和第二发送时刻在同一时间基准下的时序。

可选地,该方法还包括:该接收端在该第一请求中添加第一同步发送时刻标签,该第一同步发送时刻标签用于表示该第一同步发送时刻;以及,该接收端在该第二请求中添加第二同步发送时刻标签,该第二同步发送时刻标签用于表示该第二同步发送时刻。

接收端计算出第一同步发送时刻和第二同步发送时刻后分别在第一请求和第二请求中添加相应的标签,以便于后续的处理过程可以根据第一同步发送时刻标签和第二同步发送时刻标签确定第一请求和第二请求的待处理顺序,无需再次进行计算,减小了接收端的计算负担。

可选地,该接收端确定第一发送时刻和第二发送时刻,包括:该接收端根据该第一请求携带的第一发送时刻标签确定该第一发送时刻,该第一发送时刻标签用于表示该第一发送时刻;该接收端根据该第二请求携带的第二发送时刻标签确定该第二发送时刻,该第二发送时刻标签用于表示该第二发送时刻。

从而,服务器可以确定第一请求和第二请求的发送时刻。

可选地,该第一发送时刻标签位于该第一请求的头部,该第二发送时刻标签位于该第二请求的头部。

可选地,该第一请求包括该第一发送端的标识,该第二请求包括该第二发送端的标识。

从而,接收端可以根据上述标识确定请求来自于哪个发送端,并计算请求的同步发送时刻。

另一方面,提供了一种处理请求的装置,该装置可以实现上述方面所涉及方法中接收端所执行的功能,该功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个上述功能相应的单元或模块。

在一种可能的设计中,该装置的结构中包括处理器和通信接口,该处理器被配置为支持该装置执行上述方法中相应的功能。该通信接口用于支持该装置与其它网元之间的通信。该装置还可以包括存储器,该存储器用于与处理器耦合,其保存该装置必要的程序指令和数据。

再一方面,提供了一种计算机程序产品,该计算机程序产品包括:计算机程序代码,当该计算机程序代码被接收端的通信单元、处理单元或通信接口、处理器运行时,使得接收端执行上述实现方式中的方法。

再一方面,本申请提供了一种计算机存储介质,用于储存为上述接收端所用的计算机软件指令,其包含用于执行上述方面所设计的程序。

附图说明

图1是本申请提供的一种调度方法的示意性流程图;

图2是fcfs调度方法与本申请提供的一种调度方法的对比示意图;

图3是本申请提供的一种包括多个处理阶段的请求调度方法的示意性流程图;

图4是本申请提供的一种调度装置的结构示意图;

图5是本申请提供的另一种调度装置的结构示意图。

具体实施方式

下面将结合附图,对本申请中的技术方案进行描述。

图1是本申请提供的一种调度方法的示意性流程图。如图1所示,该方法100包括:

s110,接收端确定第一发送时刻和第二发送时刻,其中,该第一发送时刻为第一发送端发送第一请求的时刻,该第二发送时刻为第二发送端发送第二请求的时刻,该第一请求与该第二请求为同一个应用程序生成的不同的请求,该第一发送端与该第二发送端相异。

s120,该接收端根据该第一发送时刻和该第二发送时刻在同一时间基准下的时序处理该第一请求和该第二请求,其中,该第一发送时刻和该第二发送时刻在同一时间基准下的时序与该第一请求和该第二请求的处理顺序相同。

在本申请中,接收端为接收请求的任意一个单元,第一发送端为发送请求的任意一个单元,作为一个可选的示例,接收端是服务器,第一发送端是客户端,服务器和客户端是两个不同的实体设备;作为另一个可选的示例,接收端和第一发送端为位于同一个实体设备中的不同模块。为方便理解本申请,以下,以接收端为服务器、发送端为客户端为例对本申请的技术方案进行描述。

s110中,第一发送时刻为第一客户端记录的时刻,第二请求为第二客户端记录的时刻,该两个请求为同一个应用程序生成的请求。第一发送时刻和第二发送时刻可以分别记录在第一请求和第二请求中,该两个时刻也可以通过专用信息发送给服务器,本申请对服务器确定第一发送时刻和第二发送时刻的具体方法不作限定。

s120中,第一发送时刻和第二发送时刻在同一时间基准下的时序即:第一发送时刻和第二发送时刻在同一时间基准下的先后顺序。

由于不同设备的时间可能不同步,因此,将第一发送时刻和第二发送时刻直接对比没有意义,服务器需要将第一发送时刻和第二发送时刻在同一时间基准下进行对比,例如,服务器可以根据第一客户端与该服务器的时间差值对第一发送时刻进行修正,服务器可以根据第二客户端与该服务器的时间差值对第二发送时刻进行修正,从而可以将第一发送时刻和第二发送时刻在同一时间基准下进行对比,并确定第一发送时刻和第二发送时刻的时序。

上述方法仅是举例说明,本申请对服务器确定第一发送时刻和第二发送时刻在同一时间基准下的时序的方法不做限定,例如,服务器还可以通过同步信号定时与第一客户端和第二客户端进行时间同步,从而可以确定第一发送时刻和第二发送时刻在同一时间基准下的时序。进而能够减小来自不同客户端的同一个应用生成的不同请求的时延波动,增强计算机网络的稳定性。

了更清楚地说明方法100能够减小同一个应用生成的不同请求的时延波动,图2示出了本申请提供的调度方法以及fcfs调度方法的示意性流程图。

如图2所示,c1为第一客户端,c2为第二客户端a1为第一应用,a1生成了三个请求并分别通过c1和c2发送至服务器,该三个请求的发送时刻分别为0、2、4(假设该三个请求的发送时刻均为处于相同时间参考系的时刻),如图中的虚线方框所示,其中,发送时刻0早于发送时刻2,发送时刻2早于发送时刻4。当该三个请求到达服务器时,由于网络传输原因导致该三个请求到达服务器的时刻发生变化,发送时刻为4的请求最先到达服务器,其次是发送时刻为2的请求,发送时刻为0的请求最后到达服务器。图2中深色的方框表示该三个请求到达服务器时该服务器中其它正在排队等待被处理的请求。

按照fcfs原则,服务器将首先处理发送时刻为4的请求,其次处理发送时刻为2的请求,最后处理发送时刻为0的请求,该三个请求的待处理顺序如图2中fcfs对应的方框所示,其中,处理顺序为从右往左依次处理。

令发送时刻为4的请求被处理的时刻为a,服务器每处理一个请求所需时间为b,服务器处理完一个请求后立刻处理下一个请求,则该三个请求完成处理后的平均时延为[(a-4+0+b)+(a-2+b+b)+(a-0+2b+b)]/3=a-2+2b,其中,(a-4+0+b)表示发送时刻为4的请求的时延,(a-2+b+b)表示发送时刻为2的请求的时延,(a-0+2b+b)表示发送时刻为0的请求的时延。该三个时延中最高时延与上述平均时延的差值为b+2。

按照方法100,服务器将首先处理发送时刻为0的请求,其次处理发送时刻为2的请求,最后处理发送时刻为4的请求,该三个请求的待处理顺序如图2中当前延迟优先(currentlatencyfirst,clf)对应的方框所示,其中,处理顺序为从右往左依次处理。

令发送时刻为4的请求被处理的时刻为a,服务器每处理一个请求所需时间为b,服务器处理完一个请求后立刻处理下一个请求,则该三个请求完成处理后的平均时延为[(a-0+0+b)+(a-2+b+b)+(a-4+2b+b)]/3=a-2+2b,其中,(a-0+0+b)表示发送时刻为0的请求的时延,(a-2+b+b)表示发送时刻为2的请求的时延,(a-4+2b+b)表示发送时刻为4的请求的时延。该三个时延中最高时延与上述平均时延的差值为|b-2|。

相比于fcfs,clf调度方法可以使单个请求的最高时延与平均时延的差值减小2b(2>b>0)或4(b≥2)。

由此可见,本申请提供的调度方法100,能够减小同一个应用生成的不同请求的时延波动,增强计算机网络的稳定性。

可选地,该接收端根据该第一发送时刻和该第二发送时刻在同一时间基准下的时序确定该第一请求和该第二请求的待处理顺序,包括:

s121,该接收端根据该第一发送时刻和该第二发送时刻在同一时间基准下的时序确定该第一请求和该第二请求在请求队列中的位置,该请求队列包括至少一个待处理请求,该第一请求在该请求队列中的位置位于该至少一个待处理请求在该请求队列中的位置之后,且位于该第二请求在该请求队列中的位置之前。

s122,该接收端根据该第一请求和该第二请求在该请求队列中的位置确定该第一请求和该第二请求的待处理顺序,其中,该第一请求和该第二请求在该请求队列中的位置的顺序与该第一请求和该第二请求的待处理顺序相同。

在s121和s122中,服务器可以将全部待处理请求通过队列进行排序,每个请求占据请求队列中的一个位置,请求队列中的一个位置只能容纳一个请求,请求队列中的每个请求占据的位置的顺序与所述每个请求的待处理顺序相同。

例如,第一发送时刻早于第二发送时刻,则第一请求在请求队列中的位置排在第二请求在请求队列中的位置之前,并且,第一请求将先于第二请求被处理。

应理解,上述实施例仅是举例说明,本申请对确定第一请求和第二请求的待处理顺序的具体方式不做限定,例如,还可以通过“堆”或“栈”确定第一请求和第二请求的待处理顺序。

可选地,方法100还包括:

s130,该接收端根据第一平均发送时刻、第一平均到达时刻、第一平均往返时间和该第一发送时刻确定第一同步发送时刻,其中,该第一平均发送时刻为该第一发送端在第一周期内发送请求的时刻的平均值,该第一平均到达时刻为该第一发送端在该第一周期内发送的请求到达该接收端的时刻的平均值,该第一平均往返时间为在该第一周期内请求往返该接收端和该第一发送端所需的时间,该第一同步发送时刻为该第一发送时刻在该接收端的时间参考系中的时刻。

s140,该接收端根据第二平均发送时刻、第二平均到达时刻、第二平均往返时间和该第二发送时刻确定该第二同步发送时刻,其中,该第二平均发送时刻为该第二发送端在第二周期内发送请求的时刻的平均值,该第二平均到达时刻为该第二发送端在该第二周期内发送的请求到达该接收端的时刻的平均值,该第二平均往返时间为在该第二周期内请求往返该接收端和该第二发送端所需的时间,该第二同步发送时刻为该第二发送时刻在该接收端的时间参考系中的时刻。

s150,该接收端根据该第一同步发送时刻和该第二同步发送时刻确定该第一发送时刻和该第二发送时刻在同一时间基准下的时序。

令第一发送时刻为ttime1,第一平均发送时刻为avg.ttime1,第一平均到达时刻为avg.atime1,第一平均往返时间为avg.rtt1,第一同步时刻为δt1。

当第一周期内服务器接收到第一客户端的n个请求时,avg.ttime1等于该n个请求的发送时刻的平均值,avg.atime1为该n个请求到达服务器的时刻的平均值,avg.rtt1为该n个请求从第一客户端发送出至返回第一客户端所经历的时间的平均值,其中,n为正整数。服务器可以在每个周期之后更新上述参数的值。

n个第一发送时刻分别为ttime11,ttime12,…,ttime1n,由于,则该n个第一发送时刻在服务器时间参考系中的时刻分别为ttime11,ttime12,…,ttime1n。

avg.ttime1=(ttime11+ttime12+…+ttime1n)/n。

由于该n个第一发送时刻均为第一客户端记录的时刻,可能与服务器的时刻不同步,因此,令第一客户端的时间与服务器的时间的差值为t,t为任意的实数,则avg.ttime1=avg.ttime1ture+t,其中,avg.ttime1ture表示avg.ttime1在服务器的时间参考系中的时刻。

n个第一到达时刻分别为atime11,atime12,…,atime1n,该n个第一到达时刻均为服务器记录的时刻,因此,该n个第一到达时刻均为服务器时间参考系的时刻。

avg.atime1=(atime11+atime12+…+atime1n)/n。

n个第一往返时间为rtt11,rtt12,…,rtt1n,n个第一往返时间为服务器通过现有技术统计得到的基于服务器的时间参考系的往返时间。

avg.rtt1=(rtt11+rtt12+…+rtt1n)/n。

对于δt1,可以通过下述公式(1)确定。

δt1=ttime1+(avg.atime1–avg.ttime1)–avg.rtt1/2。(1)

其中,ttime1为第一周期之后的任意一个第一发送时刻,

avg.atime1–avg.ttime1=[(atime11–ttime11)+(atime12–ttime12)+…+(atime1n–ttime1n)]/n。

由于每个第一发送时刻与服务器的时间差值均为t,即,ttime11ture=ttime11+t,…,ttime1ntrue=ttime1n+t,其中,ttime11ture表示ttime11在服务器的时间参考系中的时刻,ttime1ntrue表示ttime1n在服务器的时间参考系中的时刻,因此,

avg.atime1–avg.ttime1=[(rtt11/2+rtt12/2+…+rtt1n/2)/n]–t

=avg.rtt1/2–t。

因此,根据公式(1),δt1=ttime1+avg.rtt1/2+t–avg.rtt1/2

=ttime1+t。

由此可见,通过公式(1)可以确定第一发送时刻在服务器的时间参考系中的时刻,即,将第一客户端记录的第一发送时刻ttime1转换为第一同步发送时刻为δt1。

类似地,可以通过公式(2)确定第二发送时刻在接收端的时间参考系中的时刻,将第二客户端记录的第二发送时刻ttime2转换为第二同步发送时刻δt2。

δt2=ttime2+(avg.atime2–avg.ttime2)–avg.rtt2/2。(2)

其中,avg.atime2为服务器记录的第二周期内第二请求到达服务器的时刻的平均值,即,第二平均到达时刻,avg.ttime2为第二周期内到达服务器的第二请求的发送时刻的平均值,即,第二平均发送时刻,avg.rtt2为第二周期内第二请求往返服务器和第二客户端的时间的平均值,即,第二平均往返时间。

第二周期与第一周期可以相同,也可以相异。

综上,根据本申请提供的方法100,可以确定第一发送时刻和第二发送时刻在同一时间基准下的时序。进而能够减小来自不同客户端的同一个应用生成的不同请求的时延波动,增强计算机网络的稳定性。

可选地,方法100还包括:

s160,该接收端在该第一请求中添加第一同步发送时刻标签,该第一同步发送时刻标签用于表示该第一同步发送时刻。

s170,该接收端在该第二请求中添加第二同步发送时刻标签,该第二同步发送时刻标签用于表示该第二同步发送时刻。

服务器计算出第一同步发送时刻和第二同步发送时刻后分别在第一请求和第二请求中添加相应的标签,以便于后续的处理过程可以根据第一同步发送时刻标签和第二同步发送时刻标签确定第一请求和第二请求的待处理顺序,无需再次进行计算,减小了服务器的计算负担。

可选地,该接收端确定第一发送时刻和第二发送时刻,包括:

s111,该接收端根据该第一请求携带的第一发送时刻标签确定该第一发送时刻,该第一发送时刻标签用于表示该第一发送时刻。

s112,该接收端根据该第二请求携带的第二发送时刻标签确定该第二发送时刻,该第二发送时刻标签用于表示该第二发送时刻。

从而,服务器可以确定第一请求和第二请求的发送时刻。

可选地,该第一发送时刻标签位于该第一请求的头部,该第二发送时刻标签位于该第二请求的头部。上述发送时刻标签也可以位于请求的其它部位。

可选地,该第一请求包括该第一发送端的标识,该第二请求包括该第二发送端的标识。

从而,服务器可以根据上述标识确定请求来自于哪个客服端,并根据相应的公式计算请求的同步发送时刻。

在本申请中,接收端对请求的处理可能包括多个处理阶段,对于同一个应用生成的请求,接收端在该多个处理阶段中的每个处理阶段均按照方法100确定各个请求的待处理顺序。

图3示出了一种包括多个处理阶段的请求调度方法。如图3所示,一个请求生成后经过以下四个处理阶段:

发送阶段(sendstage),请求从客户端发送至服务器端;

查找阶段(lookupstage),服务器查找数据所在的位置,其中,该请求用于请求服务器查找数据;

数据阶段(datastage),服务器读取该请求所需要的数据;

反馈阶段(replystage),服务器将该请求的处理结果反馈给客户端。

对于发送阶段,控制器(controller)将发送时刻(ttime)标签和客户端标签添加到请求的头部。

请求到达服务器后,控制器根据ttime和客户端标签确定请求的同步发送时刻δt,并将标识该同步发送时刻的标签添加至请求头部,从而,服务器在不同的阶段均可以快速确定请求的同步发送时刻。

随后,控制器将请求插入至查找阶段的请求队列,对于同一个应用程序生成的请求来说,δt越早的请求越靠近请求队列的头部,即,δt较早的请求优先被处理,不同应用程序生成的请求可以按照fcfs方法确定待处理顺序。

对于数据阶段和反馈阶段,每个阶段均按照与查找阶段相同的方法确定各个请求在请求队列中的位置。

上文详细介绍了本申请提供的调度方法的示例。可以理解的是,接收端和发送端为了实现上述功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。

在采用集成的单元的情况下,图4示出了上述实施例中所涉及的服务器(即,处理请求的装置)的一种可能的结构示意图。服务器400包括:处理单元402和通信单元403。处理单元402用于对服务器400的动作进行控制管理,例如,处理单元402用于支持服务器400执行图1的s120和/或用于本文所描述的技术的其它过程。通信单元403用于支持服务器400与其它网络实体的通信,例如与客户端之间的通信。服务器400还可以包括存储单元401,用于存储服务器400的程序代码和数据。

其中,处理单元402可以是处理器或控制器,例如可以是中央处理器(centralprocessingunit,cpu),通用处理器,数字信号处理器(digitalsignalprocessor,dsp),专用集成电路(application-specificintegratedcircuit,asic),现场可编程门阵列(fieldprogrammablegatearray,fpga)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。所述处理器也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,dsp和微处理器的组合等等。通信单元403可以是通信接口等。存储单元401可以是存储器。

当处理单元402为处理器,通信单元403为通信接口,存储单元401为存储器时,本申请所涉及的服务器可以为图5所示的服务器。

参阅图5所示,该服务器500包括:处理器502、通信接口503、存储器501。其中,通信接口503、处理器502以及存储器501可以通过内部连接通路相互通信,传递控制和/或数据信号。

所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,上述描述的装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不加赘述。

本申请提供的服务器400和服务器500,可以减小来自不同客户端的同一个应用生成的不同请求的时延波动,增强计算机网络的稳定性。

在本申请各个实施例中,各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请的实施过程构成任何限定。

另外,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。

结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现,也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于随机存取存储器(randomaccessmemory,ram)、闪存、只读存储器(readonlymemory,rom)、可擦除可编程只读存储器(erasableprogrammablerom,eprom)、电可擦可编程只读存储器(electricallyeprom,eeprom)、寄存器、硬盘、移动硬盘、只读光盘(cd-rom)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于asic中。另外,该asic可以位于服务器中。

在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,dvd)、或者半导体介质(例如固态硬盘(solidstatedisk,ssd))等。

以上所述的具体实施方式,对本申请的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本申请的具体实施方式而已,并不用于限定本申请的保护范围,凡在本申请的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括在本申请的保护范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1