交互异常补偿方法、用户端、服务器端和存储介质与流程

1.本技术属于数据处理技术领域，特别是涉及一种交互异常补偿方法、用户端、服务器端和计算机可读存储介质。


背景技术：

2.当服务器发生异常，用户请求服务器信息内容将发生阻碍，导致出现如4xx(用户端请求错误或无法完成请求)、5xx(服务器端发生错误，请求无法完成)等网络服务器异常状态码提示，降低业务传递能力及用户使用体验问题。现有技术通常服务器端会采用cdn技术(content delivery network，内容分发网络)，分布式服务器技术等进行减灾，避险问题。成本及调度能力要求随之提高。如何提出一种低成本容灾方案是本领域技术人员亟待解决的技术问题。
3.前面的叙述在于提供一般的背景信息，并不一定构成现有技术。


技术实现要素：

4.基于此，有必要针对上述问题，提出了一种交互异常补偿方法、用户端、服务器端和计算机可读存储介质，能够有效地在用户端和服务器端出现交互异常时及时将本应发送的交互数据离线缓存或转存。
5.本技术解决其技术问题是采用以下的技术方案来实现的：
6.本技术提供了一种交互异常补偿方法，应用于用户端，包括如下步骤：响应于用户端与服务器端连接异常，获取异常信息，异常信息用于表征连接异常的原因；根据异常信息匹配对应的补偿模式，补偿模式用于表征用户端和服务器端交互出现异常时的补救措施；获取用户端和服务器端交互的交互数据，根据补偿模式处理交互数据，以将交互数据离线缓存或转送。
7.在本技术一可选实施例中，根据异常信息匹配对应的补偿模式，包括：当异常信息表征为用户端异常时，匹配第一补偿模式；和/或，当异常信息表征为服务器端能够访问但无法进行交互时，匹配第二补偿模式；当异常信息表征为服务器端无法访问时，匹配第三补偿模式。
8.在本技术一可选实施例中，用户端与服务器端连接异常之前，方法还包括：获取服务器端的初始数据，并加密缓存至用户端本地及关联用户端本地，初始数据为用户端和服务器端交互所需的基础数据，关联用户端与用户端处于同一局域网络内；当补偿模式为第一补偿模式时，获取用户端和服务器端交互的交互数据，根据补偿模式处理交互数据，包括：从用户端本地和/或关联用户端本地获取初始数据，渲染初始数据生成交互界面，以通过交互界面获取交互数据；将交互数据加密缓存至用户端及本地和/或关联用户端本地。
9.在本技术一可选实施例中，当补偿模式为第二补偿模式时，获取用户端和服务器端交互的交互数据，根据补偿模式处理交互数据，包括：确定用户端所在的局域网内是否存在可用用户端，可用用户端可与服务器端实现交互；若存在可用用户端，则建立与可用用户
端的连接，以将可用用户端作为转发中介，以将交互数据在用户端和服务器端间传递；若不存在可用用户端，则确定内容分发网络内是否存在的可用服务器端，内容分发网络为服务器端所建的网络，可用服务器端和服务器端在同一内容分发网络内，具备相同的服务器功能；当存在可用服务器端时，建立用户端与可用服务器端的连接，以将交互数据在用户端和可用服务器端间传递。
10.在本技术一可选实施例中，当补偿模式为第三补偿模式时，获取用户端和服务器端交互的交互数据，根据补偿模式处理交互数据，包括：根据与内容分发网络的交互确定内容分发网络指定的运行端，内容分发网络为服务器端所建的网络；将交互数据转发至运行端，以使得交互数据在运行端缓存。
11.本技术还提供了一种交互异常补偿方法，应用于服务器端，包括如下步骤：当确定与服务器端关联的用户端间存在连接异常后，获取交互数据，交互数据是在连接异常期间用户端本应发送至服务器端进行离线缓存的数据；核验交互数据；将核验通过的交互数据添加至服务器端的数据库中，并从更新后的数据库中提取出核验数据，核验数据与核验通过的交互数据具有相关关系；将核验不通过的交互数据标记为异常数据；将核验数据和/或异常数据发回用户端。
12.在本技术一可选实施例中，服务器端包括网关，网关独立于服务器端，用于建立内容分发网络；确定与服务器端关联的用户端间存在连接异常之前，方法还包括：当网关确定用户端无法访问服务器端时，网关选定一个或多个用户端或内容分发网络内的一个网关为运行端，并将获取到的交互数据离线缓存至运行端内。
13.本技术还提供了一种用户端，包括处理器和存储器：处理器用于执行存储器中存储的计算机程序以实现如前述应用于用户端的交互异常补偿方法。
14.本技术还提供了一种服务器端，包括处理器和存储器：处理器用于执行存储器中存储的计算机程序以实现如前述应用于服务器端的交互异常补偿方法。
15.本技术还提供了一种计算机可读存储介质，存储有计算机程序，当计算机程序被处理器执行时实现如前述的方法。
16.采用本技术实施例，具有如下有益效果：
17.本技术能够在服务器端和用户端存在连接异常时，根据不同的异常做不同的容灾处理。总体思路都是将每个局域网内的用户端都作为临时的服务器离线缓存数据。使得即使网络暂时中断，于用户侧的用户侧的实际感知是完成了数据交互。离线缓存的教书数据确保网络恢复后，服务器端能正常获取本应该处理的数据。从而提高了数据传递的能力，在现有设备基础上降低了运维的成本，提升了用户使用体验。
18.上述说明仅是本技术技术方案的概述，为了能够更清楚了解本技术的技术手段，而可依照说明书的内容予以实施，并且为了让本技术的上述和其他目的、特征和优点能够更明显易懂，以下特举较佳实施例，并配合附图，详细说明。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。
附图说明
19.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本
申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
20.其中：
21.图1为实施例一提供的一种应用于用户端的交互异常补偿方法流程示意图；
22.图2为实施例二提供的第一补偿模式下的应用环境示意图；
23.图3为实施例二提供的第一补偿模式下的交互异常补偿方法流程示意图；
24.图4为实施例三提供的第二补偿模式下的应用环境示意图；
25.图5为实施例三提供的第二补偿模式下的交互异常补偿方法流程示意图；
26.图6为实施例四提供的第三补偿模式下的应用环境示意图；
27.图7为实施例四提供的第三补偿模式下的交互异常补偿方法流程示意图；
28.图8为实施例五提供的一种应用于服务器端的交互异常补偿方法流程示意图；
29.图9为实施例六提供的计算机设备的内部结构图。
具体实施方式
30.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
31.现有技术通常服务端会采用cdn技术，分布式服务器技术等进行减灾，避险问题。不足之处就是设备成本及运维成本的居高不下。如何利用现有设备即可实现容灾处理，本技术提出了一种交互异常补偿方法。分别应用在用户端和服务器端，各自执行不同的流程实现交互异常时的及时补救。
32.实施例一
33.为了清楚描述本实施例提供的应用于用户端的交互异常补偿方法，请参考图1，包括有步骤s110～s130。
34.步骤s110：响应于用户端与服务器端连接异常，获取异常信息，异常信息用于表征连接异常的原因。
35.在一实施方式中，服务器端和用户端通过有线和/或无线通信技术相连。其中，对于无线通信技术，可以包括但并不限于有：全球移动通信装置(global system for mobile communication,gsm)、增强型移动通信技术(enhanced data gsm environment,edge)，宽带码分多址技术(wideband code division multiple access,w-cdma)、码分多址技术(code division access,cdma)、时分多址技术(time division multiple access,tdma)、蓝牙、无线保真技术(wireless，fidelity，wifi)(如美国电气和电子工程师协会标准ieee 802.11a，ieee 802.11b,ieee802.11g和/或ieee 802.11n)、网络电话(voice over internet protocal，voip)、全球微波互联接入(worldwide interoperability for microwave access，wi-max)、其他用于邮件、即时通讯及短消息的协议，以及任何其他合适的通讯协议，甚至可包括那些当前仍未被开发出来的协议。具体地，对于用户端具体形式例如可以但不限于手机、平板电脑、个人数码助理(英文：personal digital assistant，缩写：pda)、移动互联网设备(英文：mobile internet device，缩写：mid)和可穿戴设备(例如
智能手表)等。移动终端上可以通过的应用程序(例如app)来对相应的信息进处理和展示，以及执行相应的操作，从而提升使用效率。服务器端则作为数据中心处理用户端发来的数据进行处理。
36.然而在运行过程中，可能会存在连接异常的情况，如出现4xx(用户端请求错误或无法完成请求)、5xx(服务器端发生错误，请求无法完成)等网络服务器异常状态码提示。在此可以收集表征连接异常的原因的异常信息，以便后续根据不同异常状况确定不同的处理方式。具体的，异常信息即可以为连接错误的状态码。
37.步骤s120：根据异常信息匹配对应的补偿模式，补偿模式用于表征用户端和服务器端交互出现异常时的补救措施。
38.在一实施方式中，当异常信息表征为用户端异常时，匹配第一补偿模式；和/或，当异常信息表征为服务器端能够访问但无法进行交互时，匹配第二补偿模式；当异常信息表征为服务器端无法访问时，匹配第三补偿模式。
39.在一实施方式中，当异常信息表征为用户端异常时，具体可以为状态码包括：400或401等。其中状态码400表示：bad request，错误请求，也即服务器端无法理解用户端发送的请求，可能是由于请求语法错误、缺少必要的参数或无效的请求内容引起的。或是，状态码401所表示的unauthorized，未授权。具体而言为：请求需要身份验证，但用户端未提供有效的身份验证信息，因此服务器端拒绝响应该请求。对应的则可以匹配第一补偿模式，对于第一补偿模式的具体处理过程将会在后续实施例中详述，此处暂不展开。
40.当异常信息表征为服务器端能够访问但无法进行交互时，具体可以为状态码包括：403、404或408等。具体的，状态403含义为forbidden，也即禁止访问：服务器端已经理解请求，但拒绝执行该请求。通常是因为用户端没有权限访问所请求的资源。404则表示not found，未找到。具体含义为：服务器端无法找到用户端请求的资源。还可以是408request timeout，意为请求超时，用户端在服务器端预设的时间内没有完成请求。对于上述服务器端能够访问却无法完成用户端请求的，则可以对应匹配第二补偿模式以作该类型情况的容灾处理，具体处理过程将会在后续实施例中详述，此处暂不展开。
41.当异常信息表征为服务器端无法访问时，具体对应的状态码可以有：500或503。500internal server error，服务器端内部错误：服务器端在执行请求时遇到了意外的错误，通常表示服务器端出现了故障或配置错误。503service unavailable，服务不可用，表示出现了服务器端暂时无法处理请求的情况，通常是由于过载或维护等原因导致。但是可以理解的是，以上情况都表示为服务器端暂时出现了不可预知的情况，无法对服务器端进行访问。对此，则可以匹配到第三补偿模式以进行处理，具体如何实现补偿的，将会在后续实施例中展开说明。
42.步骤s130：获取用户端和服务器端交互的交互数据，根据补偿模式处理交互数据，以将交互数据离线缓存或转送。
43.在一实施方式中，用户端在确定好补偿模式后，即可将本应该与服务器端交互的数据，按照所匹配的补偿模式进行处理，从而在用户感知处的交互完成。而实际上交互数据则可以通过补偿模式中所可以包含的加密技术、浏览器缓存、渲染引擎技术、采用最佳路径算法计算请求路由、共享加密数据等方式进行处理，实现交互数据的离线缓存或转发，保证后续连接异常被解决后，交互数据能够正常补发至服务器端，保证数据交互的正常完成。本
申请提供的方法可以实现在开放银行领域，例如在商户调用开放银行的支付接口，如果银行业务端的服务器端出现异常，将会导致支付失败，需要等待修复后才可以正常支付。这将是严重的生产问题，也导致用户使用不好体验。本技术提供的方案，将在用户端将本用于支付的的支付信息打包为交互数据，通过点对点的信息交互实现信息的不可篡改，在一定的范围内进行公证传递。在服务器端可用后，服务器端将相关交互数据存互联网接受处理。无须使得用户使用体验的降低，同时保证安全运行全年24小时无间断安全正常运行。
44.因此，本技术能够在服务器端和用户端存在连接异常时，根据不同的异常做不同的容灾处理。总体思路都是将每个局域网内的用户端都作为临时的服务器离线缓存数据。使得即使网络暂时中断，于用户侧的实际感知是完成了数据交互。离线缓存的教书数据确保网络恢复后，服务器端能正常获取本应该处理的数据。从而提高了数据传递的能力，在现有设备基础上降低了运维的成本，提升了用户使用体验。
45.实施例二
46.为清楚描述当根据异常信息匹配为第一补偿模式时，交互异常补偿方法所执行的流程请参考图1～图3，包括有步骤s310～s350。其中，图2为实施例二提供的第一补偿模式下的应用环境示意图；图3为实施例二提供的第一补偿模式下的交互异常补偿方法流程示意图。
47.对于第一补偿模式虽然是在异常确定为用户端220异常时所匹配的补偿模式，但实际上可以是保底的补偿模式，也即是说不论何种异常情况，都可以通过第一补偿模式实现容灾处理。具体而言，对于第一补偿模式下的容灾处理，核心在于js基于本地浏览器的存储以及引擎渲染技术的使用。对于第一补偿模式的应用环境，可以参考图2。如图2所示，用户端220与服务器端210的连接出现故障，该故障具体而言可以是用户端220自身原因引起的，例如用户端220所在的局域网内的所有设备都无法与服务器端210进行交互。在此种情况下，用户端220可以通过自身进行减灾处理，也可以通过关联用户端221实现减灾。其中用户端220和关联用户端221需要都处于统一局域网内，对于关联用户端221除了可以为前文所例举的各种设备外，还可以为局域网的构建设备例如光猫或路由器等。对于第一补偿模式下的交互异常补偿方法，具体可参考后文步骤s310～s350的详述。
48.步骤s310：获取服务器端的初始数据，并加密缓存至用户端本地及关联用户端本地。
49.在一实施方式中，在用户端220和服务器端210还处于正常连接的状态时，用户端220即可以获取服务器端210的初始数据并加密缓存至用户端220及关联用户端221本地。具体而言，也即是对用户端220提供js离线调用服务，对js核心进行本地缓存。js核心本地初始化加密存储器，并缓存包括但不限于有本地标识、html、js、css、接口缓存数据、非敏感性数据等初始厨具。并反馈标识等信息给服务器端210并可以通知其他关联用户端221同样进行本地缓存。
50.步骤s320：响应于用户端与服务器端连接异常，获取异常信息，异常信息用于表征连接异常的原因。
51.步骤s330：当异常信息表征为用户端异常时，匹配第一补偿模式。
52.在一实施方式中，对于如何确定为第一补偿模式的实施过程，已经在前文实施例一中有详细描述，具体可参考前文，此处便不再赘述。
53.步骤s340：从用户端本地和/或关联用户端本地获取初始数据，渲染初始数据生成交互界面，以通过交互界面获取交互数据。
54.步骤s350：将交互数据加密缓存至用户端及本地和/或关联用户端本地。
55.在一实施方式中，如前文所述可知，匹配第一补偿模式则可以为用户端220自身异常所导致的无法完成交互。因此可以可从用户端220和/或用户端220本地获取之前利用浏览器缓存技术所离线缓存的初始数据，并利用渲染引擎技术对初始数据进行渲染以生成交互界面，例如网页等。用户通过与交互界面的交互即可实现用户端220的获取交互数据。在用户侧的感受即使，用户想要传达、交互的信息已经被处理了，也即是说出现异常，用户也不会有明确的感知，不会影响用户的正常操作。对于本应上传至服务器端210的用户数据，因为异常无法上传，在第一补偿模式下，可以将交互数据按照预设的方式加密，点对点地缓存至局域网内的用户端220和所有关联用户端221本地。从而通过公证传递的方式，保证交互数据能够有效在局域网内的所有设备中存储，保证数据的有效性。
56.因此本技术能够在用户端220所在局域网无法与服务器端210交互时，通过异常出现之前缓存的初始数据渲染得到交互界面从而从用户处获取交互数据，使得用户侧感知为请求得到落实。而实际交互数据在局域网内的所有设备中离线公证存储，并在异常被解决，局域网又可以和服务器端210连接后，即可将异常期间所缓存的交互数据上传给服务器端210，保证交互流程的完整执行。从而降低业务传递能力及用户使用体验问题，降低运维成本的问题。
57.实施例三
58.为清楚描述当根据异常信息匹配为第二补偿模式时，交互异常补偿方法所执行的流程请参考图1～图5，包括有步骤s510～s560。其中，图4为实施例三提供的第二补偿模式下的应用环境示意图；图5为实施例三提供的第二补偿模式下的交互异常补偿方法流程示意图。
59.对于第二补偿模式的应用环境，可以参考图4。如图4所示，服务器端210存在于内容分发网络中，内容分发网络为服务器端210所建的网络，可用服务器端211和服务器端210在同一内容分发网络内，具备相同的服务器功能。用户端220存在于一局域网内，该局域网可以存在有多个与用户端220相同的设备。对于匹配第二补偿模式的情况，参考图4具体可以为仅有用户端220无法与服务器端210完成交互的情况，且实际上局域网内的设备包括用户端220都是可以与内容分发网络内的服务器端210进行连接的情况。对于此种情况的容灾处理，本技术提供了一种第二补偿模式下的交互异常补偿方法，包括有步骤s510～s560。
60.步骤s510：响应于用户端与服务器端连接异常，获取异常信息，异常信息用于表征连接异常的原因。
61.步骤s520：当异常信息表征为服务器端能够访问但无法进行交互时，匹配第二补偿模式。
62.在一实施方式中，对于如何确定为第二补偿模式的实施过程，已经在前文实施例一中有详细描述，具体可参考前文，此处便不再赘述。
63.步骤s530：确定用户端所在的局域网内是否存在可用用户端。
64.若存在可用用户端，则执行步骤s540：建立与可用用户端的连接，以将可用用户端作为转发中介，以将交互数据在用户端和服务器端间传递。
65.在一实施方式中，如前文所述用户端220匹配第二补偿模式，仅能明确的是用户端220虽能服务器端210，但无法完成用户端220的请求。这个问题实际可能是用户端220本身所导致的，可能将该请求操作由其他设备与服务器端210交互即可以完成了。因此可以搜索用户端220所在的局域网内是否存在有可用用户端222，可用用户端222和用户端220同处于同一局域网内，且与用户端220具备相同的功能，例如获取交互数据并外发等。不同点在于，可用用户端222能够实现用户端220所未能实现的交互数据的处理。因此，如果局域网内存在可用用户端222，可以使用户端220与可用用户端222间建立通信连接，并由可用用户端222作为信息中介，代为传递用户端220本应上传的交互数据。使得用户端220的交互数据及时不能由用户端220本身上传，也可以由相应的可用用户端222代为上传，保证了数据的正常流通，具体的交互数据的流向，可以参考图4中用户端220到可用用户端222再到服务器端210的箭头标识。
66.若不存在可用用户端，步骤s550：确定内容分发网络内是否存在的可用服务器端。
67.若存在可用服务器端，则执行步骤s560：建立用户端与可用服务器端的连接，以将交互数据在用户端和可用服务器端间传递。
68.在一实施方式中，如果不存在可用用户端222则可能是服务器端210本技术的问题，也可能是局域网内不存在其他用户端220设备，具体原因不做限定。在此情况下也即是说用户端220无法寻找中介实现交互数据的代为上传。基于此用户端220可以确定内容分发网络内是否存在的可用服务器端211。内容分发网络为服务器端210所建的网络，可用服务器端211和服务器端210在同一内容分发网络内，具备相同的服务器功能。可用服务器端211具体可以为其他所在地的服务器，也可以为备用服务器，具体形式不做限制，实际能起到与服务器端210相同的功能即可。因此在内容分发网络中存在有可用服务器时，则可以通过服务器配置的域名转发等功能，选找出与用户端220所相适配的可用服务器端211，相适配具体可以包括有地理位置最近、延迟最低、等级相适配等。由用户端220直接与可用服务器端211建立通信连接，将交互数据上传至可用服务器端211，实现同等效果的上传和交互。具体的交互数据的流向，可以参考图4中用户端220到可用服务器端211的箭头标识。
69.若不存在可用服务器端，则执行步骤s570：匹配第一补偿模式，以根据第一补偿模式处理交互数据，以将交互数据离线缓存。
70.在一实施方式中，如果同时满足局域网内不存在可用用户端222且内容分发网络中不存在可用服务器端211，则说明当前情况下无论如何都无法实现交互数据的转发。对此则可以按照第二实施例所述的补偿流程，实现交互数据的离线缓存。具体实现情况，请参考前文实施例二中的相关描述，在此便不再赘述。
71.因此，本技术能够在用户端220能够访问服务器端210但无法进行交互时，通过局域网内的可用用户端222或内容分发网络中的可用服务器端211，代为转发本应上传的交互数据，使得用户侧感知为请求得到落实，而实际交互数据被代为转发，保证交互流程的完整执行。从而降低业务传递能力及用户使用体验问题，降低运维成本的问题。
72.实施例四
73.为清楚描述当根据异常信息匹配为第三补偿模式时，交互异常补偿方法所执行的流程请参考图1、图6和图7，包括有步骤s710～s740。其中，图6为实施例四提供的第三补偿模式下的应用环境示意图；图7为实施例四提供的第三补偿模式下的交互异常补偿方法流
程示意图。
74.如前文所述，当异常信息表征为服务器端210无法访问时，匹配第三补偿模式。因此对于本实施里的应用环境可以参考图6，如图6所示，服务器端210包括网关230，网关230独立于服务器端210，用于建立内容分发网络。当异常信息表征为服务器端210无法访问，具体而言也即用户端220能够与网关230连接，但网关230无法与服务器端210进行连接。对于第三补偿模式下的交互异常补偿方法，具体可参考后文步骤s710～s740的详述。
75.步骤s710：响应于用户端与服务器端连接异常，获取异常信息，异常信息用于表征连接异常的原因。
76.步骤s720：当异常信息表征为服务器端无法访问时，匹配第三补偿模式。
77.在一实施方式中，对于如何确定为第三补偿模式的实施过程，已经在前文实施例一中有详细描述，具体可参考前文，此处便不再赘述。
78.步骤s730：根据与内容分发网络的交互确定内容分发网络指定的运行端。
79.步骤s740：将交互数据转发至运行端，以使得交互数据在运行端缓存。
80.在一实施方式中，如前文所述，对于匹配到第三补偿模式的模式，属于是服务器侧的问题，用户端220如何处理都无法完成交互。因此用户端220可以根据与内容分发网络的交互确定内容分发网络指定的运行端240。内容分发网络为服务器端210的网关230建立的网络，所有服务器都囊括于该网络中，且服务器出错的问题也是由网关230所确定。对于网关230确定运行端240的具体执行过程将会在后续应用于服务器端210的交互异常补偿方法中详述，此处暂不展开。可以理解的是，运行端240是服务器端210的指定的代为接收交互数据的临时服务器，具体可以为内容分发网络中的某一个网关230，也可以为局域网内的某一个设备，具体不做限制。基于此在图6中运行端1位于内容分发网络外，运行端2位于内容分发网络外，也即是用于描述此种情况。
81.因此，本技术能够在服务器侧异常时，根据用户端220与内容分发网络的交互确定内容分发网络指定的运行端240，运行端240能够代为接收交互数据，起到临时服务器的作用。实现用户侧的实际感知还是完成了数据交互，而实际本应上传的交互数据被服务器端210所在的内容分发网络所指定的运行端240，作为临时服务器代为接收。确保网络恢复后，服务器端210能正常获取本应该处理的数据。从而提高了数据传递的能力，在现有设备基础上降低了运维的成本，提升了用户使用体验。
82.实施例五
83.为清楚描述应用于服务器端210的交互异常补偿方法，请参考图1～图8，包括有步骤s810～s850。其中，图8为实施例五提供的一种应用于服务器端210的交互异常补偿方法流程示意图。
84.步骤s810：当确定与服务器端关联的用户端间存在连接异常后，获取交互数据，交互数据是在连接异常期间用户端本应发送至服务器端进行离线缓存的数据。
85.在一实施方式中，交互数据所缓存的设备可以包括但不限于有用户端220、可用服务器端211、运行端240等设备处，具体如何进行离线缓存的，已经在前文实施例一到实施例四中分别详细描述了，具体请参考前文，在此便不再赘述。
86.步骤s820：核验交互数据。
87.在一实施方式中，服务器可以用对异常期间离线缓存的交互数据进行核验，核验
具体可以包括有完整性核验、有效性核验等。完整性核验也即确定交互数据是否按照预设的格式、形式进行处理和存储的，所必要内容是否齐全，例如对于金融交易而言，交互数据是否包括有付款方、收款方、交易金额等数据。有效性核验，也即是确定交互数据是否真实有效。同样以金融交易而言，可以核验付款方支付金额是否满足其本身的余额，其数字签名是否真实有效，以及还可以确定局域网内公证离线存储的交互数据之间是否彼此都相同等。从而确保异常期间产生的数据没有造假的可能，保证流程的正常进行。
88.步骤s830：将核验通过的交互数据添加至服务器端的数据库中，并从更新后。的数据库中提取出核验数据，核验数据与核验通过的交互数据具有相关关系。
89.步骤s840：将核验不通过的交互数据标记为异常数据。
90.步骤s850：将核验数据和/或异常数据发回用户端。
91.在一实施方式中，如果交互数据核验通过了即可对应将交互数据存储至服务器端210的数据库中，更新现有的数据库得到核验数据。该核验数据是由核验通过了的交互数据根据处理得到的。是真实有效且可信的数据，对于该数据则可以在相应的网络内广播，例如发回用户端220，或者与其他服务器进行同步，实现最后的数据共同存储。如果某一交互数据未能通过，也即是说其中可能参假或者不完整等，需要将其打回用户端220，由用户端220来勘误、纠正，从而避免虚假数据的录入。
92.在一实施方式中，服务器端210包括网关230，网关230独立于服务器端210，用于建立内容分发网络；确定与服务器端210关联的用户端220间存在连接异常之前，方法还包括：当网关230确定用户端220无法访问服务器端210时，网关230选定一个或多个用户端220或内容分发网络内的一个网关230为运行端240，并将获取到的交互数据离线缓存至运行端240内。
93.在一实施方式中，为保证第三补偿模式的实现，服务器端210内还包括有相对独立的网关230，多个网关230之间组成了内容分发网络，用于囊括和连接多个服务器，并且直接与用户端220连接。当网关230确定服务器侧出现异常时，也即用户端220无法访问服务器端210时，网关230可以根据预设的选定规则选定至少一个设备作为运行端240。其中选定规则具体而言可以为：服务器出现问题后，第一个与网关230交互的网关230或运行端240；也可以为内容分发网络内数据处理能力最强的网关230等。运行端240实际用于临时缓存上传的交互数据，起到临时服务器的功能，暂时缓存交互数据，以待服务器的恢复。从而保证了用户端220的交互数据可以实施不间断上传，不受服务器的异常影响。
94.因此，本技术通过应用于服务器端210的交互异常补偿方法，能够在服务器端210和用户端220存在连接异常时，根据不同的异常做不同的容灾处理。总体思路都是将每个局域网内的用户端220都作为临时的服务器离线缓存数据。使得即使网络暂时中断，于用户侧的用户侧的实际感知是完成了数据交互。离线缓存的教书数据确保网络恢复后，服务器端210能正常获取本应该处理的数据。从而提高了数据传递的能力，在现有设备基础上降低了运维的成本，提升了用户使用体验。
95.实施例六
96.图9示出了一个实施例中计算机设备的内部结构图。该计算机设备具体可以是前文所述的用户端220，也可以是服务器端210等设备。如图9所示，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，存储器包括非易失性存储介质和内存储
器。该计算机设备的非易失性存储介质存储有操作系统，还可存储有计算机程序，该计算机程序被处理器执行时，可使得处理器实现交互异常补偿方法。该内存储器中也可储存有计算机程序，该计算机程序被处理器执行时，可使得处理器执行交互异常补偿方法。本领域技术人员可以理解，图9中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
97.在一个实施例中，本技术还提出了一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时，使得处理器执行如前述方法的步骤，
98.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
99.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
100.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。

技术特征：
1.一种交互异常补偿方法，应用于用户端，其特征在于，包括如下步骤：响应于所述用户端与服务器端连接异常，获取异常信息，所述异常信息用于表征连接异常的原因；根据异常信息匹配对应的补偿模式，所述补偿模式用于表征所述用户端和所述服务器端交互出现异常时的补救措施；获取所述用户端和所述服务器端交互的交互数据，根据所述补偿模式处理所述交互数据，以将所述交互数据离线缓存或转送。2.如权利要求1所述的交互异常补偿方法，其特征在于，所述根据异常信息匹配对应的补偿模式，包括：当所述异常信息表征为所述用户端异常时，匹配第一补偿模式；和/或，当所述异常信息表征为所述服务器端能够访问但无法进行交互时，匹配第二补偿模式；当所述异常信息表征为所述服务器端无法访问时，匹配第三补偿模式。3.如权利要求2所述的交互异常补偿方法，其特征在于，所述用户端与服务器端连接异常之前，所述方法还包括：获取所述服务器端的初始数据，并加密缓存至所述用户端本地及关联用户端本地，所述初始数据为所述用户端和所述服务器端交互所需的基础数据，所述关联用户端与所述用户端处于同一局域网络内；当所述补偿模式为第一补偿模式时，所述获取所述用户端和所述服务器端交互的交互数据，根据所述补偿模式处理所述交互数据，包括：从所述用户端本地和/或所述关联用户端本地获取初始数据，渲染所述初始数据生成交互界面，以通过所述交互界面获取所述交互数据；将所述交互数据加密缓存至所述用户端及本地和/或所述关联用户端本地。4.如权利要求2所述的交互异常补偿方法，其特征在于，当所述补偿模式为第二补偿模式时，所述获取所述用户端和所述服务器端交互的交互数据，根据所述补偿模式处理所述交互数据，包括：确定所述用户端所在的局域网内是否存在可用用户端，所述可用用户端可与所述服务器端实现交互；若存在所述可用用户端，则建立与所述可用用户端的连接，以将所述可用用户端作为转发中介，以将所述交互数据在所述用户端和所述服务器端间传递；若不存在所述可用用户端，则确定内容分发网络内是否存在的可用服务器端，所述内容分发网络为所述服务器端所建的网络，所述可用服务器端和所述服务器端在同一内容分发网络内，具备相同的服务器功能；当存在所述可用服务器端时，建立所述用户端与所述可用服务器端的连接，以将所述交互数据在所述用户端和所述可用服务器端间传递。5.如权利要求2所述的交互异常补偿方法，其特征在于，当所述补偿模式为第三补偿模式时，所述获取所述用户端和所述服务器端交互的交互数据，根据所述补偿模式处理所述交互数据，包括：根据与内容分发网络的交互确定所述内容分发网络指定的运行端，所述内容分发网络为所述服务器端所建的网络；
将所述交互数据转发至所述运行端，以使得所述交互数据在所述运行端缓存。6.一种交互异常补偿方法，应用于服务器端，其特征在于，包括如下步骤：当确定与所述服务器端关联的用户端间存在连接异常后，获取交互数据，所述交互数据是在连接异常期间所述用户端本应发送至所述服务器端进行离线缓存的数据；核验所述交互数据；将核验通过的交互数据添加至所述服务器端的数据库中，并从更新后的所述数据库中提取出核验数据，所述核验数据与所述核验通过的交互数据具有相关关系；将核验不通过的所述交互数据标记为异常数据；将所述核验数据和/或所述异常数据发回所述用户端。7.如权利要求6所述的交互异常补偿方法，其特征在于，所述服务器端包括网关，所述网关独立于所述服务器端，用于建立内容分发网络；所述确定与所述服务器端关联的用户端间存在连接异常之前，所述方法还包括：当所述网关确定所述用户端无法访问所述服务器端时，所述网关选定一个或多个所述用户端或所述内容分发网络内的一个网关为运行端，并将获取到的所述交互数据离线缓存至所述运行端内。8.一种用户端，其特征在于，包括处理器和存储器；所述处理器用于执行所述存储器中存储的计算机程序以实现如权利要求1到5中任一项所述方法。9.一种服务器端，其特征在于，包括处理器和存储器；所述处理器用于执行所述存储器中存储的计算机程序以实现如权利要求6或7所述方法。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1到5中任一项所述方法或权利要求6或7所述方法。

技术总结
本申请实施例公开了一种交互异常补偿方法、用户端、服务器端和计算机可读存储介质。其中，应用于用户端的方法包括如下步骤：响应于用户端与服务器端连接异常，获取异常信息，异常信息用于表征连接异常的原因；根据异常信息匹配对应的补偿模式，补偿模式用于表征用户端和服务器端交互出现异常时的补救措施；获取用户端和服务器端交互的交互数据，根据补偿模式处理交互数据，以将交互数据离线缓存或转送。因此，本申请能够在服务器端和用户端存在连接异常时，根据不同的异常做不同的容灾处理。使得即使网络暂时中断，于用户侧的用户侧的实际感知是完成了数据交互，提高了数据传递的能力，在现有设备基础上降低了运维的成本，提升了用户使用体验。了用户使用体验。了用户使用体验。


技术研发人员：黄勇
受保护的技术使用者：平安银行股份有限公司
技术研发日：2023.08.08
技术公布日：2023/10/11