CN116069489A - 一种自动负载均衡分配方法及系统 - Google Patents

一种自动负载均衡分配方法及系统 Download PDF

Info

Publication number
CN116069489A
CN116069489A CN202111285327.4A CN202111285327A CN116069489A CN 116069489 A CN116069489 A CN 116069489A CN 202111285327 A CN202111285327 A CN 202111285327A CN 116069489 A CN116069489 A CN 116069489A
Authority
CN
China
Prior art keywords
server
distribution
calling
information
call
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
CN202111285327.4A
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.)
Qingdao Haier Technology Co Ltd
Haier Smart Home Co Ltd
Original Assignee
Qingdao Haier Technology Co Ltd
Haier Smart Home 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 Qingdao Haier Technology Co Ltd, Haier Smart Home Co Ltd filed Critical Qingdao Haier Technology Co Ltd
Priority to CN202111285327.4A priority Critical patent/CN116069489A/zh
Publication of CN116069489A publication Critical patent/CN116069489A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本公开公开的一种自动负载均衡分配方法及系统，分发服务器在调用服务器上注册zookeeper，以对调用服务器的节点进行监听；调用服务器在zookeeper注册并保存或更新调用服务器信息；zookeeper向分发服务器推送调用服务器信息；分发服务器更新本地保存的调用服务器信息并设置hash slot数据结构；数据请求端向分发服务器发送地址获取请求；分发服务器通过slot查询与地址获取请求对应的调用服务器地址，并反馈至数据请求端，数据请求端基于反馈的调用服务器地址对对应的调用服务器进行数据调用。本公开实现了负载均衡的全自动，解决了hash slot需要手动分配的问题，针对分布式节点添加与删除的场景可以自动做到高效的hash槽位迁移，将普通hash算法分片时出现的数据迁移的影响减少到最少。

Description

一种自动负载均衡分配方法及系统
技术领域
本公开涉及电子技术领域，尤其涉及一种自动负载均衡分配方法及系统。
背景技术
目前针对分布式环境下的数据散列算法主要有两种：1.一致性hash算法；2.hashslot算法。
hash slot算法常见于redis中的集群扩缩容。redis中的hash slot实现方法如下：在redis集群环境下，数据是分片存储的，因此在启动的时候可指定该redis节点分配的hash槽值。假设hash槽值为0-1000，那么redis客户端进行操作时，首先对需要操作的key进行CRC16(将key首先转换为int)，然后对其进行取模，计算到所处的槽位，然后将请求转发到对应的redis节点，这样就完成了数据的分片存储与管理。redis如果需要缩容或者扩容，可以手动进行分hash槽，例如：redis-1分配{0-7000}，redis-2分配{7001-16383}，如果需要加入redis-3则将redis-1，redis-2的hash槽拆出分配给redis-3；同样如果redis-1剔除集群，则将redis-1的{0-7000}，分配给redis-2，redis-3。但是目前redis中的hash slot算法需要使用者手动分配hash槽，这造成了数据节点均匀度依靠hash槽的分配结果，并且不能实现服务器节点扩缩容时自动迁移数据，实时性差。
因此，如何实现hash slot的自动化，成为了本领域技术人员急需解决的问题。
发明内容
有鉴于此，本公开提供如下技术方案：
一种自动负载均衡分配方法，应用于自动负载均衡分配系统，所述自动负载均衡分配系统包括：分发服务器、调用服务器、zookeeper和数据请求端；所述方法包括：
所述分发服务器在所述调用服务器上注册所述zookeeper，以对所述调用服务器的节点进行监听；
所述调用服务器在所述zookeeper保存或更新调用服务器信息；
当有调用服务器信息保存或更新时，所述zookeeper向所述服务器推送所述调用服务器信息；
所述分发服务器基于接收的所述调用服务器信息更新本地保存的调用服务器信息；
所述分发服务器基于本地保存的调用服务器信息设置hash slot数据结构；
数据请求端向所述分发服务器发送地址获取请求；
所述分发服务器通过slot查询与地址获取请求对应的调用服务器地址，并反馈至所述数据请求端；
所述数据请求端基于反馈的调用服务器地址对对应的调用服务器进行数据调用。
优选地，所述调用服务器信息包括调用服务器的IP地址、表征调用服务器可以承载的请求数量的权重及调用服务器的地理分布信息。
优选地，所述表征调用服务器可以承载的请求数量的权重由分发服务器CPU核数、分发服务器内存、分发服务器网络带宽、分发服务器空闲内存、分发服务器空闲CPU负载和分发服务器CPU总核数确定。
优选地，所述表征调用服务器可以承载的请求数量的权重基于公式权重＝分发服务器CPU核数*0.5+分发服务器内存*0.2+分发服务器网络带宽/100*0.5+分发服务器空闲内存*0.5+分发服务器空闲CPU负载*分发服务器CPU总核数计算得到。
优选地，所述分发服务器基于本地保存的调用服务器信息设置hash slot数据结构包括：
所述分发服务器对比接收的调用服务器信息与本地保存的调用服务器信息，确定变化场景；
所述分发服务器基于变化场景及接收的调用服务器信息更新本地保存的调用服务器信息。
优选地，所述方法还包括：
所述调用服务器周期性向zookeeper发送调用服务器运行信息；
所述zookeeper基于所述调用服务器运行信息更新对应的调用服务器信息并推送至所述分发服务器。
一种自动负载均衡分配系统，包括：分发服务器、调用服务器、zookeeper和数据请求端，其中：
所述分发服务器，用于在所述调用服务器上注册zookeeper，以对所述调用服务器的节点进行监听；
所述调用服务器，用于在所述zookeeper保存或更新调用服务器信息；
所述zookeeper，用于当有调用服务器信息保存或更新时，向所述分发服务器推送调用服务器信息；
所述分发服务器还用于基于接收的调用服务器信息更新本地保存的调用服务器信息；
所述分发服务器还用于基于本地保存的调用服务器信息设置hash slot数据结构；
所述数据请求端，用于向分所述发服务器发送地址获取请求；
所述分发服务器还用于通过slot查询与地址获取请求对应的调用服务器地址，并反馈至数据请求端；
所述数据请求端还用于基于反馈的调用服务器地址对对应的调用服务器进行数据调用。
一种自动负载均衡分配设备，包括至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述指示一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上所述的自动负载均衡分配方法。
一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上所述的自动负载均衡分配方法。
一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上所述的自动负载均衡分配方法。
从上述技术方案可以看出，本公开公开的一种自动负载均衡分配方法及系统，其中，分发服务器在调用服务器上注册zookeeper，以对所述调用服务器的节点进行监听；所述调用服务器在zookeeper保存或更新调用服务器信息；当有调用服务器信息保存或更新时，zookeeper向分发服务器推送调用服务器信息；所述分发服务器基于接收的调用服务器信息更新本地保存的调用服务器信息；所述分发服务器基于本地保存的调用服务器信息设置hash slot数据结构；数据请求端向分发服务器发送地址获取请求；所述分发服务器通过slot查询与地址获取请求对应的调用服务器地址，并反馈至数据请求端，数据请求端基于反馈的调用服务器地址对对应的调用服务器进行数据调用。本公开实现了hash slot的全自动，解决了hash slot需要手动分配的问题，针对分布式节点添加与删除的场景可以自动做到高效的hash槽位迁移，将普通hash算法分片时出现的数据迁移的影响减少到最少。
附图说明
为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本公开公开的一种自动负载均衡分配方法实施例1的方法流程图；
图2为本公开公开的一种自动负载均衡分配方法实施例2的方法流程图；
图3为本公开公开的一种自动负载均衡分配系统实施例1的结构示意图；
图4为本公开公开的一种自动负载均衡分配系统实施例2的结构示意图；
图5为本公开公开的一种自动负载均衡分配设备的结构示意图。
具体实施方式
下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。
如图1所示，为本公开公开的一种自动负载均衡分配方法实施例1的方法流程图。
具体的：
S101.分发服务器在调用服务器上注册zookeeper，以对调用服务器的节点进行监听；
首先分发服务器都对zookeeper的调用服务器节点进行监听，一旦调用服务器上注册的节点数量增加，减少或者配置的权重发生变化就可以获得zookeeper的回调通知。这样做的目的是保证所有的分发服务器都能同时并及时的获取到调用服务器集群的变化，可以保证及时调整hash slot的前提。
S102.调用服务器在zookeeper保存或更新调用服务器信息；
S103.当有调用服务器信息保存或更新时，zookeeper向分发服务器推送调用服务器信息；
S104.分发服务器基于接收的调用服务器信息更新本地保存的调用服务器信息；
S105.分发服务器基于本地保存的调用服务器信息设置hash slot数据结构；
S106.数据请求端向分发服务器发送地址获取请求；
S107.分发服务器通过slot查询与地址获取请求对应的调用服务器地址，并反馈至数据请求端。
首先分发服务器针对请求的入参进行CRC16转换为int数值，然后对总hash槽个数进行hash取模，取出实际的槽位索引，然后通过数组查询该索引对应的分组id，再通过分组id查询实际的调用服务器的ip等信息。由于CRC16不同于其他的hash散列算法，执行的速率更高，并且散列的程度也较高，所以redis中集群分发请求也是使用该算法，又因为借助了数组与Map的数据结构，两次查询都是O(1)级别的，查询效率很高。针对对于同一个请求，分配到的执行服务器是同一台这一特性，可以借助guava等本地缓存中间件进一步提高分配查询的效率。与一般的缓存思想类似，使用请求参数作为key，调用服务器的ip作为value的数据结构作为存储。在查询hashslot的数据结构返回服务器ip之前添加缓存层，如果命中则直接返回，没有查询到则走hash slot查询出服务器ip，并且在返回之前写入到本地缓存中。为了保证缓存数据的有效性，同样采用了比较普遍的做法，也就是缓存数据变化时，则直接删除所有的缓存，这么做的好处有如下几点：1.可以快速使缓存内存失效，如果存在其他线程则不会进行脏读，则是重新走实际的查询并写入的过程；2.直接删除并非是更新缓存是基于懒加载的设计思想，并且更新的过程相比直接删除的过程耗时更久，会很有可能继续造成脏读的情况。
S108.数据请求端基于反馈的调用服务器地址对对应的调用服务器进行数据调用。
与现有技术相比，本公开解决了传统的hash slot需要手动进行分配的痛点，提供了基于权重的分配策略，极大的提高了分配效率(与一致性hash的速率对比见表1及表2)，该算法可以作为去中心化的方式进行部署，避免了单点故障。
表1 Hash槽个数为16383(400w次总耗时)
Figure BDA0003332698830000061
表2 Hash槽个数为16383(平均单次耗时)
Figure BDA0003332698830000062
在一种实现方式中，上述步骤S102中，调用服务器信息包括服务器IP、权重及地理分布信息。假设部署的调用服务器一共有4台，ip地址分别为192.168.100.0，192.168.100.1，192.168.100.2，192.168.100.3，并且每台服务器有自身的服务器具体参数差别(例如内存64G，CPU逻辑核数24核，网络带宽1G，机房位置为华北区等等)，通过每一台服务器的性能以及地理位置分布计算出一个权重，权重越大表示服务器可以承载的请求数量越多，可以使hash slot分配槽位时更加的倾斜。
表征调用服务器可以承载的请求数量的权重＝分发服务器CPU核数*第一数值+分发服务器内存*第二数值+分发服务器网络带宽/100*第三数值+分发服务器空闲内存*第四数值+分发服务器空闲CPU负载*分发服务器CPU总核数。其中，第一数值可以为0.5，第二数值可以为0.2，第三数值可以为0.5，第四数值可以为0.5。
对于以下几组服务器配置可以分别计算出权重：
CPU核数 内存 网络带宽 空闲内存 空闲负载 权重
24 16 1000 8 50％ 36.2
32 24 500 16 30％ 40.9
64 64 1000 48 60％ 112.2
64 32 800 16 50％ 82.4
由于zookeeper是树形保存形式，并且提供了持久互斥的特性，所以将服务器ip作为保存的key值，权重以及地理分布作为保存的value使用。
就以上面的计算结果为例，最终保存到zookeeper的服务器节点信息如下：
服务器ip地址 权重 地理分布
192.168.100.0 36.2 华北
192.168.100.1 40.9 西北
192.168.100.2 112.2 东南
192.168.100.3 82.4 华北
结合多种服务器运行参数，基于公式计算出服务器实际的负载能力，使请求分发更加的合理。
在一种实现方式中，上述方法还包括：
调用服务器周期性向zookeeper发送调用服务器运行信息；
调用服务器根据实际需要设定的时间间隔，定时上报自身的服务器状态，包括CPU负载，网络情况，剩余内存等变化参数，以及CPU核数，总内存等基准参数，更新到zookeeper对应的节点信息上。
之所以需要定时上报，是因为服务器的运行状态可以直接反映出其可以承载服务的能力，通过更新这些数据，进一步可以动态更新该服务器的权重，最终动态调整分配到该台服务器的请求数量。
如果计算出权重信息没有变化则不更新。
zookeeper基于调用服务器运行信息更新对应的调用服务器信息并推送至分发服务器。
当调用服务器信息推送至分发服务器后，分发服务器按照步骤S105的方法进行数据更新。
在上述方法实施例1的基础上，如图2所示，为本公开公开的一种自动负载均衡分配方法实施例2的方法流程图。
具体的：
S201.分发服务器在调用服务器上注册zookeeper，以对调用服务器的节点进行监听；
首先分发服务器都对zookeeper的调用服务器节点进行监听，一旦调用服务器上注册的节点数量增加，减少或者配置的权重发生变化就可以获得zookeeper的回调通知。这样做的目的是保证所有的分发服务器都能同时并及时的获取到调用服务器集群的变化，可以保证及时调整hash slot的前提。
S202.调用服务器在zookeeper注册并保存或更新调用服务器信息；
S203.当有调用服务器信息保存或更新时，zookeeper向分发服务器推送调用服务器信息；
S204.分发服务器基于接收的调用服务器信息更新本地保存的调用服务器信息；
S205.分发服务器对比接收的调用服务器信息与本地保存的调用服务器信息，确定变化场景；
分发服务器内部使用统一的sdk进行hash slot数据结构的维护，hash slot的槽位进行变更的场景一共4种：
1.初始化组(仅有一组调用服务器，hash槽初始化)；
2.增加组(调用服务器节点数大于等于2，hash槽需要进行迁移)；
3.删除组(调用服务器组数减少，hash槽进行部分合并)；
4.任意组的权重信息变化(hash槽需要进行拆分或合并)。
S206.分发服务器基于变化场景及接收的调用服务器信息更新本地保存的调用服务器信息；
场景一：初始化组
首先针对初始化阶段需要定义hash槽的个数(默认为16383个，转化为16进制为HEX：3FFF)。
再次定义主要的数据结构，本方案中的数据结构有五个：
1.存储所有hash槽编号以及对应的分组编号，上面设计使用的map，由于实际的hash槽个数在程序启动时就已经确定所以使用数组来替代map。数组的索引就是hash槽编号(hash槽编号设定从0开始)，数组的value就是分组的个数，使用数组替换map的好处有：数组比map更节省内存空间；虽然查询的复杂度都是O(1)，但是map是近似O(1)，并且数组由于内存连续可以享受到操作系统的数据页缓存的优化，所以总体来说速度更快。
2.需要一个map来存储多个分组中的hash槽编号，例如目前有两个组，hash槽个数为4个，那么存储的结构有可能是：{分组1：[slot0,slot2],分组2：[slot1,slot3]}，为了保证内部存储的hash槽有序(为了保证增加，删除调整的hash槽各个环境都一致)，则使用TreeMap来存储；
3.为了快速计算增加的组编号(多次增加，删除组后组编号存在不连续，为了高效复用组编号，所以需要计算出未使用的最小组号)，使用一个LinkedList来记录存在的组号；
4.并且为了方便计算增加组与删除组时需要移动的hash槽，将当前组的个数进行了存储；
5.由于组号是函数内部使用的数据，为了方便扩展可以增加组时将组信息传递进来，所以还增加了一个map来存储组编号与实际组信息的关系；
通过以上五个数据结构可以快速描述分组与hash槽的对应关系(正向，反向)，其中两个为关键的数据结构，三个为辅助数据结构。
由于初始化时只有一个服务提供组，那么不论该服务器的权重是如何的，都可以占满所有的hash槽(即16383个槽位中写的都是分组1的id)，而分组1保存了所有的hash槽(16383个)。
场景二：添加组
以从一个组添加到两个组的过程为例，就在场景一的前提下，添加组之前仅有一个分组(192.168.100.0权重100)，现在又需要添加分组2(192.168.100.1权重100)，因为添加的分组的权限也正好为100，那么添加的组正好分配一半的hash槽位(如果权重不一致，如果添加的分组2权重为300，则分组1占比为1/4，分组2为3/4)。
添加组需要迁移出的hash槽计算公式为：
总槽位*(自己的权重/原有的权重之和–自己的权重/(原有权重之和+新节点的权重))
所以分组1需要迁移出的节点个数为8191个，由于保存hash槽的数据结构是TreeMap数据结构(会根据key进行排序)，所以仅需要删除末尾的8191个hash槽，同时将这些槽位添加到分组2中，并且修改移动hash槽对应的分组为分组2。
场景三：删除组
删除组与添加组的过程是一个相反的过程，以2个组删除2号组变为1个组的过程为例。
在场景二的前提下，删除组之前有两个组存在(192.168.100.0，192.168.100.1)，并且正好这两台服务器的权重一致，那么两个组中分配的hash slot一致。现在接收到zookeeper的通知组二需要下线，那么需要将组二的hash slot转移到组一中，其过程与添加组正好是一个逆过程，计算出需要移动的槽位个数，计算公式如下：
总槽位*(自己的权重/(原有的权重之和–删除节点的权重)–自己的权重/(原有权重之和))
将分组2的全部槽位分配给分组1，然后修改原槽位指向的分组id为分组。
场景四：任一组的权重信息变化
对于存在调用服务器的权重发生了变更，则需要进行调整分配的槽位。
在场景二的前提下，调用服务器1(192.168.100.0)与调用服务器2(192.168.100.1)的权重一致，那么分组1与分组2的hash槽个数是均分的，这时如果zookeeper通知调用服务器2的权重从100上升到300，触发了hash槽的重新分配，移动的槽位计算公式与增加节点删除节点的公式类似，计算后分组1从占有1/2槽位变为占用1/4槽位，分组2从占有1/2槽位变为占有3/4槽位，那么需要从分组1移动1/4到分组2。
经过槽位的迁移后分组1(192.168.100.0)占用4095个槽位，分组2(192.168.100.1)占用12288个槽位。
假设这时分组1的权重也调整为300，那么按照迁移公式，分组2将归还之前迁移过来的4095个槽位，最终分组1与分组2均分全部的槽位，过程与场景四的一致。
S207.数据请求端向分发服务器发送地址获取请求；
S208.分发服务器通过slot查询与地址获取请求对应的调用服务器地址，并反馈至数据请求端。
首先分发服务器针对请求的入参进行CRC16转换为int数值，然后对总hash槽个数进行hash取模，取出实际的槽位索引，然后通过数组查询该索引对应的分组id，再通过分组id查询实际的调用服务器的ip等信息。由于CRC16不同于其他的hash散列算法，执行的速率更高，并且散列的程度也较高，所以redis中集群分发请求也是使用该算法，又因为借助了数组与Map的数据结构，两次查询都是O(1)级别的，查询效率很高。针对对于同一个请求，分配到的执行服务器是同一台这一特性，可以借助guava等本地缓存中间件进一步提高分配查询的效率。与一般的缓存思想类似，使用请求参数作为key，调用服务器的ip作为value的数据结构作为存储。在查询hashslot的数据结构返回服务器ip之前添加缓存层，如果命中则直接返回，没有查询到则走hash slot查询出服务器ip，并且在返回之前写入到本地缓存中。为了保证缓存数据的有效性，同样采用了比较普遍的做法，也就是缓存数据变化时，则直接删除所有的缓存，这么做的好处有如下几点：1.可以快速使缓存内存失效，如果存在其他线程则不会进行脏读，则是重新走实际的查询并写入的过程；2.直接删除并非是更新缓存是基于懒加载的设计思想，并且更新的过程相比直接删除的过程耗时更久，会很有可能继续造成脏读的情况。
S209.数据请求端基于反馈的调用服务器地址对对应的调用服务器进行数据调用。
如图3所示，为本公开公开的一种自动负载均衡分配系统实施例1的结构示意图。
具体的：
分发服务器101，用于在调用服务器102上注册zookeeper103，以对调用服务器的节点进行监听；
首先分发服务器101都对zookeeper103的调用服务器102节点进行监听，一旦调用服务器102上注册的节点数量增加，减少或者配置的权重发生变化就可以获得zookeeper103的回调通知。这样做的目的是保证所有的分发服务器101都能同时并及时的获取到调用服务器102集群的变化，可以保证及时调整hash slot的前提。
调用服务器102，用于在zookeeper103注册并保存或更新调用服务器信息；
zookeeper103，用于当有调用服务器信息保存或更新时，向分发服务器101推送调用服务器信息；
分发服务器101还用于基于接收的调用服务器信息更新本地保存的调用服务器信息；
分发服务器101还用于基于本地保存的调用服务器信息设置hash slot数据结构；
数据请求端104向分发服务器101发送地址获取请求；
数据请求端104，用于向分发服务器101发送地址获取请求；
分发服务器101还用于通过slot查询与地址获取请求对应的调用服务器地址，并反馈至数据请求端104。
首先分发服务器101针对请求的入参进行CRC16转换为int数值，然后对总hash槽个数进行hash取模，取出实际的槽位索引，然后通过数组查询该索引对应的分组id，再通过分组id查询实际的调用服务器102的ip等信息。由于CRC16不同于其他的hash散列算法，执行的速率更高，并且散列的程度也较高，所以redis中集群分发请求也是使用该算法，又因为借助了数组与Map的数据结构，两次查询都是O(1)级别的，查询效率很高。针对对于同一个请求，分配到的执行服务器是同一台这一特性，可以借助guava等本地缓存中间件进一步提高分配查询的效率。与一般的缓存思想类似，使用请求参数作为key，调用服务器102的ip作为value的数据结构作为存储。在查询hash slot的数据结构返回服务器ip之前添加缓存层，如果命中则直接返回，没有查询到则走hash slot查询出服务器ip，并且在返回之前写入到本地缓存中。为了保证缓存数据的有效性，同样采用了比较普遍的做法，也就是缓存数据变化时，则直接删除所有的缓存，这么做的好处有如下几点：1.可以快速使缓存内存失效，如果存在其他线程则不会进行脏读，则是重新走实际的查询并写入的过程；2.直接删除并非是更新缓存是基于懒加载的设计思想，并且更新的过程相比直接删除的过程耗时更久，会很有可能继续造成脏读的情况。
数据请求端104还用于基于反馈的调用服务器地址对对应的调用服务器102进行数据调用。
与现有技术相比，本公开解决了传统的hash slot需要手动进行分配的痛点，提供了基于权重的分配策略，极大的提高了分配效率(与一致性hash的速率对比见表1及表2)，该算法可以作为去中心化的方式进行部署，避免了单点故障。
表1 Hash槽个数为16383(400w次总耗时)
Figure BDA0003332698830000131
表2 Hash槽个数为16383(平均单次耗时)
Figure BDA0003332698830000132
Figure BDA0003332698830000141
在一种实现方式中，上述步骤S102中，调用服务器信息包括服务器IP、权重及地理分布信息。假设部署的调用服务器102一共有4台，ip地址分别为192.168.100.0，192.168.100.1，192.168.100.2，192.168.100.3，并且每台服务器有自身的服务器具体参数差别(例如内存64G，CPU逻辑核数24核，网络带宽1G，机房位置为华北区等等)，通过每一台服务器的性能以及地理位置分布计算出一个权重，权重越大表示服务器可以承载的请求数量越多，可以使hash slot分配槽位时更加的倾斜。
表征调用服务器可以承载的请求数量的权重＝分发服务器CPU核数*第一数值+分发服务器内存*第二数值+分发服务器网络带宽/100*第三数值+分发服务器空闲内存*第四数值+分发服务器空闲CPU负载*分发服务器CPU总核数。其中，第一数值可以为0.5，第二数值可以为0.2，第三数值可以为0.5，第四数值可以为0.5。
对于以下几组服务器配置可以分别计算出权重：
CPU核数 内存 网络带宽 空闲内存 空闲负载 权重
24 16 1000 8 50％ 36.2
32 24 500 16 30％ 40.9
64 64 1000 48 60％ 112.2
64 32 800 16 50％ 82.4
由于zookeeper103是树形保存形式，并且提供了持久互斥的特性，所以将服务器ip作为保存的key值，权重以及地理分布作为保存的value使用。
就以上面的计算结果为例，最终保存到zookeeper103的服务器节点信息如下：
服务器ip地址 权重 地理分布
192.168.100.0 36.2 华北
192.168.100.1 40.9 西北
192.168.100.2 112.2 东南
192.168.100.3 82.4 华北
结合多种服务器运行参数，基于公式计算出服务器实际的负载能力，使请求分发更加的合理。
在一种实现方式中，上述方法还包括：
调用服务器102还用于周期性向zookeeper103发送调用服务器运行信息；
调用服务器102根据实际需要设定的时间间隔，定时上报自身的服务器状态，包括CPU负载，网络情况，剩余内存等变化参数，以及CPU核数，总内存等基准参数，更新到zookeeper103对应的节点信息上。
之所以需要定时上报，是因为服务器的运行状态可以直接反映出其可以承载服务的能力，通过更新这些数据，进一步可以动态更新该服务器的权重，最终动态调整分配到该台服务器的请求数量。
如果计算出权重信息没有变化则不更新。
zookeeper103还用于基于调用服务器运行信息更新对应的调用服务器信息并推送至分发服务器101。
当调用服务器信息推送至分发服务器101后，分发服务器101按照步骤S105的方法进行数据更新。
如图4所示，为本公开公开的一种自动hash slot分配系统实施例2的结构示意图。
具体的：
分发服务器101，用于在调用服务器102注册zookeeper103监听；
首先分发服务器101都对zookeeper103的调用服务器102节点进行监听，一旦调用服务器102上注册的节点数量增加，减少或者配置的权重发生变化就可以获得zookeeper103的回调通知。这样做的目的是保证所有的分发服务器101都能同时并及时的获取到调用服务器102集群的变化，可以保证及时调整hash slot的前提。
调用服务器102，用于在zookeeper103注册并保存或更新调用服务器信息；
zookeeper103，用于当有调用服务器信息保存或更新时，向分发服务器101推送调用服务器信息；
分发服务器101还用于基于接收的调用服务器信息更新本地保存的调用服务器信息；
对比单元1011，用于对比接收的调用服务器信息与本地保存的调用服务器信息，确定变化场景；
分发服务器101内部使用统一的sdk进行hash slot数据结构的维护，hash slot的槽位进行变更的场景一共4种：
1.初始化组(仅有一组调用服务器102，hash槽初始化)；
2.增加组(调用服务器102节点数大于等于2，hash槽需要进行迁移)；
3.删除组(调用服务器102组数减少，hash槽进行部分合并)；
4.任意组的权重信息变化(hash槽需要进行拆分或合并)。
更新单元1012用于基于变化场景及接收的调用服务器信息更新本地保存的调用服务器信息；
场景一：初始化组
首先针对初始化阶段需要定义hash槽的个数(默认为16383个，转化为16进制为HEX：3FFF)。
再次定义主要的数据结构，本方案中的数据结构有五个：
1.存储所有hash槽编号以及对应的分组编号，上面设计使用的map，由于实际的hash槽个数在程序启动时就已经确定所以使用数组来替代map。数组的索引就是hash槽编号(hash槽编号设定从0开始)，数组的value就是分组的个数，使用数组替换map的好处有：数组比map更节省内存空间；虽然查询的复杂度都是O(1)，但是map是近似O(1)，并且数组由于内存连续可以享受到操作系统的数据页缓存的优化，所以总体来说速度更快。
2.需要一个map来存储多个分组中的hash槽编号，例如目前有两个组，hash槽个数为4个，那么存储的结构有可能是：{分组1：[slot0,slot2],分组2：[slot1,slot3]}，为了保证内部存储的hash槽有序(为了保证增加，删除调整的hash槽各个环境都一致)，则使用TreeMap来存储；
3.为了快速计算增加的组编号(多次增加，删除组后组编号存在不连续，为了高效复用组编号，所以需要计算出未使用的最小组号)，使用一个LinkedList来记录存在的组号；
4.并且为了方便计算增加组与删除组时需要移动的hash槽，将当前组的个数进行了存储；
5.由于组号是函数内部使用的数据，为了方便扩展可以增加组时将组信息传递进来，所以还增加了一个map来存储组编号与实际组信息的关系；
通过以上五个数据结构可以快速描述分组与hash槽的对应关系(正向，反向)，其中两个为关键的数据结构，三个为辅助数据结构。
由于初始化时只有一个服务提供组，那么不论该服务器的权重是如何的，都可以占满所有的hash槽(即16383个槽位中写的都是分组1的id)，而分组1保存了所有的hash槽(16383个)。
场景二：添加组
以从一个组添加到两个组的过程为例，就在场景一的前提下，添加组之前仅有一个分组(192.168.100.0权重100)，现在又需要添加分组2(192.168.100.1权重100)，因为添加的分组的权限也正好为100，那么添加的组正好分配一半的hash槽位(如果权重不一致，如果添加的分组2权重为300，则分组1占比为1/4，分组2为3/4)。
添加组需要迁移出的hash槽计算公式为：
总槽位*(自己的权重/原有的权重之和–自己的权重/(原有权重之和+新节点的权重))
所以分组1需要迁移出的节点个数为8191个，由于保存hash槽的数据结构是TreeMap数据结构(会根据key进行排序)，所以仅需要删除末尾的8191个hash槽，同时将这些槽位添加到分组2中，并且修改移动hash槽对应的分组为分组2。
场景三：删除组
删除组与添加组的过程是一个相反的过程，以2个组删除2号组变为1个组的过程为例。
在场景二的前提下，删除组之前有两个组存在(192.168.100.0，192.168.100.1)，并且正好这两台服务器的权重一致，那么两个组中分配的hash slot一致。现在接收到zookeeper的通知组二需要下线，那么需要将组二的hash slot转移到组一中，其过程与添加组正好是一个逆过程，计算出需要移动的槽位个数，计算公式如下：
总槽位*(自己的权重/(原有的权重之和–删除节点的权重)–自己的权重/(原有权重之和))
将分组2的全部槽位分配给分组1，然后修改原槽位指向的分组id为分组。
场景四：任一组的权重信息变化
对于存在调用服务器102的权重发生了变更，则需要进行调整分配的槽位。
在场景二的前提下，调用服务器102(192.168.100.0)与调用服务器102(192.168.100.1)的权重一致，那么分组1与分组2的hash槽个数是均分的，这时如果zookeeper通知调用服务器102(192.168.100.1)的权重从100上升到300，触发了hash槽的重新分配，移动的槽位计算公式与增加节点删除节点的公式类似，计算后分组1从占有1/2槽位变为占用1/4槽位，分组2从占有1/2槽位变为占有3/4槽位，那么需要从分组1移动1/4到分组2。
经过槽位的迁移后分组1(192.168.100.0)占用4095个槽位，分组2(192.168.100.1)占用12288个槽位。
假设这时分组1的权重也调整为300，那么按照迁移公式，分组2将归还之前迁移过来的4095个槽位，最终分组1与分组2均分全部的槽位，过程与场景四的一致。
数据请求端104向分发服务器101发送地址获取请求；
数据请求端104，用于向分发服务器101发送地址获取请求；
分发服务器101还用于通过slot查询与地址获取请求对应的调用服务器地址，并反馈至数据请求端104。
首先分发服务器101针对请求的入参进行CRC16转换为int数值，然后对总hash槽个数进行hash取模，取出实际的槽位索引，然后通过数组查询该索引对应的分组id，再通过分组id查询实际的调用服务器102的ip等信息。由于CRC16不同于其他的hash散列算法，执行的速率更高，并且散列的程度也较高，所以redis中集群分发请求也是使用该算法，又因为借助了数组与Map的数据结构，两次查询都是O(1)级别的，查询效率很高。针对对于同一个请求，分配到的执行服务器是同一台这一特性，可以借助guava等本地缓存中间件进一步提高分配查询的效率。与一般的缓存思想类似，使用请求参数作为key，调用服务器102的ip作为value的数据结构作为存储。在查询hash slot的数据结构返回服务器ip之前添加缓存层，如果命中则直接返回，没有查询到则走hash slot查询出服务器ip，并且在返回之前写入到本地缓存中。为了保证缓存数据的有效性，同样采用了比较普遍的做法，也就是缓存数据变化时，则直接删除所有的缓存，这么做的好处有如下几点：1.可以快速使缓存内存失效，如果存在其他线程则不会进行脏读，则是重新走实际的查询并写入的过程；2.直接删除并非是更新缓存是基于懒加载的设计思想，并且更新的过程相比直接删除的过程耗时更久，会很有可能继续造成脏读的情况。
数据请求端104还用于基于反馈的调用服务器地址对对应的调用服务器102进行数据调用。
图5为本发明实施例提供的自动负载均衡分配设备的硬件结构示意图。如图5所示，本实施例的自动负载均衡分配设备500包括：处理器501以及存储器502；
其中，存储器502，用于存储计算机执行指令；
处理器501，用于执行存储器存储的计算机执行指令，以实现上述实施例中自动负载均衡分配系统所执行的各个步骤。具体可以参见前述方法实施例中的相关描述。
可选地，存储器502既可以是独立的，也可以跟处理器501集成在一起。
当存储器502独立设置时，该电子设备还包括总线503，用于连接所述存储器502和处理器501。
本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上所述的自动负载均衡分配方法。
本发明实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上所述的自动负载均衡分配方法。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置或系统类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本公开。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种自动负载均衡分配方法，其特征在于，应用于自动负载均衡分配系统，所述自动负载均衡分配系统包括：分发服务器、调用服务器、zookeeper和数据请求端；所述方法包括：
所述分发服务器在所述调用服务器上注册所述zookeeper，以对所述调用服务器的节点进行监听；
所述调用服务器在所述zookeeper保存或更新调用服务器信息；
当有调用服务器信息保存或更新时，所述zookeeper向所述服务器推送所述调用服务器信息；
所述分发服务器基于接收的所述调用服务器信息更新本地保存的调用服务器信息；
所述分发服务器基于本地保存的调用服务器信息设置hash slot数据结构；
数据请求端向所述分发服务器发送地址获取请求；
所述分发服务器通过slot查询与地址获取请求对应的调用服务器地址，并反馈至所述数据请求端；
所述数据请求端基于反馈的调用服务器地址对对应的调用服务器进行数据调用。
2.如权利要求1所述的方法，其特征在于，所述调用服务器信息包括调用服务器的IP地址、表征调用服务器可以承载的请求数量的权重及调用服务器的地理分布信息。
3.如权利要求2所述的方法，其特征在于，所述表征调用服务器可以承载的请求数量的权重由分发服务器CPU核数、分发服务器内存、分发服务器网络带宽、分发服务器空闲内存、分发服务器空闲CPU负载和分发服务器CPU总核数确定。
4.根据权利要求3所述的方法，其特征在于，所述表征调用服务器可以承载的请求数量的权重基于公式权重＝分发服务器CPU核数*0.5+分发服务器内存*0.2+分发服务器网络带宽/100*0.5+分发服务器空闲内存*0.5+分发服务器空闲CPU负载*分发服务器CPU总核数计算得到。
5.如权利要求1所述的方法，其特征在于，所述分发服务器基于本地保存的调用服务器信息设置hash slot数据结构包括：
所述分发服务器对比接收的调用服务器信息与本地保存的调用服务器信息，确定变化场景；
所述分发服务器基于变化场景及接收的调用服务器信息更新本地保存的调用服务器信息。
6.如权利要求1至5任一项所述的方法，其特征在于，还包括：
所述调用服务器周期性向zookeeper发送调用服务器运行信息；
所述zookeeper基于所述调用服务器运行信息更新对应的调用服务器信息并推送至所述分发服务器。
7.一种自动负载均衡分配系统，其特征在于，包括：分发服务器、调用服务器、zookeeper和数据请求端，其中：
所述分发服务器，用于在所述调用服务器上注册zookeeper，以对所述调用服务器的节点进行监听；
所述调用服务器，用于在所述zookeeper保存或更新调用服务器信息；
所述zookeeper，用于当有调用服务器信息保存或更新时，向所述分发服务器推送调用服务器信息；
所述分发服务器还用于基于接收的调用服务器信息更新本地保存的调用服务器信息；
所述分发服务器还用于基于本地保存的调用服务器信息设置hash slot数据结构；
所述数据请求端，用于向分所述发服务器发送地址获取请求；
所述分发服务器还用于通过slot查询与地址获取请求对应的调用服务器地址，并反馈至数据请求端；
所述数据请求端还用于基于反馈的调用服务器地址对对应的调用服务器进行数据调用。
8.一种自动负载均衡分配设备，其特征在于，包括至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述指示一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求1-7任一项所述的自动负载均衡分配方法。
9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求1至7任一项所述的自动负载均衡分配方法。
10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的自动负载均衡分配方法。
CN202111285327.4A 2021-11-01 2021-11-01 一种自动负载均衡分配方法及系统 Pending CN116069489A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111285327.4A CN116069489A (zh) 2021-11-01 2021-11-01 一种自动负载均衡分配方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111285327.4A CN116069489A (zh) 2021-11-01 2021-11-01 一种自动负载均衡分配方法及系统

Publications (1)

Publication Number Publication Date
CN116069489A true CN116069489A (zh) 2023-05-05

Family

ID=86170337

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111285327.4A Pending CN116069489A (zh) 2021-11-01 2021-11-01 一种自动负载均衡分配方法及系统

Country Status (1)

Country Link
CN (1) CN116069489A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117290114A (zh) * 2023-11-23 2023-12-26 南京网眼信息技术有限公司 一种基于cpu积分的负载均衡方法及系统
CN117439993A (zh) * 2023-12-22 2024-01-23 中电云计算技术有限公司 Redis集群负载均衡方法、装置、设备及存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117290114A (zh) * 2023-11-23 2023-12-26 南京网眼信息技术有限公司 一种基于cpu积分的负载均衡方法及系统
CN117290114B (zh) * 2023-11-23 2024-01-30 南京网眼信息技术有限公司 一种基于cpu积分的负载均衡方法及系统
CN117439993A (zh) * 2023-12-22 2024-01-23 中电云计算技术有限公司 Redis集群负载均衡方法、装置、设备及存储介质
CN117439993B (zh) * 2023-12-22 2024-04-16 中电云计算技术有限公司 Redis集群负载均衡方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
EP3465477B1 (en) Cached data expiration and refresh
CN116069489A (zh) 一种自动负载均衡分配方法及系统
US5864854A (en) System and method for maintaining a shared cache look-up table
US5933849A (en) Scalable distributed caching system and method
CN108829352B (zh) 一种分布式存储系统的用户配额方法及系统
US9465819B2 (en) Distributed database
US20120110108A1 (en) Computer System with Cooperative Cache
CA2505023A1 (en) Proxy and cache architecture for document storage
US20050172076A1 (en) System for managing distributed cache resources on a computing grid
US20170262464A1 (en) System and method for supporting elastic data metadata compression in a distributed data grid
US10817203B1 (en) Client-configurable data tiering service
CN107992270B (zh) 一种多控存储系统全局共享缓存的方法及装置
US6973536B1 (en) Self-adaptive hybrid cache
CN114817195A (zh) 一种分布式存储缓存管理的方法、系统、存储介质及设备
CN107908713A (zh) 一种基于Redis集群的分布式动态杜鹃过滤系统及其过滤方法
CN110825732A (zh) 数据查询方法、装置、计算机设备和可读存储介质
CN114338718B (zh) 面向巨量遥感数据的分布式存储方法、装置及介质
CN104639570A (zh) 资源对象存储处理方法及装置
CN112559570B (zh) 缓存数据获取方法、装置、设备及存储介质
CN109460293B (zh) 无线云计算系统中分布式计算环境下的计算资源选择方法
CN117539915B (zh) 一种数据处理方法及相关装置
Luo et al. Distributed dynamic cuckoo filter system based on Redis Cluster
CN112084216B (zh) 基于布隆过滤器的数据查询系统
CN117075823B (zh) 对象查找方法、系统、电子设备及存储介质
US20230289347A1 (en) Cache updates through distributed message queues

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