分布式数据库缓存方法及其哈希环优化与流程

本发明涉及计算机应用技术领域，特别涉及一种分布式数据库缓存方法及其哈希环优化方法。

背景技术：

在数据库集群中，对物理节点的添加或者删除都是集群管理系统最基本的功能。如果采用哈希取模、取随机数等常规的哈希算法，那么在有物理节点添加或者删除的情况下，大量原有的缓存就会重新建立，这样会给整个数据库集群系统带来严重的性能花销，甚至影响到业务系统的正常运作，而且这样还严重的违反了单调性原则。

而一致性哈希算法的出现就是为了保证算法的单调性，即在移除或者添加一个物理节点时，它对于已存在的缓存映射关系的影响非常小。而且，集群中物理节点的数量越多，一致性哈希算法保证单调性的效果越好。一致性哈希算法的原理如下：

(1)确定哈希环及环上的物理节点。

先确定一个哈希值的范围，例如：(-2¹⁶，2¹⁶)。将这个范围的所有哈希值看作为一个顺时针递增且首尾相连的圆环，称之为哈希环。

哈希环是实际不存在的虚拟数据结构。假设有a-f的六个节点经过哈希计算后分布在这个哈希环上。那么哈希环的示意图如图1所示。

(2)设定物理节点的访问方式

如果有一个sql查询请求，将其sql语句字符串对象作为哈希算法的key值，那么计算后的哈希值便映射到哈希环里的某一个点，如果该点没有对应到某一个物理节点，那么顺着哈希环进行顺时针查找(即查找哈希值比其大的物理节点)，直到第一次找到有映射的物理节点，该节点就是确定的目标节点(即比其哈希值大的最小节点)，如果超过了2¹⁶这个范围却仍然找不到节点，则匹配至第一个物理节点(因为首尾相连，也可以认为是一直进行的顺时针查找)。如果计算的哈希值介于b～c之间，那么匹配到的物理节点即为c节点。如果该哈希值的值大于f，那么则命中a物理节点。

(3)增加节点的处理

假设要增加一个g物理节点，如图2中灰色圆形框所示。

先计算该物理节点的哈希值，将其值对应到哈希环的某一点上。同时，哈希环的访问方式不变，那么此时映射关系将会发生改变的是分布在节点d到节点g之间的哈希值，这一部分哈希值在节点g增加后，会被映射到节点g，而不是原来的节点e。原分布在节点g到节点e之间的哈希值的映射关系不会改变，还是会被映射到节点e。这样的结果是增加一个物理节点之后仅仅一小部分缓存不命中，需要重新建立。尽管应用一致性哈希算法之后，依然会存在节点增加带来的映射关系改变的问题，但是相比于传统哈希取模的方式已经将映射关系改变的情况降到了尽可能的低。

(4)删除节点的处理

假设需要将图2中的节点g删除掉，那么哈希换将会回复到原始哈希环的状态。此时，被映射到节点g上哈希值的缓存必然会不命中，这种情况下，这部分哈希值将会依顺时针被映射到e节点上，这时，所需要重新建立的缓存仅仅是哈希值分布在节点e到节点g部分的哈希值的缓存。所以，删除一个哈希环上的节点所需要重新建立的缓存也比传统哈希取模的方法大大减少。

一致性哈希算法是目前使用得非常广泛的一种负载均衡算法。一致性哈希算法在动态变化的缓存环境中，很好的满足了判定哈希算法好坏的两个因素——平衡性和单调性。

(1)平衡性：平衡性是指所有的缓存空间都应该得到充分的利用，所以好的哈希算法应该能够使哈希结果的分布尽可能的均匀。

(2)单调性：单调性是指原有系统缓存建立稳定之后，系统中又增加了新的缓存节点，此时，已建立好的缓存应该可以被映射到新增的缓存空间中，而不会被映射到原有的缓存空间中。

但是经过以上的背景技术分析研究后，本发明发现，决定使用一致性哈希算法时，还必须确定一致性哈希中所使用的哈希算法，这也是非常关键的一步，决定了环上节点分布的均匀程度，还有算法效率等等因素。

技术实现要素：

本发明所要解决的技术问题在于，提供了一种分布式数据库缓存方法及其哈希环优化。本发明方法整个过程达到了一种对于缓存对象空间进行分配的作用，使得后台多个缓存节点能够协同工作，提高效率。当有新的缓存节点加入到哈希环中的时候，原有的各个node负责的范围并不会产生巨大的变化，新节点仅仅会拆分一个node的原有范围，不会在有新缓存节点加入的时候造成缓存空间的重新分配，避免了系统负载的波动，保证了该机制的稳定性。

为解决上述技术问题，本发明提供了一种分布式数据库的缓存方法，首先用哈希算法求出url固定长度的散列值，然后利用该散列值进行缓存对象的查找的一系列后续操作。

优选地，所述方法进一步包括：利用md5算法进行散列，对所有输入的字符串求得一个128比特的值：将所有url散列在一个[0，2¹²⁸-1]的空间之上，和url进行一对一的映射；将全部[0，2¹²⁸-1]散列范围看成一个环状的结构，[0，2¹²⁸-1]范围内的所有散列值沿着顺时针的方向按照从大到小的顺序排列，整体均匀的分布在哈希环上。

优选地，所述方法进一步包括：每个缓存节点，负责哈希环上的一段范围内对应的所有url，对每个缓存节点的ip值进行哈希计算得到散列值。

优选地，所述方法进一步包括：当用户的请求来了之后，前端代理会获取请求中包含的url，首先计算本条url的散列值，该散列值会在哈希环上对于一个键值，然后沿着哈希环的顺时针方向查找第一个大于该键值的node，前端的代理将会把该http请求定位到刚才查找到的后台缓存服务器上；当有新的缓存节点加入到哈希环中的时候，原有的各个node负责的范围并不会产生巨大的变化，新的缓存节点仅仅会拆分一个node的原有范围，不会在有新缓存节点加入的时候造成缓存空间的重新分配。

优选地，所述方法进一步包括：采用了自决策的虚拟节点迁移互助策略，对分布式代理缓存中各个缓存节点的运行参数进行感知监测，判断是否有局部过热以其他异常，并根据给定的多副本分级管理策略，选择当前负载较低的缓存节点集合作为辅助，分担cache哈希环上负载较高、性能降低的缓存节点所对应的虚拟节点。

优选地，所述自决策的虚拟节点迁移策略，进一步包括：

a.评价缓存服务器状态和服务能力；

b.是选定状态过热，服务能力下降的缓存节点，迁出它们的虚拟节点，同时选定状态正常，服务能力较强的缓存节点，对迁出的节点单进行融合，负担它们的一部分请求负载；

c.对于不同的缓存节点，确定迁移的虚拟节点数。

优选地，所述方法进一步包括：调整哈希环的层数；调整虚拟节点以进行重新平衡；数据迁移。

优选地，所述步骤调整哈希环的层数，进一步包括：如果单位权重的虚拟节点数减少到阈值，则将虚拟节点的层数增加1；如果单位权重的虚拟节点的数量高于阈值，则减小虚拟节点的层；

所述调整虚拟节点以进行重新平衡，进一步包括：在添加新节点或集群中现有节点的删除/故障期间发生重新平衡；

所述步骤数据迁移，进一步包括：将删除虚拟节点中的数据迁移到邻居节点。

为解决上述技术问题，本发明还提供了一种如前述任一项所述分布式数据库缓存方法中的哈希环优化方法，采用了自决策的虚拟节点迁移互助策略，对分布式代理缓存中各个缓存节点的运行参数进行感知监测，判断是否有局部过热以其他异常，并根据给定的多副本分级管理策略，选择当前负载较低的缓存节点集合作为辅助，分担cache哈希环上负载较高、性能降低的缓存节点所对应的虚拟节点；

优选地，所述自决策的虚拟节点迁移策略，进一步包括：

a.评价缓存服务器状态和服务能力；

b.是选定状态过热，服务能力下降的缓存节点，迁出它们的虚拟节点，同时选定状态正常，服务能力较强的缓存节点，对迁出的节点单进行融合，负担它们的一部分请求负载；

c.对于不同的缓存节点，确定迁移的虚拟节点数。

优选地，所述评价缓存服务器状态和服务能力的步骤，进一步包括：评价每个缓存节点在当前所有缓存节点中的繁忙程度，假设后台有n个缓存节点，计算所有节点当前状态的平均值计算公式如下所示：

定义缓存节点的两种状态：(1)对于缓存节点i，如果则为热状态；(2)对于缓存节点i，如果则为正常状态；当缓存集群需要自决策调整的时候，肯定至少有一台缓存节点已经处于热状态了，需要选出哪些处于热状态的缓存节点应该亟需调整，而且需要决策热状态缓存节点上的虚拟节点应该迁移到哪些正常状态的缓存节点上。

本发明有益效果包括：采用了自决策的虚拟节点迁移互助策略，对分布式代理缓存中各个缓存节点的运行参数进行感知监测，判断是否有局部过热以其他异常，并根据给定的多副本分级管理策略，选择当前负载较低的缓存节点集合作为辅助，分担cache哈希环上负载较高、性能降低的缓存节点所对应的虚拟节点，达到了热点迁移，同时也避免了单点故障。通过动态适应，可用性将更高。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是一部分实施例或现有技术，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的类似或相关附图。

图1为本发明背景技术所述哈希环示意图；

图2为本发明背景技术所述哈希环新增节点图；

图3为本发明实施例所述哈希环中虚拟节点与物理节点的对应关系；

图4为本发明实施例所述哈希环中节点数据迁移图；

图5为本发明实施例所述多层一致的哈希环示意图；

图6为本发明实施例所述创建虚拟节点示意图；

图7为本发明实施例所述分布式代理缓存结构图；

图8为本发明实施例所述基于哈希环的url空间分配图；

图9为本发明实施例所述虚拟节点的迁移互助图。

具体实施方式

下面结合实施例详述本发明。为使本发明的目的、技术方案及优点更加清楚、明确，以下对本发明进一步详细说明，但本发明并不局限于这些实施例。

如果仅仅是把现有的物理节点分布到哈希环上，那么很有可能会出现物理节点在哈希换上分布不均匀的情况，而这种情况对后续的缓存是否分布均匀也会有非常大的影响，从而造成负载不均衡的结果。

在本发明的一个实施方式中，为解决平衡性问题，本发明在哈希环中加入了一个“虚拟节点”的概念。虚拟节点，简单直白的理解就是物理节点在哈希环上的一些复制品，而非实际存在的节点，一般会根据实际情况来决定一个物理节点对应的虚拟节点的个数。虚拟节点与物理节点在哈希环上排列方式、访问方式都一样。而引入虚拟节点之后，每当增加物理节点，哈希环上便需要增加相应个数的虚拟节点，如果是删除物理节点，那么相反的需要在哈希环上删除所对应所有的虚拟节点。

在图3中，节点a-l表示12个虚拟节点，节点1-4表示4个物理节点，每三个虚拟节点对应一个物理节点。sql字符串对象计算得出的哈希值先对应到环上某一节点，然后按哈希环的访问方式找到对应的虚拟节点，然后再映射带物理节点。而集群中节点的数量越多，一致性哈希算法的平衡性效果越好，所以在引入虚拟节点之后，哈希环上的节点数量大大增加，从而会使一致性哈希算法的平衡性效果更好。

hash算法具有三大优点：单向性，抗冲突性，分布均匀性。一致性hash算法更是当前分布式负载均衡和存储均衡最常采用的算法。该算法的实现方法，通过hash函数对机器节点取值，将机器节点映射到0～2³²的空间里。数据存储时，将数据块先进行hash计算得到hash值，然后根据hash值对应到环中的某个位置。如图4左图数据object1，计算出hash值key1，然后沿顺时针找到一个机器节点node1，将object1存储到node1这个节点中。

如果node2节点宕机了，则node2上的数据就会迁移到node3节点上。这样的好处是即使某个节点坏掉，其它节点的数据访问仍然可用使用hash算法进行快速定位，只会影响到邻近节点。

一致性散列在分布式系统中广泛使用，包括分布式数据库。它提供了将密钥映射到环周围的特定节点的模式。但是，现有的一致哈希方法不能保证数据的准确平衡。例如：扩展时，新添加的节点将仅共享相邻节点的工作负载。从系统中删除节点后的相同情况。这将在删除节点或添加节点后导致不平衡状态。

另外，考虑到分布式系统中节点的容量在开始时并不总是平衡，要将整个集群转为平衡状态并不容易。在本发明前一实施方式，图3设计的方法中，呈现虚拟节点以将一个物理节点映射到多个虚拟节点以保持平衡。但是，图3方法没有考虑属于同一物理节点的虚拟节点的关系。一旦一个物理节点关闭，就有可能出现数据雪崩的情况。

因此，如图5所示，在本发明另一实施方式中，我们的想法是为分布式数据库创建和使用多层一致的哈希环，并包括：

根据容量和规则计算物理节点的权重。

构造第一个散列环并为物理节点分配不同的权重。

为某些物理节点构建第二个散列环，其中第二个散列环具有更多容量，第二个散列环中的节点是虚拟节点。

如果某些虚拟节点存在不平衡，则构造更多的散列环。

最后，构造多层一致的哈希环。

使用多层散列来定位和访问环中的数据。

一旦节点出现故障，直接绕过非第一层节点，以加速重新平衡。

(一)哈希环启动

在本实施例哈希环启动过程中，根据规则和容量计算每个物理节点的权重，例如存储大小，存储类型，存储时间，存储风险等。

在实施例中，为简化说明起见，我们只使用存储大小作为一个主要因素。但是，可以根据需要指定规则和其他因素。

根据不同物理节点的权重，定义不同的虚拟节点，并生成多层散列环。现实数据处理中，也可能只有一些物理节点的第一层，并且没有第二层和更多层。

(二)创建虚拟节点

在创建虚拟节点期间确保每个虚拟节点的容量大小相同。每个物理磁盘的虚拟节点数取决于权重。虚拟节点和物理节点之间的映射关系将作为元数据记录在映射表中。

如果虚拟节点的数量不够大，则会破坏一致哈希的平衡。因此，应考虑虚拟节点的最低阈值有多级索引来记录每一层哈希环中的节点。

(三)调整哈希环的层数

调整规则是：如果单位权重的虚拟节点数减少到阈值，则将虚拟节点的层数增加1。

另一方面，如果单位权重的虚拟节点的数量高于阈值，则减小虚拟节点的层。

(四)调整虚拟节点以进行重新平衡

在添加新节点或集群中现有节点的删除/故障期间可能发生重新平衡。

在添加节点期间：

-重新计算第一个散列环中所有节点的权重；

-为新添加的节点构造第二层或更多层的散列环；

-将新数据添加到新添加的节点中，并将一些现有数据移动到新添加的节点。

在删除节点期间：

-如果检测到节点出现故障，直接绕过第二层或更高层的所有虚拟节点，这样可以防止大量不必要的节点重定向；

-故障节点中的所有数据将移动到相邻的散列环。

(五)数据迁移：

为了重新平衡，应该将删除虚拟节点中的数据迁移到邻居节点。如果新添加的节点将在一致的hash圈中找到与删除相同的位置。迁移仅在节点之间发生。

最后，如何发现：

通过检查数据结构和数据流，并查看是否存在多层一致的哈希环。

通过检查用户手册和系统行为。

在本发明另一实施方式中，公开了一种哈希环存储机制：分布式代理缓存的结构。如图7所示，一个前端的代理服务器需要管理众多的后台缓存服务器节点，当前端的代理服务器接收到用户的请求时候，会去后台的缓存服务器上获取请求的数据，缓存服务器首先在本地缓存空间查找对应的web内容，如果查找到了，则返回给前端代理服务器；如果没有查找到对应的web内容，则首先会去请求的原始web服务器上取得内容，然后发给前端代理服务器web内容的同时也会在本地存储一份缓存对象的副本，以便加速后续的请求响应时间。

在分布式代理缓存中，网络用户的所有的http请求会经过代理之后分发到各个缓存之上，由于有后台多个缓存节点的存在，相比于单机的缓存，缓存空间和缓存内容将会大幅度的增加，前台代理的响应时间也会随着减少，从而使得整体的性能得到了提高。显然，后台的多个缓存节点如果均存储相同的内容，上述的优势将会大大折扣，只有将整个缓存副本的空间分配到这些缓存节点上才能保证性能的提升。

对于用户的http请求，其中最有用的信息就是url，该url也是后续缓存节点进行内容查找的依据，所以容易想到利用url来进行缓存空间的划分，但是url长度千差万别，不作处理直接使用的话难度很大。针对种问题，可以首先用特定的hash算法求出url固定长度的散列值，然后利用该散列值进行缓存对象的查找的一系列后续操作。本发明提出了一种基于hash机制来进行在多个缓存节点之间分配整个url的空间，也即整个缓存的空间。具体来说，本发明中利用md5算法进行散列，该算法会对所有输入的字符串求得一个128比特的值，即将所有url会散列在一个[0，2¹²⁸-1]的空间之上。考虑到实际的url数目，该空间范围足够包含所有的内容，可以和url进行一对一的映射。

为了方便url路由机制的实现，如图8所示，将整个[0，2¹²⁸-1]散列范围看成一个环状的结构，[0，2¹²⁸-1]范围内的所有散列值沿着顺时针的方向按照从大到小的顺序排列，整体均匀的分布在了哈希环之上。对于图7中的每个缓存节点，应当负责哈希环上的一段范围，也即该范围内对应的所有url。对每个缓存节点的ip值进行哈希得到散列值，正如图中node1到node4代表四个缓存节点，node1和node2之间的范围就是缓存节点2应该负责的url范围，其他的以此类推。值得注意的是，node3对应的范围跨越了最大值并且从最小值开始，这正是哈希环的优势所在，足以覆盖环上的所有范围。当用户的请求来了之后，前端代理会获取请求中包含的url，首先计算本条url的散列值，该散列值会在哈希环上对于一个键值，正如图8所示，然后沿着哈希环的顺时针方向查找第一个大于该键值的node，此node代表着实际环境中的一个缓存服务器，所以前端的代理将会把该http请求定位到刚才查找到的后台缓存服务器上。整个过程达到了一种对于缓存对象空间进行分配的作用，使得后台多个缓存节点能够协同工作，提高效率。同时注意到，该方法还有一个特点，当有新的缓存节点node5加入到哈希环中的时候，原有的各个node负责的范围并不会产生巨大的变化，node5仅仅会拆分一个node的原有范围，不会在有新缓存节点加入的时候造成缓存空间的重新分配，避免了系统负载的波动，保证了该机制的稳定性。

虽然哈希环的存储机制运用在缓存管理上有许多优势，但是，却存在一个问题，由于md5散列算法固有的性质，无法保证各个真实缓存节点ip进行散列后能够均匀分布在整个哈希环之上。正如图8所示，node1和node5的负责范围就差异很大，显然范围大的接收http请求的概率就高，反之亦然。在请求数量比较多的情况下，这会导致各个缓存节点的缓存负载任务不均，而且想要调节各个缓存节点的负载也不容易，除非重新散列各个缓存节点，这显然不可行，代价太大。改进md5算法对于该问题的解决帮助也不大，因为随机性是散列算法的一大特点，无法使得ip散列后具有某种均匀间隔分布的性质。

上述问题产生分根本原因就是每个缓存节点在哈希环上仅仅对应了一个node，所以在哈希环上引入了虚拟节点的思想来解决缓存空间分布不均的问题。也就是采用多级哈希环的机制，一个物理节点对应多个虚拟节点。虚拟节点的思想核心是，每个缓存服务器出了在哈希环上对已一个node节点之外，还会对应许多虚拟节点v-node，node和v-node负责的所有范围就是真实缓存服务器分配的缓存url空间，路由查询机制没有任何变化。三个真实的缓存节点对应了cache哈希环上的nodel、node2、node3，这样，每个缓存节点在哈希环之上将存在多个副本，由于散列的随机性，这些副本将会更加均匀分割整个url空间。每一个缓存节点在cache哈希环上面产生的虚拟节点v-node数目根据其服务能力计算得出，服务能力强的缓存对应的虚拟节点数目多，覆盖的url范围就广，从而被前端代理分配到的用户请求就多；反之亦然。举个例子，node1会被映射成v-node1a，v-node1b，而node2会被映射成v-node2a，v-node2b，node3被映射成v-node3a，v-node3b，v-node3c。

每台缓存节点的虚拟节点数目和其当前的服务能力密切相关。为了使得分布式代理缓存系统自主感知系统运行状况，之后自主决策模块预测未来缓存节点的运行状态，综合评价出该缓存节点的服务能力，动态决策哈希环上的虚拟节点分布数目，减少负载过重的缓存节点的虚拟节点数目，将这些虚拟节点重新分配给当前服务性能较强的缓存节点，整个过程如图9所示。

图9采用了自决策的虚拟节点迁移互助策略，对分布式代理缓存中各个缓存节点的运行参数进行感知监测，判断是否有局部过热以其他异常，并根据给定的多副本分级管理策略，选择当前负载较低的缓存节点集合作为辅助，分担cache哈希环上负载较高、性能降低的缓存节点所对应的虚拟节点，达到了热点迁移，同时也避免了单点故障。自决策的虚拟节点迁移互助本质上的是要解决三个问题，一是评价缓存服务器状态和服务能力；二是选定状态过热，服务能力下降的缓存节点，迁出它们的虚拟节点，同时选定状态正常，服务能力较强的缓存节点，对迁出的节点单进行融合，负担它们的一部分请求负载；三是对于不同的缓存节点，迁移的虚拟节点数目的确定。

对于缓存服务器状态和服务能力的评价，感知监测部分经过综合加之后得到了它就代表了该缓存节点的当前状态和服务能力。越大，代表该缓存节点越繁忙，可用的服务能力越小；越小，代表该缓存节点越空闲，可用的服务能力越大。

由于在分布式的代理缓存中，后台拥有许多的缓存节点，所以每次自主决策部分将会收到许多缓存节点的状态值。为了评价每个缓存节点在当前所有缓存节点中的繁忙程度，假设后台有n个缓存节点，计算所有节点当前状态的平均值计算公式如下公式1所示：

定义缓存节点的两种状态：(1)对于缓存节点i，如果则为热状态；(2)对于缓存节点i，如果则为正常状态。当缓存集群需要自决策调整的时候，肯定至少有一台缓存节点已经处于热状态了，需要选出哪些处于热状态的缓存节点应该亟需调整，而且需要决策热状态缓存节点上的虚拟节点应该迁移到哪些正常状态的缓存节点上。

首先，定义处于包含所有热状态的缓存节点集合为h，且n1＝|h|；包含所有正常状态的缓存节点集合为n，且n2＝|n|，那么它们满足公式2：

n1+n2＝|h|+|n|＝n公式2

其次，对h中的所有元素按照状态值的降序进行排列，得到了序列sh，该序列代表了所有热状态缓存节点繁忙程度的一个顺序，越靠前的元素，表示该缓存节点越繁忙，可用服务能力下越小，其公式3如下：

sh＝{sh。1，sh。2...sh。i...}(sh。i≥sh。(i+1)且i＝1，2，...，n1)公式3

接下来，对n中的所有元素按照状态值的升序进行排列，得到了序列sn，序列中越靠前的缓存节点越空闲，服务能力越高，其公式4如下：

sn＝{sn。1，sn。2...sn。i..}(sn。i≤sn。(i+1)且i＝1，2，...，n2)公式4

显然，如果只对sh中第一个元素，也就是状态值最大的缓存节点进行调整，每次的调整效果仅仅局限于一个缓存节点，而且没有考虑到元素中最大和次大的状态值差异很小的情况；如果对sh中全部元素的虚拟节点进行调整，开销很大，而且很多节点热的程度较小，没有必要调整。综合考虑，从序列sh的第一个元素开始选取的一个前缀子序列，这个前缀子序列将是最需要调整的热状态缓存节点，因为它们的状态值相对很高，已经处于较繁忙的状态，服务能力已经开始下降。

定义sh中最终求得的前缀子序列为ssub-h，前缀子序列初始为计算该序列的方法如下：

(1)如果|sh|≤2，那么sh-＝ssub-h，即选取所有元素，过程结束；

(2)如果|sh|＞2，首先将shol和sho2两个元素加入中；

(3)假设shoi之前的元素已经都加入了ssub-h中，如果shoi满足如下条件，则将shoi加入ssub-h，条件表达如公式5：

(4)如果shoi满足(3)中的条件表达公式5，那么对于sh中的下一个元素sho(i+1)，重复(3)中的判断；如果不满足条件表达公式5，则整个选择过程结束。

公式5对sh序列中的元素间隔差进行了判断，最终选取了sh的一个前缀子序列，该前缀子序列ssub-h由sh前面间隔最小的元素组成，这些元素统一归属于最热的一类缓存节点，也即本次需要调整的缓存节点集合。选取了ssub-h之后，需要从sn确定中确定一个对应的互助的缓存节点集合，该集合中的缓存节点将会融合ssub-h中热状态缓存节点的虚拟节点。公式5已经假设了n2＝|sn|，对于ssub-h中的一个热状态缓存节点ssub-hoi，它对应的互助空闲缓存节点为snoi，其中j＝i％n2。

以上所述，仅是本发明的几个实施例，并非对本发明做任何形式的限制，虽然本发明以较佳实施例揭示如上，然而并非用以限制本发明，任何熟悉本专业的技术人员，在不脱离本发明技术方案的范围内，利用上述揭示的技术内容做出些许的变动或修饰均等同于等效实施案例，均属于本发明技术方案保护范围内。