Em primeiro lugar, você pode alterar a configuração padrão se fizer pouco trabalho no
redis-trib.rb
na função
def check_create_parameters . Você pode definir uma réplica mestre e uma réplica escrava. A finalidade dessa configuração é a tolerância a falhas. Os escravos também podem ser usados para leitura (READONLY). Nos três mestres, os hashslots são distribuídos igualmente e com um algoritmo de balanceamento de carga você pode redistribuir e as chaves reais. Os passos de um possível algoritmo que distribui as chaves entre os nós são (testado por mim e funciona como esperado):
- Encontre a multidão de mestres
- Obter o número total de chaves que eles possuem
- Para cada nó mestre, armazene o nome do host, a porta e o número de chaves
- Calcule as chaves que cada mestre deve conter para que a distribuição das chaves seja balanceada (total de chaves do cluster/número de mestres)
- Encontre quais nós mestres devem receber ou fornecer chaves e a quantidade total de chaves que eles devem fornecer/receber
- Caractere os mestres como nós de origem ou destino, dependendo se eles estão recebendo ou distribuindo chaves, respectivamente
- Comece a migrar do nó de origem para os nós de destino, primeiro os slots de hash e depois as chaves relevantes e itere até que todos os mestres tenham a mesma quantidade de chaves
Este algoritmo ajudará a minimizar o tempo de resposta. O que eu quero dizer:
Com três mestres o tempo de resposta pode ser minimizado. Se você tem uma configuração com um mestre e este mestre contém, por exemplo, 30.000 #chaves, o tempo de resposta para obter 1.000 chaves de uma vez é> de uma configuração com 2 mestres que contém 15.000 cada.
Se você criar uma chave em master1, se tentar alcançar (ler) essa chave em master2, receberá um erro MOVED. Assim, a solução é criar um cliente inteligente que mapeie os hashslots para o nó correspondente. Assim, você pode excluir a chave de master2 apenas no caso de master2 redirecionar sua solicitação para o master correto.
Espero que ajude.
