基于服务器和客户端架构的业务处理方法及业务处理系统的制作方法
【技术领域】
[0001]本发明涉及通信领域，具体地，涉及一种基于服务器和客户端架构的业务处理方法及业务处理系统。
【背景技术】
[0002]在客户端与服务器的通信过程中，客户端向服务器主动发起请求，并等待服务器的响应，由此完成一个生命周期。如果服务器对响应的处理速度足够快，则服务器可以从容应对多个请求，实现平稳运行。但是，如果服务器端的业务处理比较复杂且耗时(即，此时服务器端的业务处理需要较长的时间，客户端一直占用与服务器的连接资源用于等待)，那么必定会造成客户端的请求等待、排队、淤积，使得服务器的并发处理能力降低，从而引发一系列的问题:比如服务超时、客户端始终得不到响应、服务器超载等等，最终还可能导致资源耗尽、崩溃死机等严重后果。
【发明内容】
[0003]本发明的目的是提供一种基于服务器和客户端架构的业务处理方法及业务处理系统，以解决现有技术中服务器并发处理能力低的问题。
[0004]为了实现上述目的，本发明提供一种基于服务器和客户端架构的业务处理方法，其中该方法包括:所述客户端发送业务处理请求；所述服务器接收并存储所述业务处理请求；所述服务器发送第一响应消息至所述客户端，该第一响应消息包括所述业务处理请求的标识；以及所述服务器基于所述业务处理请求对业务进行处理，并保存处理结果。
[0005]本发明还提供一种业务处理系统，该系统包括客户端和服务器，其中:所述客户端用于发送业务处理请求；所述服务器包括:接收装置，用于接收并存储所述业务处理请求，发送装置，用于发送第一响应消息至所述客户端，该第一响应消息包括所述业务处理请求的标识；以及处理装置，用于基于所述业务处理请求对业务进行处理，并保存处理结果。
[0006]通过上述技术方案，服务器从所述客户端接收并存储业务处理请求，并且发送第一响应消息至客户端，这样客户端就不会再继续占用连接资源来等待处理结果，避免了不必要的等待、排队，之后服务器基于业务处理请求对业务进行处理，并保存处理结果。由此，通过将并发处理的业务进行异步处理拆分，避免并发请求形成耗时间占资源的排队阻塞，从而提高了服务器并发处理能力。也就是，无需改变原有业务逻辑，通过解耦方法来提高服务器的吞吐量。
[0007]本发明的其它特征和优点将在随后的【具体实施方式】部分予以详细说明。
【附图说明】
[0008]附图是用来提供对本发明的进一步理解，并且构成说明书的一部分，与下面的【具体实施方式】一起用于解释本发明，但并不构成对本发明的限制。在附图中:
[0009]图1是根据本发明一种实施方式的基于服务器和客户端架构的业务处理方法的流程图；
[0010]图2是根据本发明一种实施方式的业务处理系统的方框图；以及
[0011]图3是根据本发明一种实施方式的服务器的方框图。
【具体实施方式】
[0012]以下结合附图对本发明的【具体实施方式】进行详细说明。应当理解的是，此处所描述的【具体实施方式】仅用于说明和解释本发明，并不用于限制本发明。
[0013]图1是根据本发明一种实施方式的基于服务器和客户端架构的业务处理方法的流程图。
[0014]如图1所示，本发明提供的一种基于服务器和客户端架构的业务处理方法包括:
[0015]S100，所述客户端发送业务处理请求；
[0016]S102，所述服务器接收并存储所述业务处理请求；
[0017]S104，所述服务器发送第一响应消息至所述客户端，该第一响应消息包括所述业务处理请求的标识；以及
[0018]S106，所述服务器基于所述业务处理请求对业务进行处理，并保存处理结果。
[0019]通过服务器从所述客户端接收并存储业务处理请求，并且发送第一响应消息至客户端(即，解耦)，这样客户端就不会再继续占用连接资源来等待处理结果，避免了不必要的等待、排队，之后服务器基于业务处理请求对业务进行处理，并保存处理结果。由此，通过将并发处理的业务进行异步处理拆分，避免并发请求形成耗时间占资源的排队阻塞，从而提高了服务器并发处理能力和吞吐量。也就是，无需改变原有业务逻辑，通过解耦方法来提高服务器的吞吐量。
[0020]在本发明中，解耦指的是将并发处理的业务进行异步处理拆分，服务器端对客户端的请求即刻返回，而实质性的耗时、耗资源的业务处理由服务器端的专门的工作线程逐一进行处理。在这种情况下，无论业务处理有多缓慢，由于没有阻塞和占用，客户端都无从察觉，而服务器的吞吐量已经得以提升。
[0021]其中，该方法还包括:
[0022]S108，所述客户端发送请求处理结果的请求，其中所述请求处理结果的请求包括所述业务处理请求的标识；
[0023]S110，所述服务器接收所述请求处理结果的请求；
[0024]S112，所述服务器基于所述请求处理结果的请求判断是否存在与所述业务处理请求的标识对应的处理结果，如果是，转至步骤S114，否则转至步骤S116 ；
[0025]S114，在判断为存在的情况下，所述服务器将该处理结果发送给所述客户端；
[0026]S116，在判断为不存在的情况下，所述服务器发送表示不存在所述处理结果的第二响应消息至所述客户端，并继续接收所述客户端在未接收到所述处理结果的情况下在下一个轮询时间节点发送的所述请求处理结果的请求。
[0027]也就是，如果服务器已经处理完毕，客户端发送请求后就可以获得处理结果，否则客户端将在到达下一个轮询时间节点时再次请求。可以看出，服务器对处理结果的请求也是立即响应并返回的，客户端几乎不需要等待。
[0028]通过将客户端发起的业务处理请求与请求处理结果的请求进行异步处理拆分，艮P，从业务处理请求与请求处理结果的请求统一并发到服务器(相同的后台服务)改为分别将两类请求分发到服务器(两个分离的后台服务)，由此，由于两类请求复杂程度基本相当，分开后可以加倍服务器后台处理容量。
[0029]根据本发明一种实施方式，所述业务处理请求包括表示业务类型的信息。
[0030]对于待处理的业务通常可以分为两种:依赖第三方服务的业务和不依赖第三方服务的业务，其中不依赖于第三方服务的业务可控性较高，一旦出现问题，其排查速度较快、所需恢复时间较短；而依赖于第三方服务的业务，故障排查涉及面广，链路长，复杂度高，往往比较困难，恢复需要的时间较长。因此，通过将表示业务类型的信息包括在业务处理请求中可以对不依赖第三方服务的业务和依赖第三方服务的业务进行区分。由此，可以避免相互的恶性干扰，其中一类服务的异常不会导致另一类服务的不可用，进而可以保证不依赖第三方服务的那些业务得以顺利处理，而不会位列于关于依赖第三方服务的请求之后，从而能够降低可能发生淤积队列的成员数量，降低配对阻塞风险。
[0031]根据本发明一种实施方式，所述处理结果保存在数据库或缓存中。优选地，所示处理结果保存在缓存中。由此，通