CN113296968A - 地址列表更新方法、装置、介质及电子设备 - Google Patents

地址列表更新方法、装置、介质及电子设备 Download PDF

Info

Publication number
CN113296968A
CN113296968A CN202010108888.6A CN202010108888A CN113296968A CN 113296968 A CN113296968 A CN 113296968A CN 202010108888 A CN202010108888 A CN 202010108888A CN 113296968 A CN113296968 A CN 113296968A
Authority
CN
China
Prior art keywords
address
address list
list
queue
service
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.)
Pending
Application number
CN202010108888.6A
Other languages
English (en)
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 CN202010108888.6A priority Critical patent/CN113296968A/zh
Publication of CN113296968A publication Critical patent/CN113296968A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/547Remote procedure calls [RPC]; Web services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/541Client-server
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/548Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Databases & Information Systems (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Data Mining & Analysis (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本公开提供了一种地址列表更新方法、装置、介质及电子设备。该方法包括:依次接收对应于服务提供方的待处理的地址列表;根据地址列表的接收次序确定当前待处理的最新地址列表;通过地址刷新线程读取最新地址列表,并按照最新地址列表更新本地存储的服务提供方的可用地址列表。本公开通过地址刷新线程读取在地址列表中确定出的最新地址列表,实现对本地存储的可用地址列表的更新。一方面,在监听到地址列表的更新消息时,减少了地址列表的刷新次数,降低了地址列表的时延,保证了地址列表的实时性和准确性,进一步提高了服务的可用性;另一方面,无需频繁刷新地址列表,减少了地址刷新线程负载,提升了地址刷新线程的有效刷新效率。

Description

地址列表更新方法、装置、介质及电子设备
技术领域
本公开涉及通信技术领域,具体而言,涉及一种地址列表更新方法、地址列表更新装置、计算机可读介质以及电子设备。
背景技术
服务消费方和服务提供方之间通过网络来传输通信数据。当服务消费方向服务提供方发起请求时,必须先知道服务提供方的地址列表。
如果在一段时间内连续推送了多个服务提供方的网络地址的地址列表,服务消费方的刷新线程会按照推送顺序逐次更新本地缓存的地址列表。这种方式不仅导致本地缓存中的地址列表滞后且不准确,还会导致刷新线程长期处于忙碌状态,提高了刷新线程的负载,并不适用于高可用场景中。
鉴于此,本领域亟需开发一种新的地址列表更新方法。
需要说明的是,在上述背景技术部分公开的信息仅用于加强对本申请的背景的理解,因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
本公开的目的在于提供一种地址列表更新方法、地址列表更新装置、计算机可读介质以及电子设备,进而至少在一定程度上克服地址列表更新频繁且最新地址列表更新滞后等技术问题。
本公开的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本公开的实践而习得。
根据本公开实施例的一个方面,提供一种地址列表更新方法,该方法包括:依次接收对应于服务提供方的待处理的地址列表;根据所述地址列表的接收次序确定当前待处理的最新地址列表;通过地址刷新线程读取所述最新地址列表,并按照所述最新地址列表更新本地存储的所述服务提供方的可用地址列表。
根据本公开实施例的一个方面,提供一种地址列表更新装置,该装置包括:列表接收模块,被配置为依次接收对应于服务提供方的待处理的地址列表;列表确定模块,被配置为根据所述地址列表的接收次序确定当前待处理的最新地址列表;列表更新模块,被配置为通过地址刷新线程读取所述最新地址列表,并按照所述最新地址列表更新本地存储的所述服务提供方的可用地址列表。
在本公开的一些实施例中,基于以上技术方案,所述列表更新模块包括:列表存储单元,被配置为将所述最新地址列表存储在与地址刷新线程对应的待读取的地址副本中;列表读取单元,被配置为当所述地址刷新线程为就绪状态时,通过所述地址刷新线程从所述地址副本中读取所述最新地址列表。
在本公开的一些实施例中,基于以上技术方案,所述列表存储单元包括:队列确定子单元,被配置为确定与地址刷新线程对应的任务阻塞队列,并生成与所述最新地址列表对应的任务;任务提交子单元,被配置为将所述任务提交到所述任务阻塞队列中,并将所述最新地址列表存储在与所述地址刷新线程对应的待读取的地址副本中。
在本公开的一些实施例中,基于以上技术方案,所述列表读取单元包括:队列比较子单元,被配置为获取所述任务阻塞队列的队列长度和所述任务阻塞队列的队列容量,并确定所述队列长度和所述队列容量的队列比较结果;结果确定子单元,被配置为当所述队列比较结果为所述队列长度等于所述队列容量时,通过所述地址刷新线程从所述地址副本中读取所述最新地址列表。
在本公开的一些实施例中,基于以上技术方案,所述队列容量为1,所述列表读取单元包括:长度比较子单元,被配置为获取所述任务阻塞队列的队列长度,并确定所述队列长度和1的长度比较结果;长度结果子单元,被配置为当所述长度比较结果为所述队列长度等于1时,通过所述地址刷新线程从所述地址副本中读取所述最新地址列表。
在本公开的一些实施例中,基于以上技术方案,所述地址列表更新装置还包括:任务提交模块,被配置为将所述任务提交到所述任务阻塞队列中,并确定所述队列长度和所述队列容量的队列比较结果;任务丢弃模块,被配置为当所述队列比较结果为所述队列长度等于所述队列容量时,丢弃所述任务;任务保存模块,被配置为当所述队列比较结果为所述队列长度小于所述队列容量时,在所述任务阻塞队列中保存所述任务。
在本公开的一些实施例中,基于以上技术方案,所述列表确定模块包括:标识分配单元,被配置为根据所述地址列表的接收次序向所述地址列表分配对应的列表标识;列表队列单元,被配置为将所述地址列表与所述列表标识存储在与地址刷新线程对应的待读取的列表队列中;标识确定单元,被配置为在所述列表队列中,根据所述列表标识确定当前待处理的最新地址列表。
在本公开的一些实施例中,基于以上技术方案,所述列表更新模块包括:线程就绪单元,被配置为当所述地址刷新线程为就绪状态时,通过所述地址刷新线程从所述列表队列中读取所述最新地址列表;线程运行单元,被配置为当所述地址刷新线程为运行状态时,保持所述地址刷新线程的运行状态。
在本公开的一些实施例中,基于以上技术方案,所述列表标识为版本号,所述版本号是按照递增原则向所述地址列表分配的;所述标识确定单元包括:比较排序子单元,被配置为将所述版本号进行比较,并按照号码比较结果将所述版本号进行排序;排序结果子单元,被配置为根据排序结果确定最大的所述版本号为最新版本号,并确定与所述最新版本号对应的地址列表为当前待处理的最新地址列表。
在本公开的一些实施例中,基于以上技术方案,所述地址列表更新装置还包括:过期确定模块,被配置为将除所述最新版本号之外的所述版本号确定为过期版本号,并确定与所述过期版本号对应的地址列表为过期地址列表,并确定与所述过期版本号对应的地址列表为过期地址列表;列表丢弃模块,被配置为丢弃所述过期版本号与所述过期地址列表,以更新所述列表队列。
在本公开的一些实施例中,基于以上技术方案,所述列表接收模块包括:服务调用单元,被配置为获取待调用的服务的服务标识,并根据所述服务标识发送对应的服务查询请求;请求返回单元,被配置为接收根据服务查询请求依次返回的服务提供方的待处理的地址列表。
在本公开的一些实施例中,基于以上技术方案,所述请求返回单元包括:请求发送子单元,被配置为根据所述服务查询请求确定与所述服务对应的服务提供方,并发送与所述服务提供方对应的消息订阅请求;请求接收子单元,被配置为依次接收与所述消息订阅请求对应的所述服务提供方的待处理的地址列表。
根据本公开实施例的一个方面,提供一种计算机可读介质,其上存储有计算机程序,该计算机程序被处理器执行时实现如以上技术方案中的地址列表更新方法。
根据本公开实施例的一个方面,提供一种电子设备,该电子设备包括:处理器;以及存储器,用于存储所述处理器的可执行指令;其中,所述处理器被配置为经由执行所述可执行指令来执行如以上技术方案中的地址列表更新方法。
在本公开实施例提供的技术方案中,通过地址刷新线程读取在地址列表中确定出的最新地址列表,实现对本地存储的可用地址列表的更新。一方面,减少了地址列表的刷新次数,降低了地址列表的时延,保证了地址列表的实时性和准确性,进一步提高了服务的可用性;另一方面,在地址刷新线程忙碌时,无需频繁刷新地址列表,减少了地址刷新线程负载,提升了地址刷新线程的有效刷新效率。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。显而易见地,下面描述中的附图仅仅是本公开的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。在附图中:
图1示意性示出了在远程过程调用场景中获取地址列表的方法的步骤流程图;
图2示意性示出了一种相关技术中地址列表更新方法的步骤流程示意图;
图3示意性示出了相关技术中的逐次更新地址列表的方法的步骤流程图;
图4示意性地示出了应用本公开技术方案的示例性***架构示意图;
图5示意性地示出了本公开的一些实施例中地址列表更新方法的步骤流程图;
图6示意性地示出了在本公开的一些实施例中接收地址列表的方法的步骤流程图;
图7示意性地示出了在本公开的一些实施例中进一步接收地址列表的方法的步骤流程图;
图8示意性地示出了在本公开的一些实施例中确定最新地址列表的方法的步骤流程图;
图9示意性地示出了在本公开的一些实施例中进一步确定最新地址列表的方法的步骤流程图;
图10示意性地示出了在本公开的一些实施例中更新列表队列的方法的步骤流程图;
图11示意性地示出了在本公开的一些实施例中一种读取最新地址列表的方法的步骤流程图;
图12示意性地示出了在本公开的一些实施例中存储最新地址列表的方法的步骤流程图;
图13示意性地示出了在本公开的一些实施例中确定队列比较结果的方法的步骤流程图;
图14示意性地示出了在本公开的一些实施例中确定长度比较结果的方法的步骤流程图;
图15示意性地示出了在本公开的一些实施例中对任务的处理方法的步骤流程图;
图16示意性地示出了在本公开的一些实施例中另一种读取最新地址列表的方法的步骤流程图;
图17示意性地示出了在本公开的一些实施例中在应用场景下的地址列表更新方法的步骤流程图;
图18示意性地示出了在本公开的一些实施例中第一阶段的地址列表更新方法的步骤流程图;
图19示意性地示出了在本公开的一些实施例中第二阶段的地址列表更新方法的步骤流程图;
图20示意性地示出了在本公开的一些实施例中第三阶段的地址列表更新方法的步骤流程图;
图21示意性地示出了在本公开的一些实施例中第四阶段的地址列表更新方法的步骤流程图;
图22示意性地示出了在本公开的一些实施例中第五阶段的地址列表更新方法的步骤流程图;
图23示意性地示出了在本公开一些实施例中的地址列表更新装置的结构框图;
图24示意性地示出了适于用来实现本公开实施例的电子设备的计算机***的结构示意图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实施方式使得本公开将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。
此外,所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中,提供许多具体细节从而给出对本公开的实施例的充分理解。然而,本领域技术人员将意识到,可以实践本公开的技术方案而没有特定细节中的一个或更多,或者可以采用其它的方法、组元、装置、步骤等。在其它情况下,不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。
附图中所示的方框图仅仅是功能实体,不一定必须与物理上独立的实体相对应。即,可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明,不是必须包括所有的内容和操作/步骤,也不是必须按所描述的顺序执行。例如,有的操作/步骤还可以分解,而有的操作/步骤可以合并或部分合并,因此实际执行的顺序有可能根据实际情况改变。
在本领域的相关技术中,对获取到的地址列表进行更新广泛应用于远程过程调用场景中。图1示出了远程过程调用场景中获取地址列表的方法的步骤流程图,如图1所示,服务提供方、服务消费方与服务注册中心分别部署在不同的服务器上,三者之间的通信数据通过网络进行传输。
其中,服务提供方用于向服务消费方提供服务,具体的,可以向服务注册中心服务和发布服务。服务消费方用于调用服务提供方提供的服务,具体的,向服务注册中心查找所需要的服务。服务注册中心主要负责服务的管理和监控服务的状态,实现服务的注册、存储和推送等。
举例而言,针对患者的资料记录平台,可以调用一“根据姓名获取该患者的其他身份资料”的服务,对应的,服务提供方可以是该资料记录平台的服务器或服务器集群,服务注册中心可以是记录资料记录平台的服务器或服务器集群的地址列表的服务器,服务消费方可以是发起该查询服务请求的终端;针对网上书店***,可以调用一“购买书籍《XXX》”的服务,对应的,服务提供方可以是该网上书店***的服务器或服务器集群,服务注册中心可以是记录网上书店***的服务器或服务器集群的地址列表的服务器,服务消费方可以是发起该购买服务请求的终端;针对视频网站,可以调用一“订阅电视剧的更新提醒消息”的服务,对应的,服务提供方可以是该视频网站的服务器或服务器集群,服务注册中心可以是记录该视频网站的服务器或服务器集群的地址列表的服务器,服务消费方可以是发起该订阅请求的终端。
在步骤S110中,服务提供方向服务注册中心发送服务注册请求,以在服务注册中心注册服务提供方的服务器地址。
在步骤S120中,服务消费方从服务注册中心订阅并获取与服务提供方对应的服务器地址。
在步骤S130中,服务消费方获取到服务器地址,并根据相应的负载均衡策略选择一个服务提供方发送远程过程调用(Remote Produre Call,简称RPC)请求。
在步骤S140中,服务提供方接收到RPC请求之后,可以从RPC请求中提取出请求参数,并进行相应处理。进一步的,向服务消费方返回处理结果。
通过传统的地址列表更新方法总是无法很好地满足服务消费方获取服务提供方的网络地址的需求。通过将服务提供方的网络地址的地址列表提前配置在服务消费方的本地配置中来解决该问题。但是,提前配置的方式使得服务消费方的地址列表不具备动态变更能力。当采用集群多机部署的方式来提供服务时,服务提供方会扩容或者缩容导致服务提供方的地址列表发生变更,但服务消费方的地址列表却无法同步更新。一旦服务消费方按照预先配置的地址列表发起请求,就会出现网络调用错误的结果。
除此之外,图2示出了一种相关技术中地址列表更新方法的步骤流程图,如图2所示,在服务消费方和服务提供方之间增加了服务注册中心来实现解耦。服务消费方并不需要在本地配置服务提供方的地址列表,而是通过服务注册中心动态地获取网络地址的地址列表。服务提供方在启动服务时,向服务注册中心注册对应的服务器的网络地址,服务注册中心可以根据服务名将注册的网络地址归类成地址列表。因此,每个服务都对应有一份服务提供方的地址列表。
在步骤S210中,服务消费方向服务注册中心订阅服务提供方的网络地址的地址列表。
在步骤S220中,服务注册中心向服务消费方返回服务提供方的地址列表。并且,当地址列表有更新时,服务注册中心也会向服务消费方推送更新后的地址列表。
在步骤S230中,当服务消费方接收到返回的地址列表时,为方便对服务提供方发起RPC请求,会将地址列表缓存到本地。
在步骤S240中,启动服务消费方的刷新线程监听服务注册中心的地址变更消息。当服务注册中心的地址列表有更新时,刷新线程会监听到服务注册中心推送的地址列表,并自动将新的地址列表更新到本地缓存。
在步骤S250中,当服务注册中心的地址列表有更新时,服务注册中心会向服务消费方推送新的地址列表。
在步骤S260中,当后续的刷新线程监听到更新的地址列表时,也可以通过更新的地址列表对本地缓存进行更新。
在服务消费方向服务提供方发起RPC请求之前,会先查询本地缓存的地址列表,并根据相应的负载均衡策略选择一个服务提供方实例发送请求。当服务提供方接收到远程过程调用请求后,可以提取出RPC请求的请求参数,以进行相应的处理向服务消费方返回处理结果。
可以看出,服务消费方的刷新线程监听到有新的地址列表时,是同步阻塞地进行更新的,亦即刷新线程会按照接收顺序逐次更新本地缓存的地址列表。
图3示出了相关技术中逐次更新地址列表的方法的步骤流程图,如图3所示,在步骤S310中,服务注册中心在一段时间内频繁地推送了N个地址列表,分别是地址列表1、地址列表2、……、地址列表N。
在步骤S320中,服务消费方的服务地址***监听到地址列表1、地址列表2、……、地址列表N等N个地址列表。并且,服务消费方的服务地址刷新线程逐个刷新地址列表1、地址列表2、……、地址列表N。
在步骤S330中,服务消费方的服务地址刷新线程将地址列表1刷新到本地缓存中。并且,由于刷新线程处理地址列表1耗时较长,使得地址列表2、……、地址列表N一直阻塞在地址列表1的后面,地址列表2、……、地址列表N都处于阻塞状态。
因此,一方面,在刷新线程一直处理地址列表1的过程中,会导致最新的地址列表N无法及时更新到本地缓存中,导致服务消费方缓存的地址列表滞后;另一方面,即使刷新线程处理完地址列表1,还需要逐次处理地址列表2、地址列表3、……、地址列表N-1,导致地址列表N刷新到本地缓存的时间进一步滞后,无法适用于高可用的场景,除此之外,还会导致刷新线程一直处于忙碌状态,加大刷新线程的负载。
基于以上方案存在的问题,本公开提供了一种地址列表更新方法、地址列表更新装置、计算机可读介质以及电子设备。
优选的,利用云技术对服务提供方的地址列表进行更新,可以减少服务消费方的刷新次数,提高地址列表的刷新效率。
图4示出了应用本公开技术方案的示例性***架构示意图。
如图4所示,***架构400可以包括服务消费方410,服务提供方420服务注册中心430。其中,服务消费方410可以是终端设备中的一个或多个,也可以部署在服务器上,服务提供方420和服务注册中心430分别部署在不同的服务器上。服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式***,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等,但并不局限于此。终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接,本申请在此不做限制。
应该理解,图4中的服务器的数目仅仅是示意性的,可以用独立的服务器,也可以用多个服务器组成的服务器集群,还可以用一个云计算服务中心来实现。
具体的,服务消费方410可以是某个应用,假设该应用的执行需要调用一个服务,而服务提供方420可以是服务器集群,该服务器集群用于提供该服务,而服务器集群中的任意一台服务器440可以调用该服务。服务提供方420中的服务器440调用该服务的服务器可以反馈服务调用结果至服务消费方410,使得服务消费方410可以根据调用结果继续执行应用。
除此之外,在本申请中还使用了服务注册中心430。采用服务消费方410在进行服务调用时,服务注册中心430直接与作为服务提供方420中的服务器440进行点对点的通讯,服务注册中心430用于向服务消费方410提供服务的服务器的地址列表,使得服务消费方410能够从地址列表中选择一个服务器进行服务调用。
服务注册中心430根据服务提供方440发送的服务注册请求,可以记录服务标识与地址列表的对应关系。例如,服务提供方420是对应一种服务的集群,该集群中的所有服务器都能够提供这种服务,那么当服务提供方420中的服务器向服务注册中心430注册服务时,服务注册中心430可以确定服务提供方420中的服务器都对应同一服务,可以记录该服务的服务名与服务提供方420中的各个服务器的网络地址之间的对应关系。按照同样的原理,服务注册中心430可以分别注册不同服务的服务名与提供该服务的服务器的网络地址的对应关系。因此,对应于同一服务名的各个服务器的网络地址可以组成对应该服务名的网络地址的地址列表。进一步的,一个服务名和对应的地址列表可以具有对应关系。
服务注册中心430保存的是与服务名对应的地址列表,该地址列表是当前能够正常提供与服务名对应服务的网络地址的列表。如果该地址列表中的部分服务器发生故障不可用,或者服务提供方的服务器数量过多要进行缩容,服务注册中心430可以将这部分服务器的网络地址从地址列表中删除。当故障的服务器恢复正常工作,或者服务提供方的调用数量较大需要扩容时,服务注册中心430可以将这部分服务提供方的网络地址添加到地址列表中。为了实现地址列表的刷新,服务注册中心430要和服务提供方420中的各个服务器之间保持状态监测和通知,以使得服务注册中心430能够及时获知服务提供方420中的服务器的状态,以通知给服务消费方410。
服务消费方410在调用服务时,可以向服务注册中心430请求该服务的服务名对应的服务器的地址列表,该请求中携带有要调用的服务的服务名。而服务注册中心430可以根据服务名查找对应关系得到对应的地址列表,并将地址列表反馈给服务消费方410。
服务消费方410获取服务器列表的方式可以是主动获取的,例如在需要调用服务时获取,或者定期同步该服务消费方410要调用服务的地址列表;也可以是被动获取的,服务注册中心430可以将地址列表主动推送至服务消费方410。例如当地址列表更新时,服务注册中心430可以将更新后的地址列表发送至服务消费方410,防止由于更新滞后导致被调用的服务器不可用的情况的发生。
本公开实施例所提供的地址列表更新方法一般由服务消费方410执行,相应地,地址列表更新装置一般设置于服务器410中。但本领域技术人员容易理解的是,本公开实施例所提供的地址列表更新方法也可以由服务提供方420或者服务注册中心430执行,相应的,地址列表更新装置也可以设置于服务提供方420或者服务注册中心430中,本示例性实施例中对此不做特殊限定。
举例而言,在一种示例性实施例中,可以是从服务注册中心430中依次接收对应于服务提供方420的待处理的地址列表。并且,根据地址列表的接收次序确定当前待处理的最新地址列表。通过服务消费方410中的地址刷新线程读取最新地址列表,并按照最新地址列表更新服务消费方410的本地存储的服务提供方420的可用地址列表,以便于服务消费方410根据可用地址列表进行服务调用。
下面结合具体实施方式对本公开提供的地址列表更新方法、地址列表更新装置以及电子设备做出详细说明。
图5示意性地示出了本公开的一些实施例中地址列表更新方法的步骤流程图。如图5所示,地址列表更新方法主要可以包括以下步骤:
步骤S510.依次接收对应于服务提供方的待处理的地址列表。
步骤S520.根据地址列表的接收次序确定当前待处理的最新地址列表。
步骤S530.通过地址刷新线程读取最新地址列表,并按照最新地址列表更新本地存储的服务提供方的可用地址列表。
在本公开的示例性实施例中,通过地址刷新线程读取在地址列表中确定出的最新地址列表,实现对本地存储的可用地址列表的更新。一方面,减少了地址列表的刷新次数,降低了地址列表的时延,保证了地址列表的实时性和准确性,进一步提高了服务的可用性;另一方面,在地址刷新线程忙碌时,无需频繁刷新地址列表,减少了地址刷新线程负载,提升了地址刷新线程的有效刷新效率。
下面对地址列表更新方法的各个步骤进行详细说明。
在步骤S510中,依次接收对应于服务提供方的待处理的地址列表。
在本公开的示例性实施例中,大型复杂业务***一般可以实现多个业务,每个业务的实现可能需要调用多个不同的应用,由此导致业务访问量很难预知。为了保证服务***不被海量访问压垮,又能保证较高的资源利用率,传统的应用都开始向云服务器上迁移,除了运行环境会采用云主机之外,一般的技术架构都遵从分布式无状态架构实现云上应用的弹性伸缩。
在分布式数据处理中,服务消费方和服务提供方之间使用远程过程调用(RemoteProcedure Call,简称RPC)进行通讯。RPC是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的调用方式。RPC协议可以假定某些传输协议的存在,例如传输控制协议(Transmission Control Protocol,简称TCP)或者用户数据报协议(User Datagram Protocol,简称UDP)等传输协议,为通信程序之间携带信息数据。在开放式***互联(Open System Interconnection,简称OSI)网络通信模型中,RPC超越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
分布式服务框架(Distribute Service Framework,简称DSP)是对RPC框架的进一步封装,RPC一般仅能解决两个进程之间的点对点远程通信,而DSP框架除了点对点的远程通信框架之外,还同时引入了独立的服务注册中心,实现帮助服务提供方实现在服务注册中心进行注册,支持服务消费方从服务注册中心访问地址列表的功能。
当服务注册中心向服务消费方推送服务提供方的地址列表时,服务消费方会接收该地址列表。其中,该地址列表可以是网络地址的地址列表,优选的,该网络地址为网际互连协议(Internet Protocol,简称IP)地址。IP地址是整个传输控制协议(TransmissionControl Protocol,简称TCP)/IP协议族的核心,也是构成互联网的基础。IP位于TCP/IP模型的网络层,对上可载送传输层各种协议的信息,例如TCP、UDP等;对下可将IP信息包放到链路层,通过以太网、令牌环网络等各种技术来传送。一方面可以解决互联网问题,实现大规模、异构网络的互联互通;另一方面,可以分割顶层网络应用和底层网络技术之间的耦合关系,以利于两者的独立发展。
在可选的实施例中,图6示出了接收地址列表的方法的步骤流程图,如图6所示,该方法至少包括以下步骤:在步骤S610中,获取待调用的服务的服务标识,并根据服务标识发送对应的服务查询请求。其中,该服务标识可以是服务消费方要调用的服务的服务名。举例而言,针对患者的资料记录平台,该服务可以是“根据姓名获取该患者的其他身份资料”,对应的服务名为“查询”;针对网上书店***,当用户欲购买一本书籍,该服务可以是“购买书籍《XXX》”,对应的服务名可以为“购买”;针对视频网站对应的服务账号,当用户请求订阅某个电视剧的更新提醒消息时,该服务可以是“订阅电视剧《XX》的更新消息”,对应的服务名可以是“订阅”。在确定服务名之后,可以向服务注册中心发送对应于该服务名的服务查询请求。该服务查询请求中携带服务消费方的标识和服务名。其中,服务消费方的标识用于唯一标识发起该服务查询请求的服务消费方,该服务名用于在服务注册中心中确定所要查询服务对应的服务提供方的地址列表。
在步骤S620中,接收根据服务查询请求依次返回的服务提供方的待处理的地址列表。服务注册中心接受到服务查询请求之后,可以将包括服务名和地址列表的对应关系返回给服务消费方。
在可选的实施例中,图7示出了进一步接收地址列表的方法的步骤流程图,如图7所示,该方法至少包括以下步骤:在步骤S710中,根据服务查询请求确定与服务对应的服务提供方,并发送与服务提供方对应的消息订阅请求。当接受到服务查询请求之后,可以根据地址列表确定服务提供方。进一步的,服务消费方会向已确定的服务提供方发送消息订阅请求。该消息订阅请求携带服务消费方的标识以及该服务与地址列表之间的对应关系。其中,服务消费方的标识用于唯一标识发起该消息订阅请求的服务消费方,该对应关系用于根据服务预定对应的地址列表。
在步骤S720中,依次接收与消息订阅请求对应的服务提供方的待处理的地址列表。当服务注册中心接收到消息订阅请求之后,会根据与该服务对应的服务提供方的服务器的更新情况向服务消费方返回地址列表。由于服务消费方的地址列表是实时更新的,因此,可能会响应于不同时刻的消息订阅请求返回多个服务提供方的地址列表。并且,由于这些地址列表是实时返回的,因此,这些地址列表也都是未保存在服务消费方本地的待处理的地址列表。
在本示例性实施例中,通过服务标识可以在服务注册中心查询到与服务对应的服务提供方的地址列表,从而实现了服务消费方的消息订阅,使提升消息处理的准确性、实用性和灵活性。
在步骤S520中,根据地址列表的接收次序确定当前待处理的最新地址列表。
在本公开的示例性实施例中,当服务消费方接收到返回的服务提供方的地址列表时,同时会确定接收到地址列表的次序,以进一步确定最新地址列表。
在可选的实施例中,图8示出了确定最新地址列表的方法的步骤流程图,如图8所示,该方法至少包括以下步骤:在步骤S810中,根据地址列表的接收次序向地址列表分配对应的列表标识。其中,地址列表的接收次序可以是接收到地址列表的时间顺序,列表标识可以是唯一识别地址列表的标识信息,例如地址列表对应的版本号等。举例而言,接收到地址列表的时间越早,就向该地址列表分配一个数值较小的列表标识,例如是较小的版本号;接收到地址列表的时间越晚,就向该地址列表分配一个数值较小的列表标识,例如较大的版本号。除此之外,还可以有其他列表标识或其他分配方式,本示例性实施例对此不做特殊限定。
在步骤S820中,将地址列表与列表标识存储在与地址刷新线程对应的待读取的列表队列中。在确定与地址列表对应的列表标识之后,可以在二者之间建立映射关系,以便于共同存储。具体的,可以将地址列表和列表标识存储在列表队列当中。
其中,列表队列是一种存储地址列表和列表标识的线性表。列表队列的数据元素可以有地址列表和列表标识。当向列表队列中进行存储时,该列表队列只允许在列表队列的前端进行删除操作,而在列表队列的后端进行***操作,亦即存储操作。因此,该列表队列是一种先进先出的线性表。并且,该列表队列与地址刷新线程之间具有对应关系。该地址刷新线程可以实现对列表队列中的地址列表的读取和刷新,以更新服务消费方的本地缓存。
在步骤S830中,在列表队列中,根据列表标识确定当前待处理的最新地址列表。当在列表队列中存储多个地址列表和列表标识之后,可以根据列表标识确定出多个地址列表中的最新地址列表,以便于地址刷新线程进行刷新。
在可选的实施例中,列表标识为版本号,版本号是按照递增原则向地址列表分配的,图9示出了进一步确定最新地址列表的方法的步骤流程图,如图9所示,该方法至少包括以下步骤:在步骤S910中,将版本号进行比较,并按照号码比较结果将版本号进行排序。其中,版本号可以是根据接收到地址列表的时间,并按照递增原则向地址列表分配的。具体的,第一个接收到的地址列表的接收时间最早,向该地址列表分配的版本号可以为1;第二个接收到的地址列表的版本号可以以第一个地址列表的版本号为基础,并以1为增长步长,确定为2;第三个接收到的地址列表的版本号可以以第二个地址列表的版本号为基础,并以1为增长步长,确定为3;……;以此类推。除此之外,版本号也可以是其他形式,本示例性实施例对此不做特殊限定。
在向每个地址列表分配版本号之后,鉴于版本号之间有数值大小的区别,可以比较各个版本号之间的大小以得到号码比较结果。根据该号码比较结果可以将版本号进行排序,排序方式可以是降序,也可以是升序,本示例性实施例对此不做特殊限定。
在步骤S920中,根据排序结果确定最大的版本号为最新版本号,并确定与最新版本号对应的地址列表为当前待处理的最新地址列表。当排序结果是将版本号按照降序排列时,可以将第一个版本号确定为最新版本号;当排序结果是将版本号按照升序排列时,可以将最后一个版本号确定为最新版本号。进一步的,根据版本号与地址列表之间的映射关系,可以确定与最新版本号对应的地址列表为最新地址列表。并且,该最新地址列表尚未保存在服务消费方的本地,因此是当前待处理的地址列表。
在本公开的示例性实施例中,当列表标识为版本号时,通过版本号的比较结果可以确定最新地址列表,确定方式准确且简单,实用性极强。
在确定最新地址列表之后,还可以根据版本号确定列表队列中的其他地址列表,以进行进一步的操作更新列表队列。
在可选的实施例中,图10示出了更新列表队列的方法的步骤流程图,如图10所示,该方法至少包括以下步骤:在步骤S1010中,将除最新版本号之外的版本号确定为过期版本号,并确定与过期版本号对应的地址列表为过期地址列表。在确定最新版本号之后,列表队列中存储的版本号就包括两部分,分别为最新版本号和除最新版本号之外的其他版本号。这部分其他版本号是小于最新版本号的,表明这部分版本号对应的地址列表的接收时间早于最新地址列表的接收时间。在确定最新地址列表之后,表明这部分地址列表已经过期,无需刷新。因此,将除最新版本号之外的其他版本号确定为过期版本号,并根据版本号与地址列表之间的映射关系,将与过期版本号对应的地址列表确定为过期地址列表。
在步骤S1020中,丢弃过期版本号与过期地址列表,以更新列表队列。在确定过期版本号和过期地址列表之后,可以直接丢弃过期版本号和过期地址列表。因此,列表队列中仅保存有最新版本号和最新地址列表,实现了对列表队列的更新。
在本示例性实施例中,通过将确定出的过期版本号和过期地址列表进行丢弃,节省了列表队列中的存储空间,为减少刷新次数提供了数据基础。
在步骤S530中,通过地址刷新线程读取最新地址列表,并按照最新地址列表更新本地存储的服务提供方的可用地址列表。
在本公开的示例性实施例中,当确定最新地址列表之后,可以根据地址刷新线程读取最新地址列表。其中,该地址刷新线程可以监听最新地址列表,并实现对最新地址列表的读取和刷新,以更新服务消费方本地缓存的可用地址列表。
图11和图16中分别示出了两种读取最新地址列表的方法的步骤流程图。其中,图11是根据任务阻塞队列的标识信息从地址副本中读取的,图16是在从存储有最新地址列表和最新列表标识的列表队列中读取的。
在可选的实施例中,图11示出了一种读取最新地址列表的方法的步骤流程图,如图11所示,该方法至少包括以下步骤:在步骤S1110中,将最新地址列表存储在与地址刷新线程对应的待读取的地址副本中。其中,该地址副本是服务消费方的本地的内存缓冲区,用于保存最新地址列表。并且,该地址副本与地址刷新线程之间具有对应关系。因此,在地址刷新线程刷新最新地址列表之前,可以将最新地址列表存储在地址副本中,以作后续读取准备。
在可选的实施例中,图12示出了存储最新地址列表的方法的步骤流程图,如图12所示,该方法至少包括以下步骤:在步骤S1210中,确定与地址刷新线程对应的任务阻塞队列,并生成与最新地址列表对应的任务。其中,任务阻塞队列是加载任务的队列,相当于一个存储空间,用于缓存任务。因此,当要存储最新地址列表时,可以生成一个与最新地址列表对应的任务,以表明地址副本中存储有最新地址列表。并且,由于任务阻塞队列与地址刷新线程之间具有对应关系,同时也可以标识地址刷新线程需要对该最新地址列表进行刷新。
在步骤S1220中,将任务提交到所述任务阻塞队列中,并将最新地址列表存储在与地址刷新线程对应的待读取的地址副本中。任务阻塞队列接收到任务时,可以丢弃该任务,也可以保存该任务。值得说明的是,任务阻塞队列对任务的操作并不会影响最新地址列表的存储。因此,在任务提交之后,可以将最新地址列表存储在地址副本中。
在本示例性实施例中,通过确定的任务阻塞队列可以为地址刷新线程提供刷新信号,避免地址刷新线程长期处于忙碌状态,增加地址刷新线程的负载。
在步骤S1120中,当地址刷新线程为就绪状态时,通过地址刷新线程从地址副本中读取最新地址列表。新创建的地址刷新线程并不是自动开始运行的,必须调用地址刷新线程的start()方法。当地址刷新线程调用start()方法时,表明启动了地址刷新线程,start()方法可以创建地址刷新线程运行的***资源,并调度地址刷新线程运行run()方法。当start()方法返回后,地址刷新线程就处于就绪状态。
除此之外,当地址刷新线程处理完上一个最新地址列表之后,也可以判定该地址刷新线程处于就绪状态。
当确定地址刷新线程为就绪状态时,可以获得中央处理器(central processingunit,简称CPU)时间运行该地址刷新线程。因此,该地址刷新线程可以从地址副本中读取最新地址列表。
在可选的实施例中,图13示出了确定队列比较结果的方法的步骤流程图,如图13所示,该方法至少包括以下步骤:在步骤S1310中,获取任务阻塞队列的队列长度和任务阻塞队列的队列容量,并确定队列长度和队列容量的队列比较结果。在将最新地址列表保存在地址副本之后,可以根据任务阻塞队列判定是否读取该最新地址列表。具体的,通过比较任务阻塞队列的队列长度和队列容量进行确定。
其中,任务阻塞队列的队列容量是预设的可以保存任务的数量,例如1、2等。对应的,当队列容量为1时,任务阻塞队列可以保存1个任务;当队列容量为2时,任务阻塞队列可以保存2个任务,本示例性实施例对此不做特殊限定。队列长度可以是任务阻塞队列当前保存的任务的数量,例如0、1、2等。对应的,当队列长度为0时,任务阻塞队列当前未保存任务;当队列长度为1时,任务阻塞队列当前保存1个任务;当队列长度为2时,任务阻塞队列当前保存2个任务。
将队列长度与队列容量进行比较,可以得到队列比较结果。具体的,队列比较结果可以是队列长度等于队列容量,也可以是队列长度小于队列容量两种情况。
在步骤S1320中,当队列比较结果为队列长度等于队列容量时,通过地址刷新线程从地址副本中读取最新地址列表。根据队列比较结果确定队列长度等于队列容量时,表明地址副本中存储有最新地址列表,地址刷新线程可以在地址副本中读取该最新地址列表。
在本示例性实施例中,通过队列容量和队列长度的比较可以判断是否读取最新地址列表,判断方式简单,并且为地址刷新线程提供了准确的读取信号,为地址列表更新提供了基础。
更为具体的,可以预设队列容量为1,以根据已知的队列容量确定是否读取最新地址列表。
在可选的实施例中,队列容量为1,图14示出了确定长度比较结果的方法的步骤流程图,如图14所示,该方法至少包括以下步骤:在步骤S1410中,获取任务阻塞队列的队列长度,并确定队列长度和1的长度比较结果。当队列容量已知为1时,只需获取任务阻塞队列的队列长度。该队列长度只存在等于0和等于1的两种情况。进一步的,将这两种情况的队列长度与1进行比较即可。
将队列长度与队列容量进行比较,可以得到队列比较结果。具体的,队列比较结果可以是队列长度为1时,队列长度等于队列容量;也可以是队列长度为0时,队列长度小于队列容量两种情况。
在步骤S1420中,当长度比较结果为队列长度等于1时,通过地址刷新线程从地址副本中读取最新地址列表。当已知队列容量为1时,只需将队列长度与1进行比较。若队列长度也为1,表明地址副本中存储有最新地址列表,地址刷新线程可以在地址副本中读取该最新地址列表。
在本示例性实施例中,通过队列容量为1的任务阻塞队列可以判断是否读取最新地址列表,判断方式简单,并且为地址刷新线程提供了准确的读取信号,为地址列表更新提供了基础。
在确定任务阻塞队列的队列长度和队列容量之后,还可以为任务阻塞队列接收到任务时,选择丢弃还是保存提供判定基础。
在可选的实施例中,图15示出了对任务的处理方法的步骤流程图,如图15所示,该方法至少包括以下步骤:在步骤S1510中,将任务提交到任务阻塞队列中,并确定队列长度和队列容量的队列比较结果。当任务阻塞队列接收到任务后,可以获取任务阻塞队列的队列比较结果。具体的,队列比较结果可以是队列长度等于队列容量,也可以是队列长度小于队列容量两种情况。
在步骤S1520中,当队列比较结果为队列长度等于队列容量时,丢弃任务。由于队列容量是任务阻塞队列可以保存任务的最大数量,因此,当队列长度等于队列容量时,表明任务阻塞队列已无法保存其他任务,可以选择丢弃该任务。
在步骤S1530中,当队列比较结果为队列长度小于队列容量时,在任务阻塞队列中保存任务。由于队列容量是任务阻塞队列可以保存任务的最大数量,因此,当队列长度小于队列容量时,表明任务阻塞队列还可以保存任务,可以选择接收该任务,并保存在任务阻塞队列中。
在本示例性实施例中,通过队列比较结果可以确定对提交的任务的处理方法,无需增加其他判定方式,减少任务处理操作的工作量,提升任务处理的效率。
在可选的实施例中,图16示出了另一种读取最新地址列表的方法的步骤流程图,如图16所示,该方法至少包括以下步骤:在步骤S1610中,当地址刷新线程为就绪状态时,通过地址刷新线程从列表队列中读取最新地址列表。当确定地址刷新线程为就绪状态时,可以获得中央处理器CPU时间运行该地址刷新线程。因此,该地址刷新线程可以从队列列表中读取最新地址列表。并且,可以根据实际需求丢弃与最新地址列表对应的最新列表标识,也可以选择一同读取最新列表标识,本示例性实施例对此不做特殊限定。
在步骤S1620中,当地址刷新线程为运行状态时,保持地址刷新线程的运行状态。若地址刷新线程开始执行run()方法,表明地址刷新线程处于运行状态。该运行状态表明地址刷新线程在刷新上一最新地址列表,因此,只需保持地址刷新线程的运行状态继续对上一最新地址列表进行刷新即可。
在本示例性实施例中,通过对地址刷新线程的状态判断实现读取最新地址列表的功能,确保地址刷新线程仅刷新最新地址列表,无需对其他地址列表进行操作,保证了最新地址列表的准确性和实时性,适用于高可用的场景。
在读取到最新地址列表之后,可以通过地址刷新线程的刷新操作实现最新地址列表对可用地址列表的覆盖,以更新服务消费方本地存储的可用地址列表。
下面结合一具体应用场景对本公开实施例中提供的地址列表更新方法做出详细说明。
图17示出了应用场景下的地址列表更新方法的步骤流程图,如图17所示,在步骤S1710中,服务注册中心根据服务消费方发送的服务查询请求可以推送地址列表。该地址列表可以包括地址列表1、地址列表2、……、地址列表N等N个地址列表。通过服务消费方注册的服务地址***对地址列表进行监听。
在步骤S1720中,当服务地址***监听到地址列表时,会向任务阻塞队列中提交一个任务。值得说明的是,该任务阻塞队列的队列容量为1。因此,只有当任务阻塞队列的队列长度为0时,才可以提交任务成功,保存在任务阻塞队列中;当任务阻塞队列的队列长度为1,亦即等于队列容量时,提交的任务会被丢弃。
在步骤S1730中,在向任务阻塞队列中提交任务之后,可以将地址列表写入地址副本中,以覆盖之前存储的地址列表,以此保证地址副本中保存的是最新地址列表。
在步骤S1740中,地址刷新线程可以从任务阻塞队列中拉取任务,以判定是否读取地址副本中的最新地址列表。当任务阻塞队列的队列长度为0时,表明该任务阻塞队列中没有保存任务,处于阻塞状态。当任务阻塞队列的队列长度为1时,地址刷新线程会从队列中取出任务,并将队列长度调整为0。
在步骤S1750中,当地址刷新线程取出任务之后,可以从地址副本中读取最新地址列表。
在步骤S1760中,在读取完最新地址列表之后,可以通过刷新操作实现最新地址列表覆盖本地存储的可用地址列表的功能,以便于服务消费方根据更新后的可用地址列表对服务提供方进行调用。
具体的,以地址列表1、地址列表2、……、地址列表4为例,对地址列表更新方法进行进一步的说明。
图18示出了第一阶段的地址列表更新方法的步骤流程图,如图18所示,地址刷新线程从任务阻塞队列中取出地址列表1提交的任务,并已从地址副本中读取到地址列表1,正在按照地址列表1更新可用地址列表。为说明后续地址列表的处理方式,假设通过地址刷新线程对地址列表1的刷新过程耗时较长,刷新线程一直处于运行状态。此时,由于已从任务阻塞队列中拉取过地址列表1对应的任务,因此任务阻塞队列的长度为0。并且,地址副本中仍存储地址列表1。
图19示出了第二阶段的地址列表更新方法的步骤流程图,如图19所示,地址列表2被推送过来,会向任务阻塞队列中提交与地址列表2对应的任务,同时将地址列表2写入地址副本中,以覆盖地址副本中原本存储的地址列表1。此时,任务阻塞队列的队列长度由0更新为1,地址副本中更新为地址列表2。并且,地址刷新线程仍在处理地址列表1。
图20示出了第三阶段的地址列表更新方法的步骤流程图,如图20所示,地址列表3被推送过来,会向任务阻塞队列中提交与地址列表3对应的任务。但是,由于任务阻塞队列中已经保存与地址列表2对应的任务,因此此时长度为1,无法保存与地址列表3对应的任务,该任务被丢弃。而地址副本中的地址列表2被地址列表3覆盖,地址副本中此时仅保存有地址列表3。并且,地址刷新线程仍在处理地址列表1。
图21示出了第四阶段的地址列表更新方法的步骤流程图,如图21所示,在地址列表4被推动过来后,由于地址刷新线程一直处于处理地址列表1的阻塞状态,并不会重新去任务阻塞队列中取出任务,因此,地址列表4和地址列表3的处理方式一样,提交的与地址列表4对应的任务会被丢弃,而将地址副本中的地址列表3替换为地址列表4。
图22示出了第五阶段的地址列表更新方法的步骤流程图,如图22所示,地址刷新线程此时处理完地址列表1。因此,地址刷新线程会重新从任务阻塞队列中拉取任务。由于任务阻塞队列保存有之前提交的任务,队列长度为1,因此,地址刷新线程会获取到该任务,并从地址副本中读取到地址列表4,并刷新地址列表4以更新到可用地址列表中。因此,可以地址列表中最终保存的是地址列表4,且仅刷新了地址列表4。
基于以上应用场景可知,本公开实施例提供的地址列表更新方法通过地址刷新线程读取在地址列表中确定出的最新地址列表,实现对本地存储的可用地址列表的更新。一方面,减少了地址列表的刷新次数,降低了地址列表的时延,保证了地址列表的实时性和准确性,进一步提高了服务的可用性;另一方面,在地址刷新线程忙碌时,无需频繁刷新地址列表,减少了地址刷新线程负载,提升了地址刷新线程的有效刷新效率。
应当注意,尽管在附图中以特定顺序描述了本公开中方法的各个步骤,但是,这并非要求或者暗示必须按照该特定顺序来执行这些步骤,或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的,可以省略某些步骤,将多个步骤合并为一个步骤执行,以及/或者将一个步骤分解为多个步骤执行等。
以下介绍本公开的装置实施例,可以用于执行本公开上述实施例中的地址列表更新方法。对于本公开装置实施例中未披露的细节,请参照本公开上述的地址列表更新方法的实施例。
图23示意性地示出了在本公开一些实施例中的地址列表更新装置的结构框图。如图23所示,地址列表更新装置2300主要可以包括:列表接收模块2310、列表确定模块2320和列表更新模块2330。
列表接收模块2310,被配置为依次接收对应于服务提供方的待处理的地址列表;列表确定模块2320,被配置为根据地址列表的接收次序确定当前待处理的最新地址列表;列表更新模块2330,被配置为通过地址刷新线程读取最新地址列表,并按照最新地址列表更新本地存储的服务提供方的可用地址列表。
在本公开的一些实施例中,列表更新模块包括:列表存储单元,被配置为将最新地址列表存储在与地址刷新线程对应的待读取的地址副本中;列表读取单元,被配置为当地址刷新线程为就绪状态时,通过地址刷新线程从地址副本中读取最新地址列表。
在本公开的一些实施例中,列表存储单元包括:队列确定子单元,被配置为确定与地址刷新线程对应的任务阻塞队列,并生成与最新地址列表对应的任务;任务提交子单元,被配置为将任务提交到所述任务阻塞队列中,并将最新地址列表存储在与地址刷新线程对应的待读取的地址副本中。
在本公开的一些实施例中,列表读取单元包括:队列比较子单元,被配置为获取任务阻塞队列的队列长度和任务阻塞队列的队列容量,并确定队列长度和队列容量的队列比较结果;结果确定子单元,被配置为当队列比较结果为队列长度等于队列容量时,通过地址刷新线程从地址副本中读取最新地址列表。
在本公开的一些实施例中,队列容量为1,列表读取单元包括:长度比较子单元,被配置为获取任务阻塞队列的队列长度,并确定队列长度和1的长度比较结果;长度结果子单元,被配置为当长度比较结果为所述队列长度等于一时,通过地址刷新线程从地址副本中读取最新地址列表。
在本公开的一些实施例中,地址列表更新装置还包括:任务提交模块,被配置为将任务提交到任务阻塞队列中,并确定队列长度和队列容量的队列比较结果;任务丢弃模块,被配置为当队列比较结果为队列长度等于队列容量时,丢弃任务;任务保存模块,被配置为当队列比较结果为队列长度小于队列容量时,在任务阻塞队列中保存任务。
在本公开的一些实施例中,列表确定模块包括:标识分配单元,被配置为根据地址列表的接收次序向地址列表分配对应的列表标识;列表队列单元,被配置为将地址列表与列表标识存储在与地址刷新线程对应的待读取的列表队列中;标识确定单元,被配置为在列表队列中,根据列表标识确定当前待处理的最新地址列表。
在本公开的一些实施例中,列表更新模块包括:线程就绪单元,被配置为当地址刷新线程为就绪状态时,通过地址刷新线程从列表队列中读取最新地址列表;线程运行单元,被配置为当地址刷新线程为运行状态时,保持地址刷新线程的运行状态。
在本公开的一些实施例中,列表标识为版本号,版本号是按照递增原则向地址列表分配的;标识确定单元包括:比较排序子单元,被配置为将版本号进行比较,并按照号码比较结果将版本号进行排序;排序结果子单元,被配置为根据排序结果确定最大的版本号为最新版本号,并确定与最新版本号对应的地址列表为当前待处理的最新地址列表。
在本公开的一些实施例中,地址列表更新装置还包括:过期确定模块,被配置为确定除最新版本号之外的版本号为过期版本号,并确定与过期版本号对应的地址列表为过期地址列表;列表丢弃模块,被配置为丢弃过期版本号与过期地址列表,以更新列表队列。
在本公开的一些实施例中,列表接收模块包括:服务调用单元,被配置为获取待调用的服务的服务标识,并根据服务标识发送对应的服务查询请求;请求返回单元,被配置为接收根据服务查询请求依次返回的服务提供方的待处理的地址列表。
在本公开的一些实施例中,请求返回单元包括:请求发送子单元,被配置为根据服务查询请求确定与服务对应的服务提供方,并发送与服务提供方对应的消息订阅请求;请求接收子单元,被配置为依次接收与消息订阅请求对应的服务提供方的待处理的地址列表。
本公开各实施例中提供的地址列表更新装置的具体细节已经在对应的方法实施例中进行了详细的描述,因此此处不再赘述。
图24示出了适于用来实现本公开实施例的电子设备的计算机***的结构示意图。
需要说明的是,图24示出的电子设备的计算机***2400仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
如图24所示,计算机***2400包括中央处理单元(Central Processing Unit,CPU)2401,其可以根据存储在只读存储器(Read-Only Memory,ROM)2402中的程序或者从存储部分2408加载到随机访问存储器(Random Access Memory,RAM)2403中的程序而执行各种适当的动作和处理。在RAM 2403中,还存储有***操作所需的各种程序和数据。CPU2401、ROM 2402以及RAM 2403通过总线2404彼此相连。输入/输出(Input/Output,I/O)接口2405也连接至总线2404。
以下部件连接至I/O接口2405:包括键盘、鼠标等的输入部分2406;包括诸如阴极射线管(Cathode Ray Tube,CRT)、液晶显示器(Liquid Crystal Display,LCD)等以及扬声器等的输出部分2407;包括硬盘等的存储部分2408;以及包括诸如LAN(Local AreaNetwork,局域网)卡、调制解调器等的网络接口卡的通信部分2409。通信部分2409经由诸如因特网的网络执行通信处理。驱动器2410也根据需要连接至I/O接口2405。可拆卸介质2411,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器2410上,以便于从其上读出的计算机程序根据需要被安装入存储部分2408。
特别地,根据本公开的实施例,各个方法流程图中所描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分2409从网络上被下载和安装,和/或从可拆卸介质2411被安装。在该计算机程序被中央处理单元(CPU)2401执行时,执行本申请的***中限定的各种功能。
需要说明的是,本公开实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory,EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory,CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本公开中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、有线等等,或者上述的任意合适的组合。
附图中的流程图和框图,图示了按照本公开各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的***来实现,或者可以用专用硬件与计算机指令的组合来实现。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本公开实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。
应当理解的是,本公开并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (15)

1.一种地址列表更新方法,其特征在于,所述方法包括:
依次接收对应于服务提供方的待处理的地址列表;
根据所述地址列表的接收次序确定当前待处理的最新地址列表;
通过地址刷新线程读取所述最新地址列表,并按照所述最新地址列表更新本地存储的所述服务提供方的可用地址列表。
2.根据权利要求1所述的地址列表更新方法,其特征在于,所述通过地址刷新线程读取所述最新地址列表,包括:
将所述最新地址列表存储在与地址刷新线程对应的待读取的地址副本中;
当所述地址刷新线程为就绪状态时,通过所述地址刷新线程从所述地址副本中读取所述最新地址列表。
3.根据权利要求2所述的地址列表更新方法,其特征在于,所述将所述最新地址列表存储在与地址刷新线程对应的待读取的地址副本中,包括:
确定与地址刷新线程对应的任务阻塞队列,并生成与所述最新地址列表对应的任务;
将所述任务提交到所述任务阻塞队列中,并将所述最新地址列表存储在与所述地址刷新线程对应的待读取的地址副本中。
4.根据权利要求3所述的地址列表更新方法,其特征在于,所述通过所述地址刷新线程从所述地址副本中读取所述最新地址列表,包括:
获取所述任务阻塞队列的队列长度和所述任务阻塞队列的队列容量,并确定所述队列长度和所述队列容量的队列比较结果;
当所述队列比较结果为所述队列长度等于所述队列容量时,通过所述地址刷新线程从所述地址副本中读取所述最新地址列表。
5.根据权利要求4所述的地址列表更新方法,其特征在于,所述队列容量为1;
所述通过所述地址刷新线程从所述地址副本中读取所述最新地址列表,包括:
获取所述任务阻塞队列的队列长度,并确定所述队列长度和1的长度比较结果;
当所述长度比较结果为所述队列长度等于1时,通过所述地址刷新线程从所述地址副本中读取所述最新地址列表。
6.根据权利要求4所述的地址列表更新方法,其特征在于,所述方法还包括:
将所述任务提交到所述任务阻塞队列中,并确定所述队列长度和所述队列容量的队列比较结果;
当所述队列比较结果为所述队列长度等于所述队列容量时,丢弃所述任务;
当所述队列比较结果为所述队列长度小于所述队列容量时,在所述任务阻塞队列中保存所述任务。
7.根据权利要求1所述的地址列表更新方法,其特征在于,所述根据所述地址列表的接收次序确定当前待处理的最新地址列表,包括:
根据所述地址列表的接收次序向所述地址列表分配对应的列表标识;
将所述地址列表与所述列表标识存储在与地址刷新线程对应的待读取的列表队列中;
在所述列表队列中,根据所述列表标识确定当前待处理的最新地址列表。
8.根据权利要求7所述的地址列表更新方法,其特征在于,所述通过地址刷新线程读取所述最新地址列表,包括:
当所述地址刷新线程为就绪状态时,通过所述地址刷新线程从所述列表队列中读取所述最新地址列表;
当所述地址刷新线程为运行状态时,保持所述地址刷新线程的运行状态。
9.根据权利要求7所述的地址列表更新方法,其特征在于,所述列表标识为版本号,所述版本号是按照递增原则向所述地址列表分配的;
所述根据所述列表标识确定当前待处理的最新地址列表,包括:
将所述版本号进行比较,并按照号码比较结果将所述版本号进行排序;
根据排序结果确定最大的所述版本号为最新版本号,并确定与所述最新版本号对应的地址列表为当前待处理的最新地址列表。
10.根据权利要求9所述的地址列表更新方法,其特征在于,在所述根据排序结果确定最大的所述版本号为最新版本号之后,所述方法还包括:
将除所述最新版本号之外的所述版本号确定为过期版本号,并确定与所述过期版本号对应的地址列表为过期地址列表;
丢弃所述过期版本号与所述过期地址列表,以更新所述列表队列。
11.根据权利要求1所述的地址列表更新方法,其特征在于,所述依次接收对应于服务提供方的待处理的地址列表,包括:
获取待调用的服务的服务标识,并根据所述服务标识发送对应的服务查询请求;
接收根据服务查询请求依次返回的服务提供方的待处理的地址列表。
12.根据权利要求11所述的地址列表更新方法,其特征在于,所述接收根据服务查询请求依次返回的服务提供方的待处理的地址列表,包括:
根据所述服务查询请求确定与所述服务对应的服务提供方,并发送与所述服务提供方对应的消息订阅请求;
依次接收与所述消息订阅请求对应的所述服务提供方的待处理的地址列表。
13.一种地址列表更新装置,其特征在于,所述装置包括:
列表接收模块,被配置为依次接收对应于服务提供方的待处理的地址列表;
列表确定模块,被配置为根据所述地址列表的接收次序确定当前待处理的最新地址列表;
列表更新模块,被配置为通过地址刷新线程读取所述最新地址列表,并按照所述最新地址列表更新本地存储的所述服务提供方的可用地址列表。
14.一种计算机可读介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至12中任一项所述的地址列表更新方法。
15.一种电子设备,其特征在于,包括:
处理器;以及
存储器,用于存储所述处理器的可执行指令;
其中,所述处理器配置为经由执行所述可执行指令来执行权利要求1至12中任一项所述的地址列表更新方法。
CN202010108888.6A 2020-02-21 2020-02-21 地址列表更新方法、装置、介质及电子设备 Pending CN113296968A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010108888.6A CN113296968A (zh) 2020-02-21 2020-02-21 地址列表更新方法、装置、介质及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010108888.6A CN113296968A (zh) 2020-02-21 2020-02-21 地址列表更新方法、装置、介质及电子设备

Publications (1)

Publication Number Publication Date
CN113296968A true CN113296968A (zh) 2021-08-24

Family

ID=77318472

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010108888.6A Pending CN113296968A (zh) 2020-02-21 2020-02-21 地址列表更新方法、装置、介质及电子设备

Country Status (1)

Country Link
CN (1) CN113296968A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114900383A (zh) * 2022-03-28 2022-08-12 青岛海尔科技有限公司 接口处理方法、装置、电子设备及计算机可读存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120087233A1 (en) * 2009-06-01 2012-04-12 Bin Wang Address Refresh Method and System
CN105635331A (zh) * 2014-11-18 2016-06-01 阿里巴巴集团控股有限公司 一种分布式环境下的服务寻址方法及装置
US20160373405A1 (en) * 2015-06-16 2016-12-22 Amazon Technologies, Inc. Managing dynamic ip address assignments
US20170013427A1 (en) * 2015-07-10 2017-01-12 Qualcomm Incorporated Techniques for improved short message services
CN109936639A (zh) * 2017-12-15 2019-06-25 中兴通讯股份有限公司 一种服务调用方法及服务器
CN110365809A (zh) * 2019-07-23 2019-10-22 中南民族大学 分布式服务器地址配置***及方法
WO2019223167A1 (zh) * 2018-05-21 2019-11-28 平安科技(深圳)有限公司 获取sip服务器地址的方法、装置、设备和存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120087233A1 (en) * 2009-06-01 2012-04-12 Bin Wang Address Refresh Method and System
CN105635331A (zh) * 2014-11-18 2016-06-01 阿里巴巴集团控股有限公司 一种分布式环境下的服务寻址方法及装置
US20160373405A1 (en) * 2015-06-16 2016-12-22 Amazon Technologies, Inc. Managing dynamic ip address assignments
US20170013427A1 (en) * 2015-07-10 2017-01-12 Qualcomm Incorporated Techniques for improved short message services
CN109936639A (zh) * 2017-12-15 2019-06-25 中兴通讯股份有限公司 一种服务调用方法及服务器
WO2019223167A1 (zh) * 2018-05-21 2019-11-28 平安科技(深圳)有限公司 获取sip服务器地址的方法、装置、设备和存储介质
CN110365809A (zh) * 2019-07-23 2019-10-22 中南民族大学 分布式服务器地址配置***及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114900383A (zh) * 2022-03-28 2022-08-12 青岛海尔科技有限公司 接口处理方法、装置、电子设备及计算机可读存储介质
CN114900383B (zh) * 2022-03-28 2024-04-19 青岛海尔科技有限公司 接口处理方法、装置、电子设备及计算机可读存储介质

Similar Documents

Publication Publication Date Title
CN107590001B (zh) 负载均衡方法及装置、存储介质、电子设备
US20210385290A1 (en) Method and system for providing high efficiency, bidirectional messaging for low latency applications
US20200099606A1 (en) Distrubuted testing service
US10187445B2 (en) System, method and browser client for enabling browser data synchronization
US7831734B2 (en) Method and system for remote configuration of network devices
US8639786B2 (en) Consistency domains for replication in distributed computing
CN115004673B (zh) 消息推送方法、装置、电子设备及计算机可读介质
US9432449B2 (en) Managing connection failover in a load balancer
CN109783151B (zh) 规则变更的方法和装置
CN106933548B (zh) 全局信息获取、处理及更新、方法、装置和***
US20090055888A1 (en) Self identifying services in distributed computing
CN110580305B (zh) 生成标识符的方法、装置、***和介质
CN112118315A (zh) 数据处理***、方法、装置、电子设备和存储介质
WO2021051747A1 (zh) 数据更新方法、***、装置、电子设备及计算机存储介质
CN112769671B (zh) 消息处理方法、装置与***
CN114172966A (zh) 单元化架构下的服务调用方法、服务处理方法及装置
US8725856B2 (en) Discovery of network services
CN113079098B (zh) 路由更新的方法、装置、设备和计算机可读介质
US20080235384A1 (en) Web service for coordinating actions of clients
CN114938395A (zh) 服务响应方法、装置、设备及存储介质
CN113296968A (zh) 地址列表更新方法、装置、介质及电子设备
US20230283695A1 (en) Communication Protocol for Knative Eventing's Kafka components
CN108833147B (zh) 一种配置信息的更新方法和装置
CN112448977A (zh) 分配任务的***、方法、设备和计算机可读介质
CN112187916B (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