我想使用Jedis for Redis集群或仅用于Redis服务器 . 我想知道如何启用Round Robin进行读取操作 . 无论我将使用具有Sentinel的Redis群集或Redis服务器 . 我将拥有几个主人，每个主人都拥有自己的奴隶 . 如何在特定散列槽（或特定分片）的所有从属中分配读取操作？
负载 balancer 是分布式系统中非常重要的问题 . 一个考虑因素是定义负载 balancer 的含义 .
如果我们只考虑不均匀负载分布的内在因素，可以在三个镜头下检查IMKVS中的负载 balancer 机制：
基于密钥流行度的负载 balancer ：调用特定项目的频率似乎与IMKVS节点和系统的性能有关 .
基于密钥分发的负载均衡：在许多系统中，可用节点中密钥的分配本质上构成了负载 balancer 挑战 . 单独检查问题与之前以及基础节点的功能相比可能存在风险，但即使仅基于统计数据，它在实现方面也要简单得多 .
基于查询量的负载 balancer ：从IMKVS部署并因此从节点同时请求的密钥量似乎是某些负载 balancer 部署中感兴趣的度量 .
总而言之，调查负载 balancer 问题需要至少检查以下因素：
传入查询的频率
传入查询量
密钥在系统中的分配方式
密钥长度和值长度
Experiments
根据我的实验：
获取一个特定密钥的响应时间（RT）几乎没有改变，因为节点中的密钥数量发生了变化 .
随着密钥长度的增加，RT迅速增长 .
值之间的响应时间差异无关紧要，因此值大小不会影响RT .
RT的增长率与客户呼叫的数量成正比 .
密钥的分配在负载 balancer 因子中起着重要作用 . 因此，在上一个实验中，我的目标是观察Redis Cluster中密钥从一个节点迁移到另一个节点的响应时间如何变化 . 为了实验的需要，我在一个主（M1）节点加载了33000，在另一个主（M2）中加载了0 . 我在M1中进行了4次并发客户端调用，我在时间7开始迁移，并在时间36停止 .
Ι观察到4个并发客户端呼叫的RT平均为25毫秒 . 在迁移过程开始时，响应时间突然增加，而在过程结束时，我们注意到数量级减少了9ms . 这一改进表明速度提高了3倍 . 峰值是由于迁移命令的开销造成的 . 此命令实际上在源实例中执行DUMP DEL操作，并在目标nstance中执行RESTORE操作 . 因此，很明显，通过将密钥从一个重负载节点迁移到另一个重负载节点，响应时间显着减少 .
From the above, it is clear that with the distribution of read requests among nodes, it is no certain that you will have a load distirbution (balancing) in Redis because the results show that:
关键受欢迎程度和 Value 量等因素似乎影响不大
密钥分配和密钥长度是导致负载 balancer 问题的因素，并影响集群的RT
可以通过将密钥从一个节点迁移到另一个节点来减少RT，这样群集中的每个节点都具有相同数量的密钥
因此，您需要创建一个 combines 所有这些因素的机制 . 您可以从一个算法开始，该算法在节点之间分配密钥 .
算法的步骤如下：
寻找主人群
获取他们持有的密钥总数
对于每个主节点，存储主机名，端口和密钥数
计算每个主机必须保持的键，以便 balancer 键的分布（簇的总键数/主站数）
查找哪些主节点必须采用或给出密钥以及必须提供/获取的密钥总数
将主服务器表征为源节点或目标节点，具体取决于它们是分别接收还是赠送密钥
开始从源节点迁移到目标节点，首先是哈希点，然后是相关的密钥并迭代，直到所有主服务器具有相同的数量按键
然后你可以创建下一个算法，以创建一个提供LB的机制，以便最小化RT .
注意：我将在半年内在论文中添加更多信息，以及使用我的算法实现链接到Github .
链接到纸张：https://www.researchgate.net/publication/309732099_Load_Balancing_in_In-Memory_Key-Value_Stores_for_Response_Time_Minimization
1 回答
负载 balancer 是分布式系统中非常重要的问题 . 一个考虑因素是定义负载 balancer 的含义 .
如果我们只考虑不均匀负载分布的内在因素，可以在三个镜头下检查IMKVS中的负载 balancer 机制：
基于密钥流行度的负载 balancer ：调用特定项目的频率似乎与IMKVS节点和系统的性能有关 .
基于密钥分发的负载均衡：在许多系统中，可用节点中密钥的分配本质上构成了负载 balancer 挑战 . 单独检查问题与之前以及基础节点的功能相比可能存在风险，但即使仅基于统计数据，它在实现方面也要简单得多 .
基于查询量的负载 balancer ：从IMKVS部署并因此从节点同时请求的密钥量似乎是某些负载 balancer 部署中感兴趣的度量 .
总而言之，调查负载 balancer 问题需要至少检查以下因素：
传入查询的频率
传入查询量
密钥在系统中的分配方式
密钥长度和值长度
Experiments
根据我的实验：
获取一个特定密钥的响应时间（RT）几乎没有改变，因为节点中的密钥数量发生了变化 .
随着密钥长度的增加，RT迅速增长 .
值之间的响应时间差异无关紧要，因此值大小不会影响RT .
RT的增长率与客户呼叫的数量成正比 .
密钥的分配在负载 balancer 因子中起着重要作用 . 因此，在上一个实验中，我的目标是观察Redis Cluster中密钥从一个节点迁移到另一个节点的响应时间如何变化 . 为了实验的需要，我在一个主（M1）节点加载了33000，在另一个主（M2）中加载了0 . 我在M1中进行了4次并发客户端调用，我在时间7开始迁移，并在时间36停止 .
Ι观察到4个并发客户端呼叫的RT平均为25毫秒 . 在迁移过程开始时，响应时间突然增加，而在过程结束时，我们注意到数量级减少了9ms . 这一改进表明速度提高了3倍 . 峰值是由于迁移命令的开销造成的 . 此命令实际上在源实例中执行DUMP DEL操作，并在目标nstance中执行RESTORE操作 . 因此，很明显，通过将密钥从一个重负载节点迁移到另一个重负载节点，响应时间显着减少 .
From the above, it is clear that with the distribution of read requests among nodes, it is no certain that you will have a load distirbution (balancing) in Redis because the results show that:
关键受欢迎程度和 Value 量等因素似乎影响不大
密钥分配和密钥长度是导致负载 balancer 问题的因素，并影响集群的RT
可以通过将密钥从一个节点迁移到另一个节点来减少RT，这样群集中的每个节点都具有相同数量的密钥
因此，您需要创建一个 combines 所有这些因素的机制 . 您可以从一个算法开始，该算法在节点之间分配密钥 .
算法的步骤如下：
寻找主人群
获取他们持有的密钥总数
对于每个主节点，存储主机名，端口和密钥数
计算每个主机必须保持的键，以便 balancer 键的分布（簇的总键数/主站数）
查找哪些主节点必须采用或给出密钥以及必须提供/获取的密钥总数
将主服务器表征为源节点或目标节点，具体取决于它们是分别接收还是赠送密钥
开始从源节点迁移到目标节点，首先是哈希点，然后是相关的密钥并迭代，直到所有主服务器具有相同的数量按键
然后你可以创建下一个算法，以创建一个提供LB的机制，以便最小化RT .
注意：我将在半年内在论文中添加更多信息，以及使用我的算法实现链接到Github .
链接到纸张：https://www.researchgate.net/publication/309732099_Load_Balancing_in_In-Memory_Key-Value_Stores_for_Response_Time_Minimization