CN110572451A - 一种数据处理的方法、装置及存储介质 - Google Patents

一种数据处理的方法、装置及存储介质 Download PDF

Info

Publication number
CN110572451A
CN110572451A CN201910835730.6A CN201910835730A CN110572451A CN 110572451 A CN110572451 A CN 110572451A CN 201910835730 A CN201910835730 A CN 201910835730A CN 110572451 A CN110572451 A CN 110572451A
Authority
CN
China
Prior art keywords
service
server
user terminal
data
mode
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910835730.6A
Other languages
English (en)
Other versions
CN110572451B (zh
Inventor
冯锋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201910835730.6A priority Critical patent/CN110572451B/zh
Publication of CN110572451A publication Critical patent/CN110572451A/zh
Application granted granted Critical
Publication of CN110572451B publication Critical patent/CN110572451B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Abstract

本申请实施例公开了一种数据处理的方法、装置及存储介质，所述方法包括：获取第一服务器发送的第一路由变更通知，基于所述第一路由变更通知将路由模式由第一模式调整为第二模式；获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，所述第一业务服务器为业务服务器集群中的业务服务器；基于所述业务绑定关系从所述第一业务服务器上获取第一业务数据，将所述第一业务数据返回给所述用户终端。采用本申请，可以在分布式环境下确保访问任一服务器得到的内容是强一致性的。

Description

一种数据处理的方法、装置及存储介质
技术领域
本申请涉及计算机领域，尤其涉及一种数据处理的方法、装置及存储介质。
背景技术
随着终端的普及，大多数人已经不局限于观看纸质读物，越来越多的人选择在网上观看电子读物。在分布式环境下，多台业务服务器中的每台业务服务器均可以在更新周期到来时，从更新管理服务器上获取所需同步的某个电子读物的业务数据。
但是由于不同业务服务器之间可能存在不同的更新周期，以至于这些业务服务器从更新管理服务器上同步得到业务数据所需的时间可能存在不同，从而导致用户终端在不同时间请求访问同一电子读物(例如，电子读物A)时，所请求到的业务数据可能来自于不同业务服务器(例如，已完成数据更新的业务服务器A和待完成数据更新的业务服务器B)，进而导致同一用户终端每次所接收到的该电子读物A的业务数据内容是不相同的。比如，若在T1时刻请求访问的是业务服务器A，则用户终端所呈现的是已更新的业务数据，反之，若在T2时刻请求访问的是业务服务器B，则用户终端所呈现的是未更新的业务数据，即现有的数据访问方式无法确保数据内容的一致性。
发明内容
本申请实施例提供一种数据处理的方法、装置及存储介质，可以在分布式环境下确保访问任一服务器得到的内容是强一致性的。
本申请一方面提供了一种数据处理的方法，所述方法应用于第二服务器，包括：
获取第一服务器发送的第一路由变更通知，基于所述第一路由变更通知将路由模式由第一模式调整为第二模式；
获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，所述第一业务服务器为业务服务器集群中的业务服务器；
基于所述业务绑定关系从所述第一业务服务器上获取第一业务数据，将所述第一业务数据返回给所述用户终端。
其中，所述第一模式为随机路由模式，所述第二模式为固定路由模式；
所述获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，包括：
获取所述用户终端发送的所述第一业务请求，提取所述第一业务请求中所携带的用户标识信息；
基于所述固定路由模式确定所述用户标识信息对应的哈希值，对所述哈希值进行求余处理，得到所述哈希值对应的余数，基于所述余数从业务服务器集群中确定所述用户终端对应的第一业务服务器；
构建所述用户终端与所述第一业务服务器的业务绑定关系，所述业务绑定关系用于指示所述用户终端访问所述第一业务服务器。
其中，所述业务服务器集群包含第二业务服务器；
所述方法还包括：
基于所述业务绑定关系生成所述第一路由变更通知对应的第一变更结果，向所述第一服务器返回所述第一变更结果，以使所述第一服务器基于数据更新信息对所述第一业务服务器和第二业务服务器进行数据更新。
其中，所述方法还包括：
当所述业务服务器集群中的所有业务服务器均完成数据更新时，获取所述第一服务器发送的第二路由变更通知，基于所述第二路由变更通知将路由模式由所述第二模式调整为所述第一模式；
根据所述第一模式解除所述业务绑定关系；
获取所述用户终端发送的第二业务请求，基于所述第二业务请求以及所述第一模式，获取第二业务数据，将所述第二业务数据返回给所述用户终端；所述第二业务数据为对所述第一业务请求数据进行数据更新后所确定的。
其中，所述获取所述用户终端发送的第二业务请求，基于所述第二业务请求以及所述第一模式，获取第二业务数据，将所述第二业务数据返回给所述用户终端，包括：
获取所述用户终端发送的所述第二业务请求；
获取与所述第一模式相关联的路由规则表，基于所述第二业务请求从所述路由规则表所包含的路由地址中选取目标服务标识信息；
基于所述目标服务标识信息在所述服务器集群中确定目标业务服务器，从所述目标业务服务器上获取第二业务数据；
将所述第二业务数据返回给所述用户终端。
其中，所述基于所述目标服务标识信息从所述服务器集群中确定目标业务服务器，从所述目标业务服务器上获取第二业务数据，包括：
若与所述目标服务标识信息相关联的业务服务器为所述第二业务服务器，则从所述第二业务服务器中获取第二业务数据；
若与所述目标服务标识信息相关联的业务服务器为所述第一业务服务器，则从所述第一业务服务器中获取第二业务数据。
其中，所述业务服务器集群中的每个业务服务器均为区块链中的节点服务器，且所述每个业务服务器在完成数据更新时，均用于将携带所述更新数据信息的区块写入所述区块链。
本申请一方面提供了一种数据处理的装置，所述装置应用于第二服务器，包括：
第一获取模块：用于获取第一服务器发送的第一路由变更通知，基于所述第一路由变更通知将路由模式由第一模式调整为第二模式；
第二获取模块：用于获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，所述第一业务服务器为业务服务器集群中的业务服务器；
第三获取模块：用于基于所述业务绑定关系从所述第一业务服务器上获取第一业务数据，将所述第一业务数据返回给所述用户终端。
其中，所述第一模式为随机路由模式，所述第二模式为固定路由模式；
所述第二获取模块包括：
提取单元：用于获取所述用户终端发送的所述第一业务请求，提取所述第一业务请求中所携带的用户标识信息；
确定单元：用于基于固定路由模式确定所述用户标识信息对应的哈希值，对所述哈希值进行求余处理，得到所述哈希值对应的余数，基于所述余数从业务服务器集群中确定所述用户终端所对应的第一业务服务器；
构建单元：用于构建所述用户终端与所述第一业务服务器的业务绑定关系，所述业务绑定关系用于指示所述用户终端访问所述第一业务服务器。
其中，所述业务服务器集群包含第二业务服务器，所述装置还包括：
数据更新模块：用于基于所述业务绑定关系生成所述第一路由变更通知对应的第一变更结果，向所述第一服务器返回所述第一变更结果，以使所述第一服务器基于数据更新信息对所述第一业务服务器和第二业务服务器进行数据更新。
其中，所述装置还包括：
路由变更模块：用于当所述业务服务器集群中的所有业务服务器均完成数据更新时，获取所述第一服务器发送的第二路由变更通知，基于所述第二路由变更通知将路由模式由所述第二模式调整为所述第一模式；
解除模块：用于根据所述第一模式解除所述业务绑定关系；
第四获取模块：用于获取所述用户终端发送的第二业务请求，基于所述第二业务请求以及所述第一模式，获取第二业务数据，将所述第二业务数据返回给所述用户终端；所述第二业务数据为对所述第一业务请求数据进行数据更新后所确定的。
其中，所述业务服务器集群中的每个业务服务器均为区块链中的节点服务器，且所述每个业务服务器在完成数据更新时，均用于将携带所述更新数据信息的区块写入所述区块链。
其中，所述第四获取模块，包括：
获取业务请求单元：用于获取所述用户终端发送的所述第二业务请求；
选取标识单元：用于获取与所述第一模式相关联的路由规则表，基于所述第二业务请求从所述路由规则表所包含的路由地址中选取目标服务标识信息；
获取业务数据单元：用于基于所述目标服务标识信息在所述服务器集群中确定目标业务服务器，从所述目标业务服务器上获取第二业务数据；
返回业务数据单元：用于将所述第二业务数据返回给所述用户终端。
本申请一方面提供了一种计算机处理设备，包括：处理器、存储器、网络接口；
所述处理器与存储器、网络接口相连，其中，网络接口用于提供数据通信功能，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以执行本申请实施例中上述一方面中的方法。
本申请一方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时，执行本申请实施例中上述一方面中的方法。
本申请实施例中的第二服务器可以在获取到第一服务器发送的第一路由变更通知时，将业务请求相关联的路由模式由第一模式调整为第二模式，然后在获取到用户终端发送的业务请求(例如，第一业务请求)时，确定所述用户终端与第一业务服务器之间的业务绑定关系，并将从所述第一业务服务器获取到的第一业务数据返回给用户终端。可见，本申请可以在分布式环境下，第二服务器(比如，接入服务器)可以在接收到用户终端发送的业务请求时，进一步基于调整后的路由模式(即第二模式)，构建用户终端与唯一业务服务器之间的绑定关系，以使用户终端在不同时间访问业务服务器，可以得到的内容是强一致性的。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种网络架构的结构示意图。
图2a是本申请实施例提供的一种用于进行数据访问的场景示意图。
图2b是本申请实施例提供的一种区块链网络的场景示意图。
图3是本申请实施例提供的一种数据处理方法的流程示意图。
图4是本申请实施例提供的另一种数据处理方法的流程示意图。
图5是本申请实施例提供的一种路由变更规则图。
图6是本申请实施例提供的一种数据处理方法的交互流程示意图。
图7是本申请实施例提供的一种记录时间戳的场景示意图。
图8是本申请实施例提供的一种数据处理装置结构示意图。
图9是本申请实施例提供的一种计算机处理设备的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参见图1，是本申请实施例提供的一种网络架构的结构示意图。如图1所示，所述网络架构可以应用于业务访问系统的应用场景中。如图1所示，该网络架构可以包括目标用户终端，接入服务器2000，业务服务器集群以及更新管理服务器5000。其中，所述目标用户终端可以为集成安装有目标应用的任意一个注册用户终端。如图1所示，所述业务服务器集群可包括多个业务服务器，具体可以包括：业务服务器4000a、业务服务器4000b、…、业务服务器4000n；
如图1所示，所述接入服务器2000可以与目标用户终端进行网络相连，即该接入服务器2000可以用于接收目标用户终端发送的业务请求；应当理解，该接入服务器2000还可以与业务服务器集群中的每个业务服务器进行网络连接，用于基于业务请求从相应业务服务器上获取相应的业务数据，并可以进一步将根据该业务请求所请求到的业务数据返回给所述目标用户终端。
其中，所述目标用户终端可以包括：智能手机、平板电脑、桌上型电脑、智能电视等具有业务数据访问功能的智能终端。
此外，如图1所示，接入服务器2000还可以与更新管理服务器5000进行网络连接，以接收更新管理服务器5000发送的路由变更通知。所述路由变更通知包含第一路由变更通知和第二路由变更通知。
其中，为便于理解，本申请实施例中的接入服务器2000可以称之为第二服务器，本申请实施例中的更新管理服务器5000可以为第一服务器。
其中，可以理解的是，该接入服务器2000可以在更新管理服务器5000确定数据库中缓存有针对目标应用中的业务数据的更新数据时，接收该更新管理服务器5000发送的第一路由变更通知，以将该接入服务器2000的路由模式由第一模式(即随机路由模式)调整为第二模式(即固定路由模式)。应当理解，在本申请实施例中可以将更新管理服务器5000在确定数据库中缓存有针对目标应用中的业务数据的更新数据，并向接入服务器2000发送的第一路由变更通知的时刻称之为第一时刻(例如，T1时刻)，该第一时刻也可以称之为通知发起时刻。
其中，应当理解，接入服务器2000还可以在图1所示的业务服务器集群中的每一个业务服务器均完成针对该目标应用中的业务数据的更新数据的同步缓存时，接收更新管理服务器5000发送的第二路由变更通知，以将该接入服务器2000的路由模式由第二模式(即固定路由模式)调整为第一模式(随机路由模式)。应当理解，在本申请实施例中可以将更新管理服务器5000接收到图1所示的业务服务器集群中的所有业务服务器返回确认更新结果时的时刻称之为第二时刻(例如，T2时刻)，该第二时刻也可以称之为更新完成时刻。
鉴于此，本申请实施例可以将第一时刻和第二时刻之间所确定的时长称之为业务更新时长。在该业务更新时长内，该更新管理服务器5000可以用于将数据库中的更新数据同步缓存至所述业务服务器集群中的每一个业务服务器，直至所有业务服务器均完成对该更新数据的同步缓存。
由此可见，在业务访问系统的应用场景下，所述更新管理服务器5000可以用于在确定数据库中缓存有针对目标应用中的业务数据的更新数据时，通知图1所示的接入服务器2000变更与业务请求相关联的路由模式。比如，本申请实施例可以在业务更新时长内将业务请求相关联的路由模式由随机路由模式调整为固定路由模式，从而可以确保同一个用户在该业务更新时长内均可以访问到同一业务服务器(例如，图1所示的业务服务器4000a)。所以，在该业务更新时长内，对于持有该目标用户终端的同一用户而言，每次都能够访问到携带相同数据内容的业务服务器4000a。
为便于理解，进一步的，请参见图2a，是本申请实施例提供的一种用于进行数据访问的场景示意图。如图2a所示的用户终端集群中可以包括多个用户终端，如图2a所示，具体可以包括用户终端3000a、用户终端3000b、用户终端3000c；应当理解，本申请实施例可以将用户终端3000a、用户终端3000b、用户终端3000c中的任意一个用户终端均称之为上述图1所示的目标用户终端。图2a所示的接入服务器可以为上述图1所示的接入服务器2000，基于上述图1所对应实施例中针对接入服务器2000与更新管理服务器5000之间的数据交互方式，图2a所示的接入服务器可以在接收到更新管理服务器5000发送的第一路由变更通知时，调整业务请求相关联的路由模式，即可以将当前的路由模式从随机路由模式调整为固定路由模式。
比如，当图2a所示的用户终端3000a向接入服务器2000发送第一业务请求1时，该接入服务器2000可以基于所述第一业务请求1以及调整后的固定路由模式，构建该用户终端3000a与业务服务器集群中的相应业务服务器(例如，图2a所示的业务服务器4000a)之间的业务绑定关系1，进一步的，该接入服务器2000可以基于该业务绑定关系1从业务服务器4000a上获取第一业务数据(例如，业务数据A)，并将该第一业务数据返回给用户终端3000a。其中，本申请实施例中的业务绑定关系1可以基于用户终端3000a的终端标识所对应的哈希值的余数与业务服务器4000a之间的映射关系1所确定的。
以此类推，当图2a所示的用户终端3000b向接入服务器2000发送第一业务请求2时，该接入服务器2000可以基于所述第一业务请求2以及前述固定路由模式，构建该用户终端3000b与业务服务器集群中的相应业务服务器(例如，图2a所示的业务服务器4000b)之间的业务绑定关系2，进一步的，该接入服务器2000可以基于该业务绑定关系2从业务服务器4000b上获取第一业务数据(例如，业务数据B)，并将该第一业务数据返回给用户终端3000a。其中，本申请实施例中的业务绑定关系2可以基于用户终端3000b的终端标识所对应的哈希值的余数与业务服务器4000a之间的映射关系2所确定的。
应当理解，在对不同用户终端的终端标识的哈希值进行哈希求余处理的过程中，对不同用户终端的哈希值进行求余处理后的余数可以是不同的，也可以是相同的。比如，当两个不同的用户终端的哈希值的余数是相同的情况下，可以将这两个用户终端(例如，图2a所示的用户终端3000a与用户终端3000c)绑定至同一业务服务器。例如，在上述业务更新时长内，无论这两个用户终端(例如，图2a所示的用户终端3000a与用户终端3000c)在何时发起第一业务请求，均可以访问同一业务服务器(例如，业务服务器4000a)，即可以在业务更新时长内，确保访问该业务服务器4000a的每个用户终端所访问到的数据内容的一致性。
其中，应当理解，接入服务器2000构建用户终端3000c与业务服务器4000a之间的业务绑定关系3的具体构建方式可以参见上述对构建业务绑定关系1的描述，这里将不再继续进行赘述。
可选的，在分布式缓存环境中，业务服务器集群中的每个业务服务器(即上述图1所对应实施例中的业务服务器4000a、业务服务器4000b、…、业务服务器4000n)均可以为区块链节点中的节点服务器。进一步地，请参见图2b，是本申请实施例提供的一种区块链网络的场景示意图。如图2b所示，为便于理解，本申请实施例仅以该区块链中的部分节点服务器(例如，图2b所示的4个业务服务器，一个业务服务器为一个节点服务器)为例，以阐述这4个节点服务器中的每个节点服务器在上述业务更新时长内完成数据更新时，生成用于上链的区块的具体过程。
如图2b所示，该4个节点服务器可以通过区块链网络共享同一区块链，即图2b所示的区块链1、区块链2、区块链3、区块链4可以为同一区块链，即图2b所示的区块链可以由区块1、…、区块N-1以及区块N组成。每个区块均可以存储用于对每个节点服务器中的业务数据进行数据更新的更新数据信息。可以理解的是，当第一服务器基于数据更新信息完成对业务服务器4000a的数据更新时，可以通过业务服务器4000a生成包含更新数据信息的新的区块(例如，区块N+1)，然后可以将该新的区块通过区块链网络广播至所有节点服务器，从而可以在这些节点服务器达成共识之后，将该区块N+1写入该区块链，即可以将区块N+1添加到图2b所示的区块N之后，并在该区块链中将该区块N+1的确定为具有最大时间戳的区块。
其中，区块N+1包含自身的哈希值和前一个区块(即区块N)的哈希值。通过验证区块N+1中前一个区块N的哈希值与前一区块N自身的哈希值是否相同，可以确定出前一区块中内容是否被篡改，从而可以确保存储在区块链上的用于进行数据更新的更新数据信息的可追溯性和不可篡改性。
应当理解，在业务更新时长内，接入服务器(即第二服务器)在接收到该用户终端(例如，用户终端3000a)发送的第一业务请求时，可以基于该用户终端3000a与业务服务器4000a之间的业务绑定关系，将该第一业务请求转发给业务服务器4000a，以使该业务服务器4000a可以从区块链中获取该用户终端所请求的业务数据(即第一业务数据)，该第一业务数据可以为区块N+1中所存储的对该业务服务器4000a进行数据更新的更新数据信息(即该第一业务数据可以为本次更新的新数据)。可选的，该第一业务数据还可以为从其他区块(例如，区块N)中所存储的上一次对该业务服务器4000a进行数据更新的更新数据信息(即该第一业务数据可以为历史更新的旧数据)。
此外，可以理解的是，图2b所示的业务服务器集群中的其他3个节点服务器在上述业务更新时长内完成数据更新时，也可以生成用于上链的新的区块。其中，其它节点服务器将新的区块写入区块链的具体过程可以一并参见上述对业务服务器4000a的描述方式，在此不再赘述。
其中，第二服务器获取第一服务器发送的路由变更通知、获取用户终端发送的业务请求，以及调整路由模式的具体实现方式可以参见下述图3-图7所对应的实施例。
进一步地，请参见图3，是本申请实施例提供的一种数据处理方法的流程示意图。该方法可以应用于第二服务器。如图3所示，所述方法可以包括：
步骤S101，获取第一服务器发送的第一路由变更通知，基于所述第一路由变更通知将路由模式由第一模式调整为第二模式；
具体地，当第一服务器检测到数据库中存在针对目标应用中的业务数据的更新数据时，向第二服务器发送第一路由变更通知，此时，第二服务器可以将路由模式由第一模式调整为第二模式；所述第一变更通知可以用于指示第二服务器将当前路由模式由随机路由模式变更为固定路由模式。换言之，本申请实施例中的第一模式可以为随机路由模式，第二模式可以为固定路由模式。
应当理解，本申请实施例中的路由模式还可以为其他路由模式，本申请实施例在此不对其进行限制。
其中，第一服务器可以为更新管理服务器，该更新管理服务器可以为上述图1所示的更新管理服务器5000，第二服务器可以为接入服务器，该接入服务器可以为上述图1所示的接入服务器2000。
其中，所述目标应用中的业务数据可以为电子类阅读应用中的电子读物(例如，电子小说、电子杂志、电子书籍等互联网数据信息)，可选的，本申请实施例中的业务数据还可以是浏览器中的电子读物，这里将不对其进行限定。
步骤S102，获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，所述第一业务服务器为业务服务器集群中的业务服务器；
具体地，接入服务器(即第二服务器)在接收到用户终端发送的第一业务请求时，可以提取该第一业务请求中所携带的用户标识信息，所述用户标识信息可以包含用户账户信息和终端标识号码(例如，终端的Identity，简称ID)等，即该用户标识信息可以用于标识用户终端的ID地址等。进一步的，接入服务器可以基于固定路由模式通过哈希算法计算所述用户标识信息对应的哈希值，从而可以通过哈希求余算法对所述哈希值进行求余处理，得到所述哈希值对应的余数。进一步的，接入服务器可以基于所述余数从上述图1所对应实施例中的业务服务器集群中确定用于与所述用户终端具备业务绑定关系的业务服务器。应当理解，该确定的用于与用户终端具有业务绑定关系的业务服务器可以称之为第一业务服务器。用户终端与第一业务服务器之间的绑定关系可以用于指示所述用户终端在上述业务更新时长内可以唯一的访问所述第一业务服务器。
应当理解，当用户终端发送第一业务请求时，该第一业务请求中可以携带前述用户标识信息。例如，当用户需要在目标应用中观看电子读物(例如，电子小说A)时，可以通过目标应用向第二服务器发送业务加载请求(即业务请求)，以使第二服务器可以基于该业务加载请求中的用户标识信息和调整后的路由模式(即第二模式)将发起该业务请求的用户终端与业务服务器集群中的相应业务服务器进行绑定。
其中，可以理解的是，在第一服务器发送第一路由变更通知后的业务更新时长内，本申请实施例可以将第二服务器所接收到的业务加载请求(即业务请求)统称为第一业务请求。此时，基于固定路由模式，第二服务器可以通过第一业务请求中所携带的用户标识信息(例如，用户终端的ID地址)确定该用户标识信息对应的哈希值，进而可以通过哈希求余算法对确定出的哈希值进行求余处理，得到所述哈希值的余数(例如，余数B)。此时，该第二服务器可以基于余数(余数B)从业务服务器集群中搜索到能够与该发起业务请求的用户终端进行绑定的第一业务服务器。
进一步地，请参见表1，为本申请实施例提供的一种余数与业务服务器之间的映射关系表。
其中，在下述表1中，本申请实施例可以预先建立用户终端的哈希值所对应的余数与业务服务器之间的映射关系。为便于理解，本申请实施例可以以上述业务服务器集群中的5个业务服务器为例，这5个业务服务器可以为上述图1所对应实施例中的业务服务器集群中的业务服务器，即业务服务器4000a，业务服务器4000b，业务服务器4000c，业务服务器4000d，业务服务器4000e。
表1
业务服务器 4000a 4000b 4000c 4000d 4000e
业务服务器地址 a b c d e
标识信息 0 1 2 3 4
对应用户终端的余数 0 1 2 3 4
应当理解，一个业务服务器可以对应一个服务器地址，每个业务服务器均可以携带有相应的服务器标识(比如，上述表1所示的标识信息)，该服务器标识用于匹配具有与标识相同的余数的用户终端地址，使该用户终端根据该服务器标识绑定对应的业务服务器的地址。
为便于理解，以上述表1所示的业务服务器4000a为例，该业务服务器4000a的地址为a，该业务服务器4000a地址的标识信息为0，通过该标识信息可以匹配余数为0的用户终端地址，进一步地，将余数为0的用户终端地址与标识信息为0的业务服务器4000a的地址进行业务绑定。该余数0可以根据第二服务器与用户终端地址对应的哈希值通过哈希算法进行除留求余后得到的。
进一步地，请参见以下表2，为本申请实施例提供的一种哈希值求余处理表。
如下述表2所示，为便于理解，本申请实施例可以以5个用户终端为例，这5个用户终端中的每个用户终端均可以为上述图1所对应实施例中的目标用户终端。
表2
用户终端 3000a 3000b 3000c 3000d 3000e
用户终端地址 A B C D E
哈希值 M<sub>1</sub> M<sub>2</sub> M<sub>3</sub> M<sub>4</sub> M<sub>5</sub>
余数 N<sub>1</sub> N<sub>2</sub> N<sub>3</sub> N<sub>4</sub> N<sub>5</sub>
如上述表2所示，用户终端3000a对应的用户终端地址可以为用户终端地址A，通过对该用户终端地址A进行哈希计算，可以得到该用户终端地址对应的哈希值为哈希值M1，从而根据哈希求余算法对该哈希值M1进行求余处理，可以得到该用户终端3000a所对应的哈希值的余数为余数N1。以此类推，上述表2中的其他用户终端的哈希值的余数与相应用户终端之间的映射关系，可以一并参见前述对用户终端3000a与该用户终端3000a的哈希值的余数之间的映射关系的描述，在此不再继续进行赘述。
应当理解，一个用户终端可以对应一个用户终端地址，每个用户终端地址均可以通过哈希算法计算出该用户终端地址所对应的哈希值，从而可以通过哈希求余算法对该哈希值进行求余处理，得到该哈希值所对应的余数。
应当理解，在哈希求余算法中可以使用取模运算，即：将哈希值转换为十进制，进而对转换的十进制数值除以十，得到该哈希值对应的余数。为便于理解，以上述表2所示的用户终端3000a为例，当用户终端3000a的用户地址A以二进制表示为1001001时，则根据哈希算法计算出该哈希值M1为表示为73。进一步地，根据该用户终端3000a的哈希值73，可以通过取模运算计算，即73％10＝3，得到该用户终端3000a的余数N1为3。可以理解的是，该用户终端3000a与余数为3所对应的标识信息为3的业务服务器4000d的地址d进行业务绑定，即该用户终端3000a发送第一业务请求(例如，业务请求A)，可以从业务服务器4000d获取第一业务数据(例如，业务数据A)。
应当理解，在哈希求余算法中还可以用位运算来代替取模运算，具体地，如下述公式(1)：
X％2^n＝X&(2^n-1)， (1)
其中，X为用户终端地址经过哈希算法计算的哈希值，n为一个整数。可以理解的是，用户终端地址所计算的哈希值对2^n进行取模运算相当于对此哈希值和(2^n–1)做按位与运算。
其中，若n为3，则2^3＝8，表示成2进制为1000。进而2^3-1＝7，表示为二进制为0111。可以理解的是，当用户终端计算的哈希值对除数8进行取模运算相当于与7进行按位与运算，从二进制角度来看，X/8相当于X>>3，即把X右移3位，此时得到了X/8的商，而被移掉的部分(后三位)，则是X％8，也就是该哈希值的余数。其中，该余数相当于取二进制表示的哈希值的最后三位数。
其中，为便于理解，以上述表2所示的用户终端3000a为例，用户终端3000a的用户地址A为1001001，该用户终端3000a的哈希值为1001001，将此哈希值与7进行按位与运算，将1001001右移三位，被移掉的三位数001即为余数，则该用于终端3000a的余数为1。可以理解的是，该用户终端3000a与通过该余数1与所对应的标识信息为1的业务服务器4000b的地址b进行业务绑定，即用户终端3000a发送第一业务请求(例如，业务请求B)，可从业务服务器4000b获取业务数据(例如，业务数据B)。
应当理解，依次类推，上述表2中的用户终端所对应的哈希求余算法计算得到所对应的余数的过程参见上述用户终端3000a计算得到N1的过程，在此不再继续进行赘述。此外，可以理解的是，本申请实施例可以采用取模运算和位运算计算用户终端哈希值所对应的余数，当然，也可以采用其他计算用户终端所对应余数的方式获取每个用户终端的哈希值的余数，在此不做限定。
步骤S103，基于所述业务绑定关系从所述第一业务服务器上获取第一业务数据，将所述第一业务数据返回给所述用户终端。
具体地，基于哈希求余算法，可以将所述用户终端与所述第一业务服务器(例如，上述图1实施例所述的业务服务器4000a)进行业务绑定，可以理解的是，当用户终端根据用户的需求向第二服务器发送第一业务请求时，业务服务器4000a可以将曾经从所述第一服务器的数据库中所同步缓存的第一业务数据(例如，业务数据A)返回给所述第二服务器，所述第二服务器可以将第一业务数据返回给与该业务服务器4000a具有业务绑定关系的该用户终端。
本申请实施例中的第二服务器可以在获取到第一服务器发送的第一路由变更通知时，将业务请求相关联的路由模式由第一模式调整为第二模式，然后在获取到用户终端发送的业务请求(例如，第一业务请求)时，确定所述用户终端与第一业务服务器之间的业务绑定关系，并将从所述第一业务服务器获取到的第一业务数据返回给用户终端。可见，本申请可以在分布式环境下，第二服务器(比如，接入服务器)可以在接收到用户终端发送的业务请求时，进一步基于调整后的路由模式(即第二模式)，构建用户终端与唯一业务服务器之间的绑定关系，以使用户终端在不同时间访问业务服务器，可以确保所得到的数据内容的强一致性。
进一步地，请参见图4，是本申请实施例提供的另一种数据处理方法的流程示意图。该方法可以应用于第二服务器，如图4所示，所述方法包括：
步骤S201，获取第一服务器发送的第一路由变更通知，基于所述第一路由变更通知将路由模式由第一模式调整为第二模式；
具体地，当第一服务器检测到数据库中存在针对目标应用中的业务数据的更新数据时，向第二服务器发送第一路由变更通知，此时，第二服务器可以将路由模式由第一模式调整为第二模式；所述第一变更通知可以用于指示第二服务器将当前路由模式由随机路由模式变更为固定路由模式。换言之，本申请实施例中的第一模式可以为随机路由模式，第二模式可以为固定路由模式。
其中，第一服务器可以为更新管理服务器，该更新管理服务器可以为上述图1所示的更新管理服务器5000，第二服务器可以为接入服务器，该接入服务器可以为上述图1所示的接入服务器2000。
步骤S202，获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，所述第一业务服务器为业务服务器集群中的业务服务器；
具体地，接入服务器(即第二服务器)在接收到用户终端发送的第一业务请求时，可以提取该第一业务请求中所携带的用户标识信息，所述用户标识信息可以包含用户账户信息和终端标识号码(例如，终端的Identity，简称ID)等，即该用户标识信息可以用于标识用户终端的ID地址等。进一步的，接入服务器可以基于固定路由模式通过哈希算法计算所述用户标识信息对应的哈希值，从而可以通过哈希求余算法对所述哈希值进行求余处理，得到所述哈希值对应的余数。进一步的，接入服务器可以基于所述余数从上述图1所对应实施例中的业务服务器集群中确定用于与所述用户终端具备业务绑定关系的业务服务器。应当理解，该确定的用于与用户终端具有业务绑定关系的业务服务器可以称之为第一业务服务器。用户终端与第一业务服务器之间的绑定关系可以用于指示所述用户终端在上述业务更新时长内可以唯一的访问所述第一业务服务器。
可以理解的是，本申请实施例中的业务服务器集群中的每个业务服务器均可以为上述图2b所示是的区块链网络中的节点服务器，即每个节点服务器均可以用于在完成数据更新时，将用于进行本次数据更新的更新数据信息生成一个新的区块，从而将该新的区块上链至区块链进行数据存储。这里将不对其进行赘述。可选的，本申请实施例中的业务服务器集群中的每个业务服务器也可以是其它分布式环境中用于进行数据存储的服务器，这里将不对其进行限制。
步骤S203，基于所述业务绑定关系从所述第一业务服务器上获取第一业务数据，将所述第一业务数据返回给所述用户终端。
具体地，基于哈希求余算法，第二服务器(即接入服务器)可以将所述用户终端与所述第一业务服务器(例如，上述图1所示的业务服务器4000a)进行业务绑定。可以理解的是，当用户终端根据用户的需求向第二服务器发送第一业务请求时，第二服务器可以将该第一业务请求转发给予该用户终端具有业务绑定关系的业务服务器4000a。此时，业务服务器4000a可以将曾经从所述第一服务器的数据库中所缓存好的第一业务数据(例如，业务数据A)返回给所述第二服务器。进一步的，所述第二服务器可以将接收到的第一业务数据返回给与该业务服务器4000a具有业务绑定关系的该用户终端。
其中，所述步骤S201-步骤S203的具体实施方式可参见上述图3所对应实施例中对步骤S101-步骤S103的描述，这里将不再赘述。
步骤S204，基于所述业务绑定关系生成所述第一路由变更通知对应的第一变更结果，向所述第一服务器返回所述第一变更结果，以使所述第一服务器基于数据更新信息对所述第一业务服务器和第二业务服务器进行数据更新。
具体地，第二服务器可以在确定好与用户终端具有业务绑定关系的第一业务服务器之后，生成所述第一路由变更通知对应的第一变更结果，并将该第一变更结果返回给第一服务器。此时，第一服务器可以基于接收到的第一变更结果，用该数据库中所缓存的针对目标应用中业务数据的更新数据对业务服务器集群中的每个业务服务器进行数据更新，比如，可以对该业务服务器集群中的第一业务服务器和第二业务服务器进行更新。其中，本申请实施例中的第一业务服务器可以为当前与用户终端具有业务绑定关系的业务服务器；本申请实施例中的第二业务服务器可以为业务服务器集群中除第一业务服务器之前的业务服务器，即此时的第二业务服务器与用户终端之间并不存在前述业务绑定关系。
应当理解，如上述图1所示，接入服务器2000在接收到更新管理服务器5000发送的第一路由变更通知时，接入服务器可以将随机路由模式调整为固定路由模式。
其中，在随机路由模式下，用户终端可以随机的访问业务服务器集群中的任一业务服务器进行，该业务服务器可以是业务服务器4000a，也可以是业务服务器4000b。所以，通过将随机路由模式调整为固定路由模式，可以构建用户终端与业务服务器集群中的相应业务服务器之间的业务绑定关系。比如，接入服务器2000可以根据哈希求余算法，将用户终端与业务服务器集群中的相应业务服务器(例如，业务服务器4000a)进行业务绑定。此时，接入服务器2000可以将用户终端与业务服务器4000a进行绑定后的第一变更结果返回给更新管理服务器5000。进一步地，更新管理服务器5000可以基于接收到的第一变更结果对业务服务器集群中的每个业务服务器均进行数据更新。本申请实施例可以将业务服务器集群中的每个业务服务器的数据进行更新后的数据统称为第二业务数据。
步骤S205，当所述业务服务器集群中的所有业务服务器均完成数据更新时，获取所述第一服务器发送的第二路由变更通知，基于所述第二路由变更通知将路由模式由所述第二模式调整为所述第一模式。
具体地，当业务服务器集群中的所有业务服务器均完成更新时，业务服务器可以将完成更新的结果返回给第一服务器。此时，第一服务器可以进一步向第二服务器发送第二路由变更通知。应当理解，第二服务器可以根据第一服务器所发送的第二路由变更通知，将路由模式由第二模式(例如，固定路由模式)调整为第一模式(例如，随机路由模式)。
应当理解，如上述图1所示，所述更新管理服务器5000对整个业务服务器集群进行数据更新后，业务服务器集群在确定所有业务服务器完成更新后，可以生成一个更新结果。并可以进一步将更新结果返回给更新管理服务器5000。此时，该更新管理服务器5000可以基于该更新结果向接入服务器2000发送第二路由变更通知。进一步的，接入服务器2000可以根据第二路由变更通知，将路由模式由固定路由模式调整为随机路由模式。
步骤S206，根据所述第一模式解除所述业务绑定关系。
具体地，第二服务器可以根据第一模式(例如，随机路由模式)解除用户终端与上述第一业务服务器(例如，上述图1所示的业务服务器4000a)之间的业务绑定关系。换言之，在该随机路由模式下，接入服务器2000可以将该用户终端发送的请求随机转发给业务服务器集群中的任意一台已完成数据更新的业务服务器，从而可以确保该用户终端后续所随机访问到的业务服务器集群中的任一台业务服务器中的数据内容的强一致性。
应当理解为，如图1所示，接入服务器2000可以在当前路由模式为第一模式(即随机路由模式)时，解除该用户终端与业务服务器4000a之间的业务绑定关系，使得该用户终端在下一次发起业务请求(比如，第二业务请求)时，可以基于路由表随机访问该业务服务器集群中的任意一台业务服务器。
步骤S207，获取所述用户终端发送的第二业务请求，基于所述第二业务请求以及所述第一模式，获取第二业务数据，将所述第二业务数据返回给所述用户终端；所述第二业务数据为对所述第一业务请求数据进行数据更新后所确定的。
具体地，所述用户终端与第一业务服务器解除业务绑定后，向第二服务器发送第二业务请求，第二业务服务器获取所述用户终端发送的所述第二业务请求后，进一步地，获取与所述第一模式相关联的路由规则表，基于所述第二业务请求从所述路由规则表所包含的路由地址中选取目标服务标识信息；基于所述目标服务标识信息在所述服务器集群中确定目标业务服务器，从所述目标业务服务器上获取第二业务数据；将所述第二业务数据返回给所述用户终端。
其中，应当理解，在本申请实施例中可以将第一服务器基于上述更新结果向第二服务器发送第二路由变更通知时的时刻称之为第三时刻。
其中，可以理解的是，第一服务器在接收到上述更新结果(即业务服务器集群中的所有业务服务器均完成数据更新)之后，可以向第二服务器发送第二路由变更通知。
此外，本申请实施例可以将第一服务器下一次发起新的第一路由变更通知的时刻称之为第四时刻(例如，T4时刻)，即该第四时刻可以理解为新的第一时刻。
应当理解，当第一服务器在下一次确定数据库中缓存有针对目标应用中的业务数据的更新数据时，可以向第二服务器再次发送新的第一路由变更通知，以重复执行上述步骤S201－步骤S207，以完成相应的路由变更逻辑。
鉴于此，为便于与上述第一业务请求进行区别，本申请实施例可以将第三时刻与第四时刻之间所发送的业务请求称之为第二业务请求。
进一步地，请参见以下图5，是本申请实施例提供的一种路由变更规则图。如图5所示的固定路由模式是指第二服务器根据用户终端发送的第一业务请求，提取所述第一业务请求中所携带的用户标识信息，如用户ID地址。进一步的，接入服务器(即第二服务器)通过对该ID地址对应的哈希值进行求余处理，可以得到所述哈希值对应的余数，进而可以基于所述余数在业务服务器集群中查找到相应的业务服务器，并可以将查找到的业务服务器作为用于与该用户终端进行业务绑定的第一业务服务器，此时，同一用户终端不论在何时发送用户请求，所请求访问的业务服务器均是与该用户终端具有业务绑定关系的第一业务服务器，从而可以确保在上述业务更新时长内所请求访问到的数据内容的强一致性。
如图5所示的随机路由模式是指用户终端可通过接入服务器(即第二服务器)随机的访问业务服务器集群中的任一台已完成数据更新的业务服务器。由于此时，每台业务服务器均完成了数据更新，即每台业务服务器上的数据内容并不会存在不同，所以，第二服务器在接收到第二业务请求时，第二服务器可以将该第二业务请求随机转发给任意一台业务服务器，这些业务服务器的服务标识信息可以为图5所示的业务服务器1的地址，业务服务器2的地址，业务服务器3的地址。
为便于理解，本申请实施例可以将接收到第二业务请求的业务服务器称之为目标业务服务器，该目标业务服务器的目标服务标识信息可以为图5所示的业务服务器2的地址。
所以，在该随机路由所对应的路由模式下，同一个用户终端在不同时间所发送的业务请求可以被该第二服务器分配给不同的业务服务器，即在该随机路由模式下的同一用户终端在不同时间所请求访问到的业务服务器可以是不同的。
比如，该用户终端在下一次发起新的第二业务请求时，接收到该新的第二业务请求的目标业务服务器的目标服务标识信息可以为图5所示的业务服务器3的地址，也可以是图5所示的业务服务器1的地址，这里将不对其进行限定。
比如，若与所述目标服务标识信息相关联的业务服务器为所述第二业务服务器(例如，业务服务器4000b)，则可以从所述第二业务服务器中获取第二业务数据(例如，业务数据B)。
可选的，又比如，若与所述目标服务标识信息相关联的业务服务器为所述第一业务服务器(例如，业务服务器4000a)，则可以从所述第一业务服务器中获取第二业务数据(例如，业务数据B)。
其中，所述第一业务服务器为业务服务器集群中与目标用户终端有固定映射关系的业务服务器4000a，所述第二业务服务器为业务服务器集群中除业务服务器4000a以外的其他业务服务器，所述第二业务数据可以为更新管理服务器5000已对其进行数据更新后的业务数据。
进一步地，请参见图6，是本申请实施例提供的一种数据处理方法的交互流程示意图。该交互流程示意图可以包含多个交互终端，具体可以包括用户终端，第二服务器，业务服务器集群以及第一服务器。
其中，所述步骤S301-步骤S312的具体实施方式可参见上述图4所对应实施例中的描述，这里将不再赘述。
如图6所示，在第一服务器中确定针对用户终端的目标应用中的业务数据有数据更新时，第一服务器可以向第二服务器发送第一路由变更通知，第二服务器根据第一路由变更通知将路由模式由第一路由(例如，随机路由模式)调整为第二路由(例如，固定路由模式)。其中，将第一服务器发起第一路由变更通知的时刻记录为T1时刻。
应当理解，所述第一服务器可在业务服务器集群中的每一个业务服务器均完成针对目标应用的业务数据进行同步缓存更新时，接收到第二服务器向第一服务器发送的第二路由变更通知，第二服务器根据第二路由变更通知将路由模式由第二路由(例如，固定路由模式)调整为第一路由(例如，随机路由模式)。其中，将第一服务器接收到如上述图1所示的业务服务器集群中的所有业务服务器返回确认更新结果时的时刻记录为T2时刻。
其中，进一步地，请参见图7，是本申请实施例提供的一种记录时间戳的场景示意图。如图7所示的T1时刻可以为第一服务器发起第一路由变更通知的时刻，该T1时刻可以为上述第一时刻。如图7所示的T2时刻可以为第一服务器接收到图1所示的业务服务器集群中的所有业务服务器返回确认更新结果时的时刻，即该T2时刻可以为上述第二时刻。如图7所示的T3时刻可以为第一服务器发起第二路由变更通知的时刻，该T3时刻可以为上述第三时刻。如图7所示的T4时刻可以为第一服务器下一次发起新的第一路由变更通知的时刻，即该T4时刻可以为上述第四时刻。应当理解，这里的T2时刻与T3时刻之间的时间间隔可以很短，这里将不对其进行限定。这里的第四时刻可以理解为一种新的第一时刻。
如图7所示，在T1时刻与T2时刻之间的这段时间(即上述业务更新时长)内，第二服务器可以接收用户终端所发起的第一业务请求。换言之，当用户终端在图7所示的K1时刻向第二服务器发起第一业务请求时，可以从与该用户终端具有业务绑定关系的第一服务器上获取到图7所示的第一业务数据。
如图7所示，在T3时刻与T4时刻之间的这段时间内，第二服务器可以接收用户终端所发起的第二业务请求。换言之，当用户终端在图7所示的K2时刻向第二服务器发起第二业务请求时，可以为该用户终端随机分配一个已经完成数据更新的业务服务器(该随机分配的已经完成数据更新的业务服务器可以称之为目标业务服务器)，从而可以从该目标业务服务器上将获取到的业务数据称之为第二业务数据。该第二业务数据可以与第一业务数据相同，也可以与第一业务数据不同。
本申请实施例中的第二服务器可以在获取到第一服务器发送的第一路由变更通知时，将业务请求相关联的路由模式由第一模式调整为第二模式，然后在获取到用户终端发送的业务请求(例如，第一业务请求)时，确定所述用户终端与第一业务服务器之间的业务绑定关系，并将从所述第一业务服务器获取到的第一业务数据返回给用户终端。可见，本申请可以在分布式环境下，第二服务器(比如，接入服务器)可以在接收到用户终端发送的业务请求时，进一步基于调整后的路由模式(即第二模式)，构建用户终端与唯一业务服务器之间的绑定关系，以使用户终端在不同时间访问业务服务器，可以得到的内容是强一致性的。
进一步地，请参见图8，是本申请实施例提供的一种数据处理装置结构示意图。该装置应用于第二服务器，如图8所示，所述数据处理装置1可以为上图1对应实施例的接入服务器2000，所述数据处理装置1可以包括：第一获取模块10，第二获取模块20，第三获取模块30，数据更新模块40，路由变更模块50，解除模块60以及第四获取模块70。
所述第一获取模块10，用于获取第一服务器发送的第一路由变更通知，基于所述第一路由变更通知将路由模式由第一模式调整为第二模式；
所述第二获取模块20，用于获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，所述第一业务服务器为业务服务器集群中的业务服务器；
其中，所述第一模式为随机路由模式，所述第二模式为固定路由模式；
所述第二获取模块20包括：提取单元201，确定单元202，构建单元203；
所述提取单元201，用于获取所述用户终端发送的所述第一业务请求，提取所述第一业务请求中所携带的用户标识信息；
所述确定单元202，用于根据固定路由模式确定所述用户标识信息对应的哈希值，对所述哈希值进行求余处理，得到所述哈希值对应的余数，基于所述余数从业务服务器集群中确定所述用户终端所对应的第一业务服务器；
所述构建单元203，用于构建所述用户终端与所述第一业务服务器的业务绑定关系，所述业务绑定关系用于指示所述用户终端访问所述第一业务服务器。
所述第三获取模块30，用于基于所述业务绑定关系从所述第一业务服务器上获取第一业务数据，将所述第一业务数据返回给所述用户终端。
所述数据更新模块40，用于基于所述业务绑定关系生成所述第一路由变更通知对应的第一变更结果，向所述第一服务器返回所述第一变更结果，以使所述第一服务器基于数据更新信息对所述第一业务服务器和第二业务服务器进行数据更新。
所述路由变更模块50，用于当所述业务服务器集群中的所有业务服务器均完成数据更新时，获取所述第一服务器发送的第二路由变更通知，基于所述第二路由变更通知将路由模式由所述第二模式调整为所述第一模式。
所述解除模块60，用于根据所述第一模式解除所述业务绑定关系。
所述第四获取模块70，用于获取所述用户终端发送的第二业务请求，基于所述第二业务请求以及所述第一模式，获取第二业务数据，将所述第二业务数据返回给所述用户终端；所述第二业务数据为对所述第一业务请求数据进行数据更新后所确定的。
其中，所述业务服务器集群中的每个业务服务器均为区块链中的节点服务器，且所述每个业务服务器在完成数据更新时，均用于将携带所述更新数据信息的区块写入所述区块链。
其中，所述第四获取模块70包括：获取业务请求单元701，选取标识单元702，获取业务数据单元703以及返回业务数据单元704。
所述获取业务请求单元701，用于获取所述用户终端发送的所述第二业务请求。
所述选取标识单元702，用于获取与所述第一模式相关联的路由规则表，基于所述第二业务请求从所述路由规则表所包含的路由地址中选取目标服务标识信息。
所述获取业务数据单元703，用于基于所述目标服务标识信息在所述服务器集群中确定目标业务服务器，从所述目标业务服务器上获取第二业务数据。
所述返回业务数据单元704，用于将所述第二业务数据返回给所述用户终端。
本申请实施例中的第二服务器可以在获取到第一服务器发送的第一路由变更通知时，将业务请求相关联的路由模式由第一模式调整为第二模式，然后在获取到用户终端发送的业务请求(例如，第一业务请求)时，确定所述用户终端与第一业务服务器之间的业务绑定关系，并将从所述第一业务服务器获取到的第一业务数据返回给用户终端。可见，本申请可以在分布式环境下，第二服务器(比如，接入服务器)可以在接收到用户终端发送的业务请求时，进一步基于调整后的路由模式(即第二模式)，构建用户终端与唯一业务服务器之间的绑定关系，以使用户终端在不同时间访问业务服务器，可以得到的内容是强一致性的。
进一步地，请参见图9，是本申请实施例提供的一种计算机处理设备的示意图。如图9所示，所述计算机设备1000可以为上述图1对应实施例中的接入服务器2000，所述计算机设备1000可以包括：至少一个处理器1001，例如CPU，至少一个网络接口1004，用户接口1003，存储器1005，至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，用户接口1003可以包括显示屏(Display)、键盘(Keyboard)，网络接口1004可选地可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1005可选地还可以是至少一个位于远离前述处理器1001的存储装置。如图9所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
在图9所示的计算机处理设备1000中，网络接口1004主要用于业务服务器、用户终端和更新管理服务器；而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以实现：
获取第一服务器发送的第一路由变更通知，基于所述第一路由变更通知将路由模式由第一模式调整为第二模式；
获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，所述第一业务服务器为业务服务器集群中的业务服务器；
基于所述业务绑定关系从所述第一业务服务器上获取第一业务数据，将所述第一业务数据返回给所述用户终端。
应当理解，本申请实施例中所描述的计算机处理设备1000可执行前文图3或图4所对应实施例中对所述数据处理方法的描述，也可执行前文图8所对应实施例中对所述数据处理装置1的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且所述计算机可读存储介质中存储有前文提及的数据处理装置1所执行的计算机程序，且所述计算机程序包括程序指令，当所述处理器执行所述程序指令时，能够执行前文图3或图4所对应实施例中对所述数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。
以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (10)

1.一种数据处理的方法，其特征在于，所述方法应用于第二服务器，包括：
获取第一服务器发送的第一路由变更通知，基于所述第一路由变更通知将路由模式由第一模式调整为第二模式；
获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，所述第一业务服务器为业务服务器集群中的业务服务器；
基于所述业务绑定关系从所述第一业务服务器上获取第一业务数据，将所述第一业务数据返回给所述用户终端。
2.根据权利要求1所述的方法，其特征在于，所述第一模式为随机路由模式，所述第二模式为固定路由模式；
所述获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，包括：
获取所述用户终端发送的所述第一业务请求，提取所述第一业务请求中所携带的用户标识信息；
基于所述固定路由模式确定所述用户标识信息对应的哈希值，对所述哈希值进行求余处理，得到所述哈希值对应的余数，基于所述余数从业务服务器集群中确定所述用户终端对应的第一业务服务器；
构建所述用户终端与所述第一业务服务器的业务绑定关系，所述业务绑定关系用于指示所述用户终端访问所述第一业务服务器。
3.根据权利要求1所述的方法，其特征在于，所述业务服务器集群包含第二业务服务器；
所述方法还包括：
基于所述业务绑定关系生成所述第一路由变更通知对应的第一变更结果，向所述第一服务器返回所述第一变更结果，以使所述第一服务器基于数据更新信息对所述第一业务服务器和第二业务服务器进行数据更新。
4.根据权利要求3所述的方法，其特征在于，还包括：
当所述业务服务器集群中的所有业务服务器均完成数据更新时，获取所述第一服务器发送的第二路由变更通知，基于所述第二路由变更通知将路由模式由所述第二模式调整为所述第一模式；
根据所述第一模式解除所述业务绑定关系；
获取所述用户终端发送的第二业务请求，基于所述第二业务请求以及所述第一模式，获取第二业务数据，将所述第二业务数据返回给所述用户终端；所述第二业务数据为对所述第一业务请求数据进行数据更新后所确定的。
5.根据权利要求4所述的方法，其特征在于，所述获取所述用户终端发送的第二业务请求，基于所述第二业务请求以及所述第一模式，获取第二业务数据，将所述第二业务数据返回给所述用户终端，包括：
获取所述用户终端发送的所述第二业务请求；
获取与所述第一模式相关联的路由规则表，基于所述第二业务请求从所述路由规则表所包含的路由地址中选取目标服务标识信息；
基于所述目标服务标识信息在所述服务器集群中确定目标业务服务器，从所述目标业务服务器上获取第二业务数据；
将所述第二业务数据返回给所述用户终端。
6.根据权利要求5所述的方法，其特征在于，所述基于所述目标服务标识信息从所述服务器集群中确定目标业务服务器，从所述目标业务服务器上获取第二业务数据，包括：
若与所述目标服务标识信息相关联的业务服务器为所述第二业务服务器，则从所述第二业务服务器中获取第二业务数据；
若与所述目标服务标识信息相关联的业务服务器为所述第一业务服务器，则从所述第一业务服务器中获取第二业务数据。
7.根据权利要求4所述的方法，其特征在于，所述业务服务器集群中的每个业务服务器均为区块链中的节点服务器，且所述每个业务服务器在完成数据更新时，均用于将携带所述更新数据信息的区块写入所述区块链。
8.一种数据处理的装置，其特征在于，所述装置应用于第二服务器，包括：
第一获取模块：用于获取第一服务器发送的第一路由变更通知，基于所述第一路由变更通知将路由模式由第一模式调整为第二模式；
第二获取模块：用于获取用户终端发送的第一业务请求，基于所述第一业务请求以及所述第二模式，确定所述用户终端与第一业务服务器之间的业务绑定关系，所述第一业务服务器为业务服务器集群中的业务服务器；
第三获取模块：用于基于所述业务绑定关系从所述第一业务服务器上获取第一业务数据，将所述第一业务数据返回给所述用户终端。
9.一种计算机处理设备，其特征在于，包括：处理器、存储器、网络接口；
所述处理器与存储器、网络接口相连，其中，网络接口用于提供数据通信功能，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以执行如权利要求1-7任一项所述的方法。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时，执行如权利要求1-7任一项所述的方法。
CN201910835730.6A 2019-09-04 2019-09-04 一种数据处理的方法、装置及存储介质 Active CN110572451B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910835730.6A CN110572451B (zh) 2019-09-04 2019-09-04 一种数据处理的方法、装置及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910835730.6A CN110572451B (zh) 2019-09-04 2019-09-04 一种数据处理的方法、装置及存储介质

Publications (2)

Publication Number Publication Date
CN110572451A true CN110572451A (zh) 2019-12-13
CN110572451B CN110572451B (zh) 2021-04-30

Family

ID=68777860

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910835730.6A Active CN110572451B (zh) 2019-09-04 2019-09-04 一种数据处理的方法、装置及存储介质

Country Status (1)

Country Link
CN (1) CN110572451B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111614726A (zh) * 2020-04-24 2020-09-01 深圳震有科技股份有限公司 一种数据转发方法、集群系统及存储介质
CN111736761A (zh) * 2020-05-12 2020-10-02 深圳震有科技股份有限公司 数据分发方法、装置、存储系统及计算机可读存储介质
CN111901389A (zh) * 2020-07-03 2020-11-06 北京达佳互联信息技术有限公司 数据更新方法、装置、服务器及存储介质
CN113839999A (zh) * 2021-09-18 2021-12-24 上海明略人工智能(集团)有限公司 基于多集群的设备回调分发方法、系统、设备及存储介质

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040157557A1 (en) * 2003-02-07 2004-08-12 Lockheed Martin Corporation System for a dynamic ad-hoc wireless network
CN102333029A (zh) * 2011-06-23 2012-01-25 北京新媒传信科技有限公司 一种服务器集群系统中的路由方法
US20130198805A1 (en) * 2012-01-24 2013-08-01 Matthew Strebe Methods and apparatus for managing network traffic
CN104915353A (zh) * 2014-03-13 2015-09-16 中国电信股份有限公司 分布式数据库下全局主键生成方法和系统
US20150270987A1 (en) * 2014-03-20 2015-09-24 Panasonic Intellectual Property Management Co., Ltd. Data distribution device and imaging apparatus
US20150358198A1 (en) * 2014-06-06 2015-12-10 Microsoft Corporation Dynamic Scheduling of Network Updates
CN105794149A (zh) * 2013-09-30 2016-07-20 英国电讯有限公司 数据网络管理
CN106034080A (zh) * 2015-03-10 2016-10-19 中兴通讯股份有限公司 分布式系统中元数据的迁移方法及装置
CN108055312A (zh) * 2017-12-07 2018-05-18 畅捷通信息技术股份有限公司 路由方法及其装置与计算机装置及其可读存储介质
CN108712332A (zh) * 2018-05-17 2018-10-26 华为技术有限公司 一种通信方法、系统和装置
CN109492013A (zh) * 2018-11-02 2019-03-19 北京京东金融科技控股有限公司 应用于数据库集群的数据处理方法、装置和系统
CN110086719A (zh) * 2019-04-30 2019-08-02 深圳市腾讯网域计算机网络有限公司 数据处理方法、装置及服务器

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040157557A1 (en) * 2003-02-07 2004-08-12 Lockheed Martin Corporation System for a dynamic ad-hoc wireless network
CN102333029A (zh) * 2011-06-23 2012-01-25 北京新媒传信科技有限公司 一种服务器集群系统中的路由方法
US20130198805A1 (en) * 2012-01-24 2013-08-01 Matthew Strebe Methods and apparatus for managing network traffic
CN105794149A (zh) * 2013-09-30 2016-07-20 英国电讯有限公司 数据网络管理
CN104915353A (zh) * 2014-03-13 2015-09-16 中国电信股份有限公司 分布式数据库下全局主键生成方法和系统
US20150270987A1 (en) * 2014-03-20 2015-09-24 Panasonic Intellectual Property Management Co., Ltd. Data distribution device and imaging apparatus
US20150358198A1 (en) * 2014-06-06 2015-12-10 Microsoft Corporation Dynamic Scheduling of Network Updates
CN106034080A (zh) * 2015-03-10 2016-10-19 中兴通讯股份有限公司 分布式系统中元数据的迁移方法及装置
CN108055312A (zh) * 2017-12-07 2018-05-18 畅捷通信息技术股份有限公司 路由方法及其装置与计算机装置及其可读存储介质
CN108712332A (zh) * 2018-05-17 2018-10-26 华为技术有限公司 一种通信方法、系统和装置
CN109492013A (zh) * 2018-11-02 2019-03-19 北京京东金融科技控股有限公司 应用于数据库集群的数据处理方法、装置和系统
CN110086719A (zh) * 2019-04-30 2019-08-02 深圳市腾讯网域计算机网络有限公司 数据处理方法、装置及服务器

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111614726A (zh) * 2020-04-24 2020-09-01 深圳震有科技股份有限公司 一种数据转发方法、集群系统及存储介质
CN111736761A (zh) * 2020-05-12 2020-10-02 深圳震有科技股份有限公司 数据分发方法、装置、存储系统及计算机可读存储介质
CN111901389A (zh) * 2020-07-03 2020-11-06 北京达佳互联信息技术有限公司 数据更新方法、装置、服务器及存储介质
CN111901389B (zh) * 2020-07-03 2023-07-04 北京达佳互联信息技术有限公司 数据更新方法、装置、服务器及存储介质
CN113839999A (zh) * 2021-09-18 2021-12-24 上海明略人工智能(集团)有限公司 基于多集群的设备回调分发方法、系统、设备及存储介质

Also Published As

Publication number Publication date
CN110572451B (zh) 2021-04-30

Similar Documents

Publication Publication Date Title
CN110572451B (zh) 一种数据处理的方法、装置及存储介质
CN106933854B (zh) 短链接处理方法、装置及服务器
CN109040341B (zh) 智能合约地址的生成方法、装置、计算机设备及可读存储介质
CN108737325B (zh) 一种多租户数据隔离方法、装置及系统
WO2021051880A1 (zh) 资源数据获取的方法、装置、计算机设备和存储介质
WO2017114206A1 (zh) 短链接处理方法、装置及短链接服务器
CN109542361B (zh) 一种分布式存储系统文件读取方法、系统及相关装置
CN109710695B (zh) 事务请求有效性识别和发起方法、装置、设备和介质
CN109447820B (zh) 数据处理方法、装置、计算机设备及存储介质
CN104756080A (zh) 扩展主机设备的功能
CN112423281B (zh) 无线模组升级方法、装置、计算机设备和存储介质
CN111831208A (zh) 一种信息处理方法、装置、终端设备及存储介质
CN111290779A (zh) 灰度发布方法、装置、存储介质和电子设备
WO2019019676A1 (zh) 业务编号分配方法、装置、计算机设备和存储介质
CN112445729A (zh) 操作地址确定方法、PCIe系统、电子设备及存储介质
EP4310691A1 (en) Blockchain-based data processing method, apparatus, and device, and storage medium
CN115964319A (zh) 远程直接内存访问的数据处理方法及相关产品
CN111803917A (zh) 资源的处理方法和装置
CN108520401B (zh) 用户名单管理方法、装置、平台及存储介质
CN103905201A (zh) 主应用与多个从属应用的交互方法及装置
CN109391658B (zh) 一种账号数据同步方法及其设备、存储介质、终端
CN113110944A (zh) 信息查找方法、装置、服务器、可读存储介质及程序产品
CN105610596B (zh) 一种资源目录管理方法和网络终端
CN109088913B (zh) 请求数据的方法和负载均衡服务器
CN107526530B (zh) 数据处理方法和设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant