CN110430238A - 长连接管理方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本发明涉及基架运维技术领域，本发明公开了一种长连接管理方法，所述长连接管理方法包括以下步骤：在第一次发送Http请求时，建立客户端与服务器之间的长连接；判断所述长连接是否符合长连接管理策略；若所述长连接符合长连接管理策略，则将所述长连接缓存在对应的Http连接池；判断缓存在Http连接池中的长连接是否满足第一预设条件；若不满足，则释放不满足所述第一预设条件的长连接；判断客户端是否继续发送Http请求；若客户端继续发送Http请求，则使用Http连接池中的长连接与服务器进行交互。本发明还公开了一种长连接管理装置、设备及计算机可读存储介质。本发明实现了对长连接的管理，提高了用户体验。

Description

长连接管理方法、装置、设备及计算机可读存储介质

技术领域

本发明涉及基架运维技术领域，尤其涉及一种长连接管理方法、装置、设备及计算机可读存储介质。

背景技术

目前，业内有一部分的Http请求处理，是基于短连接实现的，对于客户端请求，服务端大多是同步IO处理，完成请求，客户端即释放连接。频繁的创建连接和释放连接，以及三次握手通信和四次挥手ACK都浪费了很大时长，另一部分是基于长连接实现的，Http长连接是指基于一个TCP连接来发送或接收多个Http请求。Http长连接具有多个优点：减少建立和拆除TCP连接的次数，降低Http请求过程中的网络总耗时；降低服务器和终端设备的CPU利用率；降低服务器和终端设备的网络I/O开销；提高服务器处理Http请求的速度,长连接解决了三次握手通信和四次挥手ACK所占据的时长，由于服务器需要长时间维护长连接的状态信息，Http长连接会增加服务器的内存使用率。考虑到Http长连接的以上优点，尤其是在降低建立连接的网络耗时方面的优势(在慢速无线网络如2G、3G、4G、WiFi中，Http长连接能够显著降低网络总耗时)，Http长连接目前已经成为无线应用性能优化的主要方法之一。但是，目前的技术无法对长连接进行管理，由于无法对长连接进行管理，则现有技术中产生的长连接则存在不能适应各种实际场景的情况，会给用户带来诸多不便。因此，如何解决现有技术中不能对长连接进行管理的问题，成为了目前亟待解决的技术问题。

发明内容

本发明的主要目的在于提供一种长连接管理方法、装置、设备及计算机可读存储介质，旨在解决现有技术中不能管理长连接的技术问题。

为实现上述目的，本发明提供一种长连接管理方法，所述长连接管理方法包括以下步骤：

在第一次发送Http请求时，建立客户端与服务器之间的长连接；

判断所述长连接是否符合长连接管理策略；

若所述长连接符合长连接管理策略，则将所述长连接缓存在对应的Http连接池，若所述长连接不符合长连接管理策略，则不处理；

判断缓存在Http连接池中的长连接是否满足第一预设条件；

若不满足，则释放不满足所述第一预设条件的长连接，若满足，则不处理；

判断客户端是否继续发送Http请求；

若客户端继续发送Http请求，则使用Http连接池中的长连接与服务器进行交互，若客户端未继续发送Http请求，则不处理。

可选地，在所述在客户端发送第一次Http请求时，建立客户端与服务器之间的长连接的步骤之前，还包括以下步骤：

设置建立客户端与服务器之间的长连接的条件。

可选地，所述在客户端发送第一次Http请求时，建立客户端与服务器之间的长连接包括以下步骤：

在第一次发送Http请求时，通过轮询的方式检测心跳包的时间，判断所述心跳包的时间是否大于预设阈值；

若所述心跳包的时间大于预设阈值，则建立客户端与服务器之间的长连接，若所述心跳包的时间小于或等于预设阈值，则不处理。

可选地，在所述若待建立的长连接能被保持，则建立客户端与服务器之间的长连接的步骤之后,还包括以下步骤：

通过轮询的方式检测心跳包的时间，根据所述心跳包的时间判断已建立的长连接的保持时长是否达到预设保持时长；

若已建立的长连接的保持时长达到预设保持时长，则断开超过所述预设保持时长的长连接，若已建立的长连接的保持时长未达到预设保持时长，则不处理。

可选地，在所述判断客户端是否继续发送Http请求的步骤之前，还包括以下步骤：

在客户端设置自定义重试策略；

根据所述自定义重试策略，判断客户端是否能从Http连接池获得长连接；

若客户端能从Http连接池获得长连接，则将所述长连接返回给客户端使用，若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作。

可选地，在所述若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作的步骤之后，还包括以下步骤：

判断通过当前重试操作获取到的长连接是否符合长连接返回客户端的第二预设条件；

若符合第二预设条件，则将通过当前重试操作获取到的长连接返回客户端，若不符合第二预设条件，则不处理。

可选地，在所述若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作的步骤之前，还包括以下步骤：

设置重试操作的间隔时间。

进一步地，为实现上述目的，本发明还提供一种长连接管理装置，所述长连接管理装置包括：

建立模块，用于在第一次发送Http请求时，建立客户端与服务器之间的长连接；

第一判断模块，用于判断所述长连接是否符合长连接管理策略；

第一缓存模块，用于在所述长连接符合长连接管理策略时，将所述长连接缓存在对应的Http连接池；

第二判断模块，用于判断缓存在Http连接池中的长连接是否满足第一预设条件；

第一释放模块，用于当缓存在Http连接池中的长连接是不满足第一预设条件时，释放不满足所述第一预设条件的长连接；

第三判断模块，用于判断客户端是否继续发送Http请求；

使用模块，用于在客户端继续发送Http请求时，使用Http连接池中的长连接与服务器进行交互。

可选地，所述长连接管理装置还包括：

第一设置模块，用于设置建立客户端与服务器之间的长连接的条件。

可选地，所述建立模块包括：

第一判断单元，用于在第一次发送Http请求时，通过轮询的方式检测心跳包的时间，判断所述心跳包的时间是否大于预设阈值；

第一建立单元，用于若所述心跳包的时间大于预设阈值，则建立客户端与服务器之间的长连接。

可选地，所述长连接管理装置还包括：

第四判断模块，用于通过轮询的方式检测心跳包的时间，根据所述心跳包的时间判断已建立的长连接的保持时长是否达到预设保持时长；

断开模块，用于若已建立的长连接的保持时长达到预设保持时长，则断开超过所述预设保持时长的长连接。

可选地，所述长连接管理装置还包括：

第二设置模块，用于在客户端设置自定义重试策略；

第五判断模块，用于根据所述自定义重试策略，判断客户端是否能从Http连接池获得长连接；

第一返回模块，用于若客户端能从Http连接池获得长连接，则将所述长连接返回给客户端使用；

操作模块，用于若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作。

可选地，所述操作模块包括：

判断单元，用于判断当前重试操作是否符合长连接返回请求端的预设条件；

返回单元，用于若当前重试操作符合长连接返回请求端的预设条件，则将长连接返回请求端。

可选地，所述长连接管理装置还包括：

第六判断模块，用于判断通过当前重试操作获取到的长连接是否符合长连接返回客户端的第二预设条件；

第二返回模块，用于若通过当前重试操作获取到的长连接符合长连接返回客户端的第二预设条件，则将通过当前重试操作获取到的长连接返回客户端。

可选地，所述长连接管理装置还包括：

第三设置模块，用于预先设置重试操作的时间间隔。

进一步地，为实现上述目的，本发明还提供一种长连接管理设备，所述长连接管理设备包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的长连接管理程序，所述长连接管理程序被所述处理器执行时实现如上述任一项所述的长连接管理方法的步骤。

进一步地，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有长连接管理程序，所述长连接管理程序被处理器执行时实现如上述任一项所述的长连接管理方法的步骤。

本发明通过自定义策略，可以将符合现实场景需求的长连接缓存进连接池，这样可以在缓存长连接之前，提前筛选出最适合缓存的长连接，这样可以提高有效长连接的数目，另外，在本实施例中，需要先判断已经符合缓存条件的长连接是否满足预设条件，因为这个预设条件也是根据实际场景的需要而设立的，因此可以保证缓存在连接池内的长连接都是符合现实场景需求的有效长连接，从而可以提高连接池中有效长连接的占比可以达到最优，如果有客户端送Http的请求，则可以直接使用已经建立好的，且缓存在连接池中的长连接，既避免了重复建立，又通过预设的条件保证了连接池内有效长连接的占比，节约了连接池内的缓存资源。

附图说明

图1为本发明实施例方案涉及的长连接管理设备运行环境的结构示意图；

图2为本发明长连接管理方法第一实施例的流程示意图；

图3为本发明长连接管理方法第二实施例的流程示意图；

图4为图2中步骤S10的细化流程示意图；

图5为本发明长连接管理方法第三实施例的流程示意图；

图6为本发明长连接管理方法第四实施例的流程示意图；

图7为本发明长连接管理方法第五实施例的流程示意图；

图8为本发明长连接管理方法第六实施例的流程示意图；

图9为本发明长连接管理装置一实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明提供一种长连接管理设备。

参照图1，图1为本发明实施例方案涉及的长连接管理设备设备运行环境的结构示意图。

如图1所示，该长连接管理设备包括：处理器1001，例如CPU，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的长连接管理设备的硬件结构并不构成对长连接管理设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机可读存储介质的存储器1005中可以包括操作***、网络通信模块、用户接口模块以及长连接管理程序。其中，操作***是管理和控制长连接管理设备和软件资源的程序，支持长连接管理程序以及其它软件和/或程序的运行。

在图1所示的长连接管理设备的硬件结构中，网络接口1004主要用于接入网络；用户接口1003主要用于侦测确认指令和编辑指令等。而处理器1001可以用于调用存储器1005中存储的长连接管理程序，并执行以下长连接管理方法的各实施例的操作。

基于上述长连接管理设备硬件结构，提出本发明长连接管理方法的各个实施例。

参照图2，图2为本发明长连接管理方法第一实施例的流程示意图。本实施例中，所述长连接管理方法包括以下步骤：

步骤S10，在第一次发送Http请求时，建立客户端与服务器之间的长连接；

本实施例中，在客户端发送第一次Http请求时，客户端与服务器之间建立长连接，并获得长连接，在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输Http数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件，如Apache中设定这个时间。要注意的是，实现长连接的前提是需要要客户端和服务端都支持长连接。例如，在Http/1.0中，默认使用的是短连接，也就是说，浏览器和服务器每进行一次Http操作，就建立一次连接，但任务结束就中断连接，如果客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个Http会话，由于Http/1.0仅支持短连接，因此无法获取长连接。

步骤S20，判断所述长连接是否符合长连接管理策略；

本实施例中，长连接管理策略指的是自客户端发起建立长连接的信息时起，开始心跳计时，在设定时间内如果收到客户端发来的消息，则重置计时器，并将长连接缓存进Http连接池，否则计时结束并断开长连接。本实施例中，为了对获取的长连接进行管理，因此，需要判断获取的长连接是否符合自定义策略。自定义策略可以根据实际场景的需求进行设定，例如，在建立第一次长连接后，由于该长连接继续保持对用户来说并不具备实用性，而且会占用Http连接池的内存，因此可以设自定义，以对长连接实现个性化的管理。

步骤S30，若所述长连接符合长连接管理策略，则将所述长连接缓存在对应的Http连接池，若所述长连接不符合长连接管理策略，则不处理；

本实施例中，对Http连接池划分出了不同的管理区域，当获取的长连接符合自定义策略时，则可以根据长连接的类型将长连接分别放入不同的管理区域内，例如，例如由请求会话而产生的长连接与请求网页而产生的长连接，是不同类型的，因此可以给不同的长连接设置不同的标识，并建立不同的长连接与Http连接池的不同的管理区域之间的映射关系，当获取到某一类型的长连接时，则可以根据不同的长连接与Http连接池的不同的管理区域之间的映射关系将该长连接放入与其相匹配的管理区域内。另外，当获取到的长连接不符合自定义策略时，则说明该长连接不必放入Http连接池。

步骤S40，判断缓存在Http连接池中的长连接是否满足第一预设条件；

本实施例中，第一预设条件指的是在规定时间内缓存在Http连接池中的长连接可以被重复利用。当获取到的长连接分门别类地保存在Http连接池中的不同管理区域时，并不意味着这些长连接就要无限期地保存下去，因为随着建立的长连接越来越多，所需要占据的空间也越来越大，然而Http连接池的空间是有限的，因此，对于已经保存进来的长连接，应该为其设置条件，并判断Http连接池中的长连接是否满足预设条件。例如，可以设置长连接在同一时间段被复用的频率，若存在复用的频率低于预设阈值的长连接，则可以认为这些长连接在单位时间内占据的Http连接池的空间较大，应该及时处理。

步骤S50，若不满足，则释放不满足所述第一预设条件的长连接，若满足，则不处理；

本实施例中，经过判断，若Http连接池内的长连接满足预设条件，则说明，此时Http连接池内的长连接复用的频率较高，因此可以继续保存。如果存在不满足预设条件的长连接，则需要将不满足预设条件长连接释放出去。

步骤S60，判断客户端是否继续发送Http请求；

本实施例中，在客户端发送第一次Http请求时，客户端与服务器之间建立长连接，并获得长连接后，还有可能在客户端二次或者更多次发送Http请求，因此在本实施例中需要判断客户端是否发送Http请求。

步骤S70，若客户端继续发送Http请求，则使用Http连接池中的长连接与服务器进行交互，若客户端未继续发送Http请求，则不处理。

本实施例中，例如，可以设置Http连接池中的长连接可以保存20秒钟，在20秒钟内若在客户端发送再次Http请求，服务器为了响应其请求，可以直接从Http连接池中获取长连接。通过自定义策略，可以将符合现实场景需求的长连接缓存进连接池，这样可以在缓存长连接之前，提前筛选出最适合缓存的长连接，这样可以提高有效长连接的数目，另外，在本实施例中，需要先判断已经符合缓存条件的长连接是否满足预设条件，因为这个预设条件也是根据实际场景的需要而设立的，因此可以保证缓存在连接池内的长连接都是符合现实场景需求的有效长连接，从而可以提高连接池中有效长连接的占比可以达到最优，如果有客户端送Http的请求，则可以直接使用已经建立好的，且缓存在连接池中的长连接，既避免了重复建立，又通过预设的条件保证了连接池内有效长连接的占比，节约了连接池内的缓存资源。

参照图3，图3为本发明长连接管理方法第二实施例的流程示意图。本实施例中，所述长连接管理方法包括以下步骤：

步骤S80，设置建立客户端与服务器之间的长连接的条件。

本实施例中，由于在某些场景下，需要不断建立连接，并不断释放连接，所以如果建立长连接的话，则有可能不适宜现实场景的需求，因此可以不建立长连接，而是建立短连接，又或者是不建立任何连接。因此为了适应现实场景的需求，应该在建立长连接之前，就预先设置好建立长连接的条件，只有在符合建立长连接的条件下，才可以建立长连接，否则，则不建立长连接，可根据实际场景的需求，不建立任何连接或者是建立短连接，以便可以更加灵活地适应不同场景下对建立的连接的需求。

参照图4，图4为图2中步骤S10的细化流程示意图。本实施例中，上述步骤S10进一步包括以下步骤：

步骤S101，在第一次发送Http请求时，通过轮询的方式检测心跳包的时间，判断所述心跳包的时间是否大于预设阈值；

本实施例中，客户端发送第一次Http请求时，判断所述建立的长连接是否能被保持，其原因是在客户端发送第一次Http请求时，客户端与服务器之间会建立长连接，但是建立的长连接能不能被保持需要由预设条件来限定，即通过轮询的方式检测心跳包的时间，根据检测到的时间判断是否建立长连接，只有在心跳包的时间大于预设阈值时，才建立长连接。

在第一次发送Http请求时，通过轮询的方式检测心跳包的时间，判断所述心跳包的时间是否大于预设阈值。

例如，在实际场景中，保存长连接并没有任何意义，那么该连接就可以不必保持，在本实施例中不被保持的长连接等同于短连接，这样的设置可以使长连接更加符合实际场景的需求。若在实际场景中保持长连接是有益的，则可以保持长连接。在长连接不被保持的情况下，当一个网页打开完成后，客户端和服务器之间用于传输Http数据的TCP连接会关闭，如果客户端再次访问这个服务器上的网页，则需要重新建立长连接。

步骤S102，若所述心跳包的时间大于预设阈值，则建立客户端与服务器之间的长连接，若所述心跳包的时间小于或等于预设阈值，则不处理。

本实施例中，因为建立的长连接可能在实际场景中仅需建立一次，随后就要立即被释放，所以，应该预先判断在某种场景下刚刚建立好的长连接能否被保持，若能被保持则获得所述建立的长连接，若不能，则需要立即断开。若所述心跳包的时间大于预设阈值，则建立客户端与服务器之间的长连接，若所述心跳包的时间小于或等于预设阈值，则不处理。

参照图5，图5为本发明长连接管理方法第三实施例的流程示意图。本实施例中，在图4中的步骤S102之后，还包括以下步骤：

步骤S90，通过轮询的方式检测心跳包的时间，根据所述心跳包的时间判断已建立的长连接的保持时长是否达到预设保持时长；

本实施例中，如果长连接确定需要被保持了，但是根据实际场景的需求，这些长连接不可能一直被保持下去，因此在本实施例中，需要判断长连接的保持时间是否在预先设置的保持时间内，因此在本实施例中，通过轮询的方式检测心跳包的时间，根据所述心跳包的时间判断已建立的长连接的保持时长是否达到预设保持时长。

步骤S100，若已建立的长连接的保持时长达到预设保持时长，则断开超过所述预设保持时长的长连接，若已建立的长连接的保持时长未达到预设保持时长，则不处理。

本实施例中，要预先设置好长连接需要保持的时间，再判断当前的长连接是否超过预设保持时间的阈值，若超过了，说明此长连接已经过了保持的有效期，需要断开，若没有超过预设保持时间的阈值，则说明此长连接已经没有超过需要保持的有效期，则此长连接需要继续保持。预设条件指的是，在预设时间内长连接是否被复用，本实施例中，由于连接池中可以缓存的长连接的数量是一定的，所以当在预定时间内连接池的长连接没有被重复利用，则需要及时释放出，这样可以避免连接池中的无效长接存在。通过本实施例可以极大节约连接池的缓存空间，并使得连接池内有效长连接的占的比例增加。

参照图6，图6为本发明长连接管理方法第四实施例的流程示意图。本实施例中，在所述判断客户端是否继续发送Http请求的步骤之前，还包括以下步骤：

步骤S110，在客户端设置自定义重试策略；

本实施例中，自定义重试策略指的是在无法获取长连接时，发起多次重试操作。自定义重试策略是客户端可以自己拓展HttpRequest RetryHandler，实现自己的重试请求，HttpRequestRetryHandler实际上是DefaultHttp Re-questRetryHandler的子类，这是一个标准的retry方案，其目的是为了保证幂等约定resetful接口必须是GET,HEAD,PUT,DELETE,OPTIONS,and TRACE中的一种。HttpRequestRetryHandler是Http请求出错后的重试的处理接口类,对于在某些要求比较严格的业务情况下接口参数比较重要。在实际场景中会存这种情况：在客户端发送第一次Http请求时，客户端与服务器之间建立了长连接，这些长连接被成功保存至Http连接池中，但是在对Http连接池中的长连接进行复用的时候，发生了网络故障，例如断网，此时，用户正在发送文件，而在网络恢复后，用户则需要重新发送该文件，这样反复的操作会造成用户体验度下降。因此在本实施例中设置自定义重试策略，在发生网络故障且网络故障恢复后，该文件可以根据自定义重试策略重新发送，无需再次进行人为操作。

步骤S120，根据所述自定义重试策略，判断客户端是否能从Http连接池获得长连接；

本实施例中，需要根据自定义重试策略判断Http请求端是否能从Http连接池正常获得长连接，因为只有在符合Http连接池中预设保存条件的长连接才能在客户端再次发起来请求时，才可以再次从Http连接池中被调用出来，以上实现在客户端与服务器之间再次建立长连接。

步骤S130，若客户端能从Http连接池获得长连接，则将所述长连接返回给客户端使用；

本实施例中，若客户端能从Http连接池获得长连接，则将所述长连接返回给客户端使用。因为已建立的长连接均缓存在Http缓存连接池内，如果客户端能从Http连接池获得长连接，说明客户端需要获得到的长连接，即客户端发起了使用长连接的请求，因此需要将长连接返回给客户端使用，如果客户端不能从Http连接池获得长连接，则不处理。

步骤S140，若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作。

本实施例中，在服务端或者网络发生一些异常时，用户可以对未正常返回的请求做一些补偿措施。例如，通过自定义重试策略对异常幂等请求做多次重试操作。例如，可以设置这样的重试策略：如果重试超过3次，则不再重试；几种特殊异常及其子类，不进行重试；同一个请求在异步任务重已经被终止，则不进行重试；幂等的方法可以进行重试，比如Get；如果请求没有发送成功，可以进行重试。

参照图7，图7为本发明长连接管理方法第五实施例的流程示意图。本实施例中，在所述若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作的步骤之后，还包括以下步骤：

步骤S150，判断通过当前重试操作获取到的长连接是否符合长连接返回客户端的第二预设条件；

本实施例中，第二预设条件指的是客户端当前需要的长连接。本实施例中，需要判断当前重试操作是否符合长连接返回请求端的第二预设条件，即使Http连接池中的长连接符合被复用的条件，但是如果当前重试操作不符合长连接返回请求端的第二预设条件，则长连接依然不能返回客户端，即客户端当前不需要此长连接。

步骤S160，若符合第二预设条件，则将通过当前重试操作获取到的长连接返回客户端，若不符合第二预设条件，则不处理。

本实施例中，例如，在Http请求端发出长连接请求时，也可能会出现服务端发生故障的情况或者是出现断网的情况，在现有技术中，若出现此类情况，则无法获得长连接，在本方案中，优选地，在遇到断网这种情况或者是服务器发生故障的情况下，默认重试三次，在这三次重试请求长连接的过程中，若服务器恢复正常，或者是网络恢复连接，则可以成功获得长连接，而不必人为地再次从Http请求端发起长连接复用请求。若经过三次重试，服务器未恢复正常，或者是网络未恢复连接，则不能从连接池中获得Http请求端请求复用的长连接。

参照图8，图8为本发明长连接管理方法第六实施例的流程示意图。本实施例中，在所述若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作的步骤之前，还包括以下步骤：

步骤S170，设置重试操作的间隔时间。

本实施例中，重试操作的时间间隔可以预先设定，例如，在Http请求端第一次发起长连接复用请求，但请求端未获得长连接，这是第一次操作，在Http请求端第二次发起长连接复用请求，但请求端未获得长连接，这是第二次操作，在Http请求端第三次发起长连接复用请求，但请求端未获得长连接，这是第三次操作，其中第一次操作与第二次操作之间的时间间隔，第二次操作与第三次操作之间的时间间隔是可以预先设定的，可以将时间间隔设置成固定的5秒钟。通过预先设置重试操作的时间间隔可以更加适应实际场景的需求。

本发明还提供一种长连接管理装置。

参照图9，图9为本发明长连接管理装置一实施例的功能模块示意图。本实施例中，所述长连接管理装置包括：

建立模块10，用于在第一次发送Http请求时，建立客户端与服务器之间的长连接；

第一判断模块20，用于判断所述长连接是否符合长连接管理策略；

第一缓存模块30，用于在所述长连接符合长连接管理策略时，将所述长连接缓存在对应的Http连接池；

第二判断模块40，用于判断缓存在Http连接池中的长连接是否满足第一预设条件；

第一释放模块50，用于当缓存在Http连接池中的长连接是不满足第一预设条件时，释放不满足所述第一预设条件的长连接；

第三判断模块60，用于判断客户端是否继续发送Http请求；

使用模块70，用于在客户端继续发送Http请求时，使用Http连接池中的长连接与服务器进行交互。

本实施例中，建立模块10用于在第一次发送Http请求时，建立客户端与服务器之间的长连接；第一判断模块20用于判断所述长连接是否符合长连接管理策略；第一缓存模块30用于在所述长连接符合长连接管理策略时，将所述长连接缓存在对应的Http连接池；第二判断模块40用于判断缓存在Http连接池中的长连接是否满足第一预设条件；第一释放模块50用于当缓存在Http连接池中的长连接是不满足第一预设条件时，释放不满足所述第一预设条件的长连接；第三判断模块60用于判断客户端是否继续发送Http请求；使用模块70用于在客户端继续发送Http请求时，使用Http连接池中的长连接与服务器进行交互。通过自定义策略，可以将符合现实场景需求的长连接缓存进连接池，这样可以在缓存长连接之前，提前筛选出最适合缓存的长连接，这样可以提高有效长连接的数目，另外，在本实施例中，需要先判断已经符合缓存条件的长连接是否满足预设条件，因为这个预设条件也是根据实际场景的需要而设立的，因此可以保证缓存在连接池内的长连接都是符合现实场景需求的有效长连接，从而可以提高连接池中有效长连接的占比可以达到最优，如果有客户端送Http的请求，则可以直接使用已经建立好的，且缓存在连接池中的长连接，既避免了重复建立，又通过预设的条件保证了连接池内有效长连接的占比，节约了连接池内的缓存资源。

本发明还提供一种计算机可读存储介质。

本实施例中，所述计算机可读存储介质上存储有长连接管理程序，所述长连接管理程序被处理器执行时实现如上述任一项实施例中所述的长连接管理方法的步骤。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，这些均属于本发明的保护之内。

Claims (10)

1.一种长连接管理方法，其特征在于，所述长连接管理方法包括以下步骤：

在第一次发送Http请求时，建立客户端与服务器之间的长连接；

判断所述长连接是否符合长连接管理策略；

若所述长连接符合长连接管理策略，则将所述长连接缓存在对应的Http连接池；

判断缓存在Http连接池中的长连接是否满足第一预设条件；

若不满足，则释放不满足所述第一预设条件的长连接；

判断客户端是否继续发送Http请求；

若客户端继续发送Http请求，则使用Http连接池中的长连接与服务器进行交互。

2.如权利要求1所述的长连接管理方法，其特征在于，在所述在客户端发送第一次Http请求时，建立客户端与服务器之间的长连接的步骤之前，还包括以下步骤：

设置建立客户端与服务器之间的长连接的条件。

3.如权利要求1所述的长连接管理方法，其特征在于，所述在客户端发送第一次Http请求时，建立客户端与服务器之间的长连接包括以下步骤：

在第一次发送Http请求时，通过轮询的方式检测心跳包的时间，判断所述心跳包的时间是否大于预设阈值；

若所述心跳包的时间是否大于预设阈值，则建立客户端与服务器之间的长连接。

4.如权利要求3所述的长连接管理方法，其特征在于，在所述若所述心跳包的时间是否大于预设阈值，则建立客户端与服务器之间的长连接的步骤之后,还包括以下步骤：

通过轮询的方式检测心跳包的时间，根据所述心跳包的时间判断已建立的长连接的保持时长是否达到预设保持时长；

若是，则断开超过所述预设保持时长的长连接。

5.如权利要求1所述的长连接管理方法，其特征在于，在所述判断客户端是否继续发送Http请求的步骤之前，还包括以下步骤：

在客户端设置自定义重试策略；

根据所述自定义重试策略，判断客户端是否能从Http连接池获得长连接；

若客户端能从Http连接池获得长连接，则将所述长连接返回给客户端使用；

若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作。

6.如权利要求5所述的长连接管理方法，其特征在于，在所述若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作的步骤之后，还包括以下步骤：

判断通过当前重试操作获取到的长连接是否符合长连接返回客户端的第二预设条件；

若符合，则将通过当前重试操作获取到的长连接返回客户端。

7.如权利要求5所述的长连接管理方法，其特征在于，在所述若客户端不能从Http连接池获得长连接，则根据所述自定义重试策略执行获取长连接的重试操作的步骤之前，还包括以下步骤：

设置重试操作的间隔时间。

8.一种长连接管理装置，其特征在于，所述长连接管理装置包括：

建立模块，用于在第一次发送Http请求时，建立客户端与服务器之间的长连接；

第一判断模块，用于判断所述长连接是否符合长连接管理策略；

第一缓存模块，用于在所述长连接符合长连接管理策略时，将所述长连接缓存在对应的Http连接池；

第二判断模块，用于判断缓存在Http连接池中的长连接是否满足第一预设条件；

第一释放模块，用于当缓存在Http连接池中的长连接是不满足第一预设条件时，释放不满足所述第一预设条件的长连接；

第三判断模块，用于判断客户端是否继续发送Http请求；

使用模块，用于在客户端继续发送Http请求时，使用Http连接池中的长连接与服务器进行交互。

9.一种长连接管理设备，其特征在于，所述长连接管理设备包括处理器、存储器以及存储在所述存储器上并可被所述处理器执行的长连接管理程序，所述长连接管理程序被所述处理器执行时实现如权利要求1至7中任一项所述的长连接管理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有长连接管理程序，所述长连接管理程序被处理器执行时实现如权利要求1至7中任一项所述的长连接管理方法的步骤。