如何在Jedis中启用负载平衡？

Question

我想将Jedis用于Redis群集或仅用于Redis服务器。我想知道如何启用Round Robin进行读取操作。使用带有Sentinel的Redis群集或Redis服务器并不重要。我将拥有几位大师，每位大师都拥有它自己的奴隶。如何在特定散列槽（或特定分片）的所有从属中分配读取操作？

Answer 1

负载平衡是分布式系统中非常重要的问题。一个考虑因素是定义负载均衡意味着什么。

如果我们只考虑负载分布不均匀的内在因素，可以在三个镜头下检查IMKVS中的负载平衡机制：

1. 基于密钥流行度的负载均衡：调用特定项目的频率似乎与IMKVS节点和系统的性能有关。

2. 基于密钥分发的负载均衡：在许多系统中，可用节点中密钥的分配本质上构成了负载平衡挑战。与前一个问题以及基础节点的功能隔离开来的问题检查可能存在风险，但即使仅基于统计数据，它在实施方面也要简单得多。

3. 基于查询量的负载平衡：从IMKVS部署并因此从节点同时请求的密钥量似乎是某些负载平衡部署中感兴趣的度量标准。

总而言之，调查负载平衡问题需要至少检查这些因素：

• 传入查询的频率

• 传入查询量

• 密钥在系统中的分发方式

• 密钥长度和值长度

<强>实验

根据我的实验：

• 获取一个特定密钥的响应时间（RT）几乎没有变化，如 节点中更改的键数。
• 随着密钥长度的增加，RT迅速增长。
• 值的卷之间的响应时间的差异是 无意义，因此价值大小不会影响RT。
• RT的增长率与客户来电的数量成正比。

密钥的分配在负载平衡因素中起着重要作用。因此，在上一个实验中，我的目标是观察Redis Cluster中密钥从一个节点迁移到另一个节点的响应时间如何变化。为了实验的需要，我在一个主（M1）节点加载了33000，在另一个主（M2）中加载了0。我在M1中进行了4次并发客户端调用，我在时间7开始迁移，并在时间36停止。



Ι观察到4个并发客户端呼叫的RT平均为25毫秒。在迁移过程开始时，响应时间突然增加，而在过程结束时，我们注意到数量级减少了9ms。这一改进表明速度提高了3倍。尖峰是由于 迁移命令的开销。该命令实际上执行DUMP + DEL 源实例中的操作，以及目标nstance中的RESTORE操作。因此，很明显，密钥从一个重负载节点迁移到 另一个响应时间显着减少。

从上面可以看出，随着节点间读取请求的分配，无法确定Redis中是否存在负载分配（平衡），因为结果显示： < / p>

• 关键受欢迎程度和价值量等因素似乎都很小 效果

• 密钥分配和密钥长度是导致负载的因素 平衡问题并影响集群的RT

• 可以通过将密钥从一个节点迁移到另一个节点来减少RT 这样，集群中的每个节点都具有相同数量的密钥

因此，您需要创建组合所有这些因素的机制。您可以从一个算法开始，该算法在节点之间分配密钥。

算法的步骤如下：

1. 找到主人群

2. 获取他们持有的密钥总数

3. 对于每个主节点，存储主机名，端口和密钥数

4. 计算每个主人必须持有的密钥，以便平衡密钥的分配（群集的总密钥/主人的数量）

5. 查找哪些主节点必须占用或提供密钥以及必须提供/获取的密钥总数

6. 根据主服务器是分别接收还是赠送密钥，将主服务器表征为源节点或目标节点

7. 开始从源节点迁移到目标节点，首先是hashslots，然后是相关的密钥并迭代，直到所有主服务器具有相同数量的密钥

然后你可以创建下一个算法，以便创建一个提供LB的机制，以便最小化RT。

注意：我将在半年内在论文中添加更多信息，并在算法实施时链接到Github。

链接到纸张： https://www.researchgate.net/publication/309732099_Load_Balancing_in_In-Memory_Key-Value_Stores_for_Response_Time_Minimization