基于gRPC的数据传输方法、装置及存储介质与流程

基于grpc的数据传输方法、装置及存储介质
技术领域
1.本发明数据通信领域，尤其是涉及一种基于grpc的数据传输方法、装置及存储介质。


背景技术：

2.grpc是一款语言中立、平台中立且开源的远程过程调用系统。目前网站监测系统中探针多部署于外网，而外网的网络环境较为复杂，存在一定的不稳定性。外网探针向网站监测云端服务器通过grpc传输数据时，若网络出现抖动等不稳定情况，会造成数据传输出现卡顿、超时甚至丢包等现象，影响了数据传输的质量。


技术实现要素：

3.为了有助于提高数据传输质量，本发明提供一种基于grpc的数据传输方法、装置及存储介质。
4.第一方面，本技术提供的一种基于grpc的数据传输方法采用如下的技术方案：一种基于grpc的数据传输方法，包括：客户端与服务器在grpc环境下基于预设的验证规则判断信息通道是否可用；在所述客户端与所述服务器之间的信息通道不可用时，则将待传输数据进行缓存；在所述客户端与所述服务器之间的信息通道可用时，对所述待传输数据进行传输，并判断所述待传输数据是否传输成功；若所述待传输数据传输失败，则进行传输重试；在所述传输重试的次数大于预设的重试次数阈值时，将所述待传输数据进行缓存。
5.通过采用上述技术方案，在信息通道不可用时，将所有待传输数据缓存，便于等到信息通道可用时再进行传输，使待传输数据不易丢失，有助于提高数据传输质量。在信息通道可用时，实时监测待传输数据是否传输成功，若出现不成功情况，证明网络出现波动，或传输环境出现变化，此时对待传输数据进行传输重试，有助于降低待传输数据的丢失率，进一步提高数据传输质量。
6.可选的，所述客户端与服务器在grpc环境下基于预设的验证规则判断信息通道是否可用的步骤包括：所述客户端向所述服务器发送预设的第一数据包，同时更新客户状态标识为准备，且存储更新的所述客户状态标识；所述服务器接收所述第一数据包，并将接收的所述第一数据包和预设的第二数据包一同返回给所述客户端，同时存储更新的所述客户状态标识；所述客户端接收所述第一数据包和所述第二数据包，判断存储的所述客户状态标识是否为准备；
若是，则将所述客户状态标识再次更新，使所述客户状态标识为连接，并将接收的所述第一数据包、所述第二数据包和预设的第三数据包返回给所述服务器；所述服务器接收所述第一数据包、所述第二数据包和所述第三数据包，判断存储的所述客户状态标识是否为准备；若是，则将存储的所述客户状态标识改为稳定，并将接收的所述第一数据包、所述第二数据包和所述第三数据包返回给所述客户端；所述客户端接收所述第一数据包、所述第二数据包和所述第三数据包，判断存储的所述客户状态标识是否为连接；若是，则将所述客户状态标识三次更新，使所述客户状态标识为稳定，同时判定所述信息通道可用。
7.通过采用上述技术方案，客户端和服务器之间相互传输预设的第一数据包、第二数据包和第三数据包，一方面，预设的数据包具有一定的大小，与待传输数据相似，通过相互传输数据包的方式验证信息通道是否可用，准确度更高；另一方面，每一次传输均增加一个新的数据包，并在接收到数据包后更新客户状态标识，基于接收的数据包的大小或者数量，以及基于客户状态标识，便于判断信息通道是否真实可用，且便于判断传输过程中数据包和客户状态标识是否会出现异常，只有两方面均未出现异常，方视为信息通道可用，有助于保证数据传输质量。
8.可选的，在所述对所述待传输数据进行传输之后，还包括：所述客户端将所述第一数据包、所述第二数据包和所述第三数据包传输给所述服务器，并判断传输是否超过预设的维持时间阈值或判断是否接收到所述服务器传输的拒绝接收信息；若传输超过预设的维持时间阈值或接收到所述服务器传输的拒绝接收信息，则判定信息通道异常，并重新判断信息通道是否可用；若重新判断的次数超过重建次数阈值，则视为所述信息通道不可用。
9.通过采用上述技术方案，信息通道被判定为可用后，实时验证信息通道是否可用，一则，在待传输数据出现无法传输或者传输异常时，容易得知是信息通道的问题还是待传输数据传输的问题，从而保证待传输数据不易丢失，提高修复效率；再则，易于及时发现信息通道不可用，从而停止待传输数据的传输动作，对待传输数据进行缓存，有助于降低待传输数据的丢失率，提高数据传输质量。
10.可选的，所述判断所述待传输数据是否传输成功的步骤包括：所述客户端判断由所述服务器反馈的传输成功信息是否超过预设的反馈时间阈值；若超过，则视为传输失败；否则，视为传输成功。
11.通过采用上述技术方案，客户端将待传输数据传输给服务器后，服务器会反馈给客户端相应的传输成功信息，客户端基于接收到的传输成功信息的时间判断待传输数据是否传输成功，便于及时作出判断，防止在异常情况下向服务器传输大量待传输数据。此外，能够及时判断出待传输数据是否传输成功，有助于减少待传输数据的卡顿和超时现象。
12.可选的，所述若所述待传输数据传输失败，则进行传输重试的步骤包括：
对当前的所述待传输数据进行重新传输，并停止传输后续的所述待传输数据；重试次数增加1。
13.通过采用上述技术方案，在重新传输待传输数据时，不对后续的待传输数据进行传输，有助于减少待传输数据的丢失率，从而有助于提高数据传输质量。
14.可选的，所述将待传输数据进行缓存的步骤包括：将所述待传输数据存储至预设的消息队列；在接收到处理信息后，从所述消息队列中取出对应的所述待传输数据，并将对应的所述待传输数据传输。
15.通过采用上述技术方案，将待传输数据存储至消息队列，便于对待传输数据进行有序存储，且不易丢失。在接收到处理信息后，从消息队列中取出待传输数据，便于使待传输数据有序输出，不易丢失。
16.可选的，所述消息队列包括第一队列和第二队列；所述将所述待传输数据存储至预设的消息队列的步骤包括：将所述待传输数据存储至所述第一队列；所述在接收到处理信息后，从所述消息队列中取出对应的所述待传输数据，并将对应的所述待传输数据传输的步骤包括：基于先进先出规则传输存储在所述第一队列中的所述待传输数据；判断所述待传输数据是否传输成功；若成功，遍历所述第一队列中的所述待传输数据；若不成功，将传输失败的所述待传输数据存储至所述第二队列，并遍历所述第一队列中的所述待传输数据；将所述第二队列中的所述待传输数据移入所述第一队列。
17.通过采用上述技术方案，第一队列中的待传输数据传输成功后，将第一队列中的所有待传输数据均传输一遍，传输失败的则存储到第二队列中。待第一队列中的待传输数据均进行过传输后，将第二队列中的待传输数据移入第一队列，等待下一次的处理信息，有助于提高待传输数据的传输效率，两个队列交互使用，使待传输数据不易丢失，便于保证传输质量。
18.第二方面，本技术提供一种基于grpc的数据传输装置采用如下的技术方案：一种基于grpc的数据传输装置，包括存储器和处理器，所述存储器中存储有基于grpc的数据传输程序；所述处理器用于在执行基于grpc的数据传输程序时采用上述方法。
19.通过采用上述技术方案，存储器中存储有基于grpc的数据传输程序，且处理器能够采用上述方法执行该程序，有助于提高数据传输质量。
20.第三方面，本技术提供一种存储介质采用如下的技术方案：一种存储介质，存储有能够被处理器加载并执行上述方法的计算机程序。
21.通过采用上述技术方案，存储有数据传输程序，有助于提高数据传输质量。
22.综上所述，优先对信息通道进行判断，在信息通道可用时，对待传输数据进行传输，不可用时，将待传输数据缓存，使待传输数据不易丢失，有助于提高数据传输质量。
23.此外，在待传输数据传输过程时，判断待传输数据是否传输成功，有助于保证待传输数据从输出端至接收端的精确流转，不易在中途被盗取或篡改，有助于提高数据传输质
量。
24.在待传输数据传输不成功时，进行传输重试，以保证待传输数据的传输效率，若传输重试次数大于预设的重试次数阈值，则对待传输数据进行缓存，有助于保证待传输数据始终处于稳定的传输环境，否则不进行传输，有助于提高数据的传输质量。
附图说明
25.图1是本技术实施例的一种基于grpc的数据传输方法的流程图。
26.图2是本技术实施例的一种判断信息通道是否可用的流程图。
27.图3是本技术实施例的另一种判断信息通道是否可用的流程图。
28.图4是本技术实施例的一种基于grpc的数据传输方法中步骤200的具体流程图。
具体实施方式
29.本技术实施例公开一种基于grpc的数据传输方法。参照图1，包括：s100、客户端与服务器在grpc环境下基于预设的验证规则判断信息通道是否可用。
30.其中，在grpc环境下指客户端与服务器利用grpc技术进行数据传输，即客户端与服务器在grpc这种远程过程调用系统中进行通信。
31.具体的，在一实施例中，参照图2，步骤s100包括：s111、客户端向服务器发送预设的第一数据包，同时更新客户状态标识为准备，且存储更新的客户状态标识。
32.为了便于理解，在客户端未发送第一数据包时，客户状态标识可以是空值，在客户端发送第一数据包时或者在客户端发送了第一数据包后，客户状态标识变为准备。而步骤s111中所称存储更新的客户状态标识即存储准备，因为此时客户状态标识就是准备。
33.s112、服务器接收第一数据包，并将接收的第一数据包和预设的第二数据包一同返回给客户端，同时存储更新的客户状态标识。
34.在应用时，客户端和服务器均可预存有第一数据包和第二数据包，根据情况进行调用即可。当然，如果待传输数据仅能由客户端发送至服务器端，也可在客户端只预存第一数据包，在服务器端只预存第二数据包，节省网络资源。
35.服务器将接收的第一数据包和预设的第二数据包一同返回给客户端即服务器将第一数据包和第二数据包融合后或者绑定后传输给客户端。为了便于理解，例如第一数据包为a，第二数据包为b，则服务器在接收到a后，将a b传输给客户端。对于服务器存储的客户状态标识可以是客户端在向服务器传输第一数据包时，一同将更新后的客户状态标识传输给服务器；也可以是客户端将更新后的客户状态标识存储到第一数据包中，服务器读取第一数据包中的信息后获得；还可以是服务器在接收第一数据包时，基于预设的对应关系，自动判定客户状态标识为准备，而后对客户状态标识进行存储。
36.s113、客户端接收第一数据包和第二数据包，判断存储的客户状态标识是否为准备。
37.若否，则判定信息通道不可用；若是，则将客户状态标识再次更新，使客户状态标识为连接，并将接收的第一数据
包、第二数据包和预设的第三数据包返回给服务器。
38.第三数据包的存储情况与第一数据包和第二数据包的相同，可以仅存储在服务器中，也可以客户端和服务器均预存有第三数据包。
39.s114、服务器接收第一数据包、第二数据包和第三数据包，判断存储的客户状态标识是否为准备。
40.若否，则判定信息通道不可用；若是，则将存储的客户状态表示改为稳定，并将接收的第一数据包、第二数据包和第三数据包返回给客户端。
41.s115、客户端接收第一数据包、第二数据包和第三数据包，判断存储的客户状态标识是否为连接。
42.若否，则判定信息通道不可用；若是，则将客户状态标识进行第三次更新，使客户状态标识为稳定，同时判定信息通道可用。
43.对于步骤s112-s115，需要说明的是，除了对客户状态标识进行校对外，若客户端或者服务器在对应步骤接收的数据包错误或者数据包数量错误，则输出异常报警信息或直接判定信息通道不可用。例如，在步骤s112的执行过程中，服务器判断接收的第一数据包是否与本地预存的第一数据包相同，相同指内容和数据结构均相同；若相同，判断接收的是否只有第一数据包，若是，则执行后续步骤，否则输出异常报警信息或判定信息通道不可用。再例如，在不受s113的执行过程中，客户端判断接收的第一数据包和第二数据包是否与本地预存的第一数据包和第二数据包相同；若相同，判断接收的是否只有第一数据包和第二数据包，若只接收到了第一数据包，则输出异常报警信息或判定信息通道不可用，若接收到了第一数据包、第二数据包和第三数据包，则输出异常报警信息或判定信息通道不可用，若接收到了两份第一数据包，则输出异常报警信息或判定信息通道不可用。
44.在另一实施例中，参照图3，待传输数据可以由服务器向客户端发起传输，此时步骤s100包括：s121、服务器向客户端发送预设的第一数据包，同时更新服务状态表示为准备，且存储更新的客户状态标识。
45.s122、客户端接收第一数据包，并将接收的第一数据包和预设的第二数据包一同返回给服务器，同时存储更新的服务状态标识。
46.s123、服务器接收第一数据包和第二数据包，判断存储的服务状态标识是否为准备。
47.若否，则判定信息通道不可用；若是，则将用户状态标识再次更新，使用户状态标识为连接，并将接收的第一数据包、第二数据包和预设的第三数据包返回给服务器。
48.s124、客户端接收第一数据包、第二数据包和第三数据包，判断存储的服务状态标识是否为准备。
49.若否，则判定信息通道不可用；若是，则将存储的服务状态表示改为稳定，并将接收的第一数据包、第二数据包和第三数据包返回给服务器。
50.s125、服务器接收第一数据包、第二数据包和第三数据包，判断存储的服务状态标识是否为连接。
51.若否，则判定信息通道不可用；若是，则将服务状态标识进行第三次更新，使服务状态标识为稳定，同时判定信息通道可用。
52.对于步骤s121-s125，与步骤s111-s115的原理相同，不再赘述。
53.参照图1，在客户端与服务器之间的信息通道不可用时，执行步骤s200、将待传输数据进行缓存。
54.在客户端与服务器之间的信息通道可用时，执行步骤s300、对待传输数据进行传输，并判断待传输数据是否传输成功。
55.其中，在一实施例中，待传输数据是由客户端发起，向服务器传输的情况，在对待传输数据进行传输之后，还包括：客户端将第一数据包、第二数据包和第三数据包传输给服务器，并判断传输是否超过预设的维持时间阈值，或判断是否接收到服务器传输的拒绝接收信息。
56.其中，判断传输是否超过维持时间阈值即客户端在将第一数据包、第二数据包和第三数据包传输给服务器时，开始计时；在接收到服务器返回的成功反馈信息时，停止计时。判断计时时间是否超过维持时间阈值。
57.若客户端判断传输超过预设的维持时间阈值或接收到服务器传输的拒绝接收信息，则判定信息通道异常，并重新判断信息通道是否可用。
58.若开始计时后，计时时间超过了维持时间阈值，但未接收到服务器传输的任何信息，则直接判定信息通道异常。重新判断信息通道是否可用即执行步骤s111-s115。
59.若重新判断信息通道是否可用的次数超过重建次数阈值，则视为信息通道不可用，停止待传输数据的传输，并执行步骤s200。
60.为了便于理解，例如，客户端判定信息通道异常后，与服务器重新进行了步骤s111-s115，但是结果为信息通道不可用。为了保证待传输数据的传输时效性，客户端和服务器会再执行步骤s111-s115，重复确认信息通道是否可用。每次重复确认均对判断信息通道是否可用的次数加1，当次数超过重建次数阈值时，则不再对信息通道的可用性进行判断；例如重建次数阈值为3。
61.在另一实施例中，待传输数据是由服务器发起，向客户端传输的情况，在对待传输数据进行传输之后，还包括：服务器将第一数据包、第二数据包和第三数据包传输给客户端，并判断传输是否超过预设的维持时间阈值，或判断是否接收到客户端传输的拒绝接收信息。
62.若服务器判断传输超过预设的维持时间阈值或接收到服务器传输的拒绝接收信息，则判定信息通道异常，并重新判断信息通道是否可用。
63.重新判断信息通道是否可用即执行步骤s121-s125.若重新判断信息通道是否可用的次数超过重建次数阈值，则视为信息通道不可用，停止待传输数据的传输，并执行步骤s200。
64.需要说明的是，无论待传输数据是由客户端向服务器传输，还是服务器向客户端传输，只要待传输数据处于传输状态，且未判断出待传输数据传输失败，则持续对信息通道
是否异常进行判定。
65.判断待传输数据是否传输成功的步骤包括：客户端判断由服务器反馈的传输成功信息是否超过预设的反馈时间阈值。若超过，则视为传输失败；若未超过，视为传输成功。
66.不难理解，客户端每向服务器传输一条待传输数据，服务器均会向客户端返回一条对应的传输成功信息。而客户端在将一条待传输数据发送给服务器时，开始针对该条待传输数据进行计时，在接收到服务器针对该条待传输数据返回的传输成功信息后，停止计时；对比计时时间与反馈时间阈值两者的大小，判定该条待传输数据是否传输成功。为了有助于减少待传输数据的丢失率，反馈时间阈值小于客户端向服务器发送两条或者三条待传输数据所花费的总时间。例如，客户端每10ms向服务器传输一条待传输数据，则反馈时间阈值可以设置为15ms、20ms或者25ms。
67.对于待传输数据由服务器向客户端传输的情况，如果判断待传输数据是否传输成功的原理和具体实现方式与上述情况相同，不再赘述。
68.参照图1，若待传输数据传输成功，则持续对待传输数据进行传输；若待传输数据传输失败，则执行步骤s400、进行传输重试。
69.具体的，步骤s400具体包括：对当前的待传输数据进行重新传输，并停止传输后续的待传输数据，记录重试次数，并在每次重新传输前，将重试次数增加1。
70.其中，当前的待传输数据指传输失败的待传输数据，后续的待传输数据指还未进行传输的待传输数据。一旦进行重新传输，则将重试次数增加1。
71.s500、判断传输重试的次数是否大于预设的重试次数阈值。
72.在传输重试的次数大于预设的重试次数阈值时，执行步骤s200、将带传输数据进行缓存。
73.具体的，参照图4，步骤s200包括：s210、将待传输数据存储至预设的消息队列。
74.其中，消息队列包括第一队列和第二队列，第一队列和第二队列可以是rabbitmq、rocketmq、kafka或redis。
75.s220、在接收到处理信息后，从消息队列中取出对应的待传输数据，并将对应的待传输数据传输。
76.具体的，处理信息可以是由客户端或者服务器在判定信息通道可用后，或者待传输数据能够传输成功后产生的或者接收到的。从消息队列中取出对应的待传输数据的执行主体由待传输数据的输出方决定；即如果待传输数据是由客户端向服务器传输，则由客户端执行取出动作，反之则由服务器执行取出动作。
77.将待传输数据存储至预设的消息队列的具体步骤包括：将待传输数据存储至第一队列。
78.在接收到处理信息后，从消息队列中取出对应的待传输数据，并将对应的待传输数据传输的具体步骤包括：基于先进先出规则传输存储在第一队列中的待传输数据。
79.判断待传输数据是否传输成功。
80.判断的方式与前文相同，不再赘述。
81.若成功，遍历第一队列中的待传输数据。
82.需要说明的是，由于从第一队列读取待传输数据时，是基于先进先出规则。因此待传输数据是逐条被传输。此时，无论是否有待传输数据传输失败，均按照先进先出的顺序，将第一队列中的待传输数据传输一遍。
83.若不成功，将传输失败的待传输数据存储至第二队列，并遍历第一队列中的待传输数据。
84.例如，第一队列中的第一条待传输数据传输失败，则将第一条待传输数据从第一队列导入至第二队列，并对第二条待传输数据进行传输，依次类推，直至第一队列中的所有待传输数据均进行过传输为止。
85.将第二队列中的待传输数据移入第一队列。
86.为了进一步对本方案进行理解，下面结合具体的实施场景进行数据传输方法的实施例的描述。
87.网站监测平台基于部署在外网的探针对目标网站进行监测。具体监测过程为：探针从网站监测平台获取监测任务，包括需要监测的网站，即目标网站；监测的周期，即开始监测的时间和监测的频率；监测的策略，即监测目标网站哪些内容以及监测目标网站的层级数和页面数。探针得到监测任务后，对目标网站中的信息进行抓取，并将抓取到的数据返回给网站监测平台；网站监测平台基于探针返回的数据对目标网站进行监测。
88.而在本实施例中，网站监测平台相当于服务器，探针相当于客户端，不难理解，网站监测平台通常需要同时对多个目标网站进行监测，因此与网站监测平台通信的探针数量为多个。
89.在对目标网站进行监测时，网站监测平台在本地创建监测任务，等待探针领取。
90.探针先基于预设的验证规则判断信息通道是否可用。即探针端与网站监测平台端均预存有第一数据包、第二数据包和第三数据包，而后探针按照验证规则与网站监测平台传输预存的数据包，从而判断与网站监测平台之间的信息通道是否可用。此过程也可以理解为探针与网站监测平台建立了信息通道。
91.在信息通道为可用时，探针将自身信息封装后，传输给网站监测平台，并启动超时等待。探针的自身信息包括探针id、探针类型、拉取任务类型和匹配标签等。
92.网站监测平台接收到探针上传的自身信息后，将对应的监测任务数据返回给探针。
93.若探针在超时之前接收到网站监测平台返回的监测任务数据，则开始执行监测任务。
94.在上述数据传输过程中，若信息通道不可用，探针则将需要传输给网站监测平台的自身信息进行缓存；若探针在超时之前未接收到网站监测平台返回的监测任务数据，则视为数据传输失败，而后进行传输重试。若传输重试的次数大于预设的重试次数阈值，则将自身信息进行缓存。
95.不难理解，除了探针的自身信息，其他数据在传输时，也可进行信息通道是否可用的判定、数据传输是否成功的判定以及传输重试次数的判定，有助于在探针与网站监测平台之间确立稳定的信息通道，排出网络震荡导致的数据传输失败故障，降低数据丢失率。
96.本实施例还公开一种基于grpc的数据传输装置，包括存储器和处理器，存储器中存储有基于grpc的数据传输程序，处理器用于在执行基于grpc的数据传输程序时，采用上述数据传输方法。
97.本实施例又公开一种存储介质，存储有能够被处理器加载并执行上述数据传输方法的计算机程序。
98.以上均为本技术的较佳实施例，并非依此限制本技术的保护范围，故：凡依本技术的结构、形状、原理所做的等效变化，均应涵盖于本技术的保护范围之内。