sql >> Database >  >> NoSQL >> Redis

Laravel + predis + Redis cluster - VERPLAATST / geen verbinding naar 127.0.0.1:6379

TL;DR:

  • 'cluster' => true moet waar zijn om één geaggregeerde client te maken die meerdere knooppunten afhandelt.
  • 'options' => ['cluster' => 'redis'] moet aan de configuratie worden toegevoegd als een broer of zus van default (geen kind) om Predis te vertellen om de server-side clustering van Azure af te handelen.
  • bij gebruik van auth met server-side clustering, 'options' => [ 'cluster' => 'redis', 'parameters' => ['password' => env('REDIS_PASSWORD', null)], ] is nodig om nieuw ontdekte clusterknooppunten te verifiëren.

Volledige tekst

In de redis-configuratie kunt u meerdere verbindingen met meerdere redis-instanties instellen. Het cluster optie vertelt Laravel hoe deze meerdere gedefinieerde verbindingen moet worden afgehandeld.

Als cluster is ingesteld op false , maakt Laravel individuele \Predis\Client instanties voor elke verbinding. Elke verbinding is afzonderlijk toegankelijk en heeft geen enkele relatie met een andere verbinding.

Als cluster is ingesteld op true , maakt Laravel een geaggregeerde \Predis\Client instantie met behulp van alle gedefinieerde verbindingen. Zonder andere configuratie is dit een soort "nep"-cluster. Het maakt gebruik van client-side sharding om de sleutelruimte te verdelen en kan externe monitoring en onderhoud vereisen om een ​​juiste sleutelbelastingsbalans te garanderen.

Het probleem waar u echter tegenaan loopt, is dat Azure (vermoedelijk) een echt Redis-cluster aan de serverzijde implementeert, dat automatische sharding van de keyspace afhandelt. In dit geval weten de knooppunten van elkaar en praten ze met elkaar, en kunnen ze op en neer gaan. Dit is waar MOVED en ASK reacties komen van.

De Predis bibliotheek kan deze reacties automatisch afhandelen, maar alleen als u aangeeft dat dit nodig is. In dit geval moet u de Predis . vertellen client die het nodig heeft om clustering af te handelen, en dit wordt gedaan door Laravel via de options array op de redis configuratie.

Op de redis configuratie, de options sleutel moet een broer of zus zijn van je connecties (d.w.z. default ), geen kind. Bovendien moeten de opties worden gespecificeerd als key => value paren.

Uw configuratie zou er dus als volgt uit moeten zien:

'redis' => [
    'cluster' => true,

    'default' => [
        'host' => env('REDIS_HOST', 'localhost'),
        'password' => env('REDIS_PASSWORD', null),
        'port' => env('REDIS_PORT', 6379),
        'database' => 0,
    ],

    'options' => [
        'cluster' => 'redis',
    ],
],

Het cluster sleutel onder de redis config zal Laravel vertellen om een ​​geaggregeerde Predis\Client te maken instantie die meerdere knooppunten kan verwerken, en de cluster toets onder de options array zal die instantie vertellen dat het server-side clustering moet afhandelen, niet client-side clustering.

Autorisatie

De oorspronkelijke verbindingsparameters (inclusief authenticatie) worden niet gedeeld met verbindingen naar nieuwe nodes die zijn ontdekt via -MOVED en -ASK reacties. Dus alle fouten die u eerder kreeg van -MOVED reacties worden nu gewoon omgezet in NOAUTH fouten. Echter, de server-side 'cluster' configuratie zorgt voor een 'parameters' broer of zus die een lijst met parameters definieert die moeten worden gebruikt met nieuw ontdekte knooppunten. Hier kunt u uw auth-parameters gebruiken voor nieuwe nodes.

Ik denk dat dit er ongeveer zo uit zal zien:

'redis' => [
    'cluster' => true,

    'default' => [
        'host' => env('REDIS_HOST', 'localhost'),
        'password' => env('REDIS_PASSWORD', null),
        'port' => env('REDIS_PORT', 6379),
        'database' => 0,
    ],

    'options' => [
        'cluster' => 'redis',
        'parameters' => ['password' => env('REDIS_PASSWORD', null)],
    ],
],

Eerlijke waarschuwing, dit is alle informatie die ik net heb gekregen van onderzoek en codeduiken. Hoewel ik Redis met Laravel heb gebruikt, heb ik (nog) geen server-side clustering gebruikt, dus dit werkt mogelijk nog steeds niet.

Enkele nuttige stukjes informatie die ik tegenkwam toen ik dit onderzocht:

Predis-probleem over verbinding maken met een redis-cluster:
https://github.com/nrk/predis/issues/259#issuecomment-117339028

Het lijkt erop dat u Predis niet hebt geconfigureerd om redis-cluster te gebruiken, maar in plaats daarvan gebruikt u het met de gewone oude sharding-logica aan de clientzijde (wat ook het standaardgedrag is). U moet de client configureren door het optiecluster in te stellen met de waarde redis om de client te laten weten dat deze moet meespelen met redis-cluster. Snel voorbeeld:

$client = new Predis\Client([$node1, $node2, ...], ['cluster' => 'redis']);

Als u dit doet, kan de client automatisch -MOVED- of -ASK-antwoorden van Redis-knooppunten afhandelen.

MS-artikel over clustering op redis-cache:
https://docs.microsoft.com/en-us/azure/redis-cache/cache-how-to-premium-clustering#how-do-i-connect- naar-mijn-cache-wanneer-clustering-is-enabled

U kunt verbinding maken met uw cache met dezelfde eindpunten, poorten en sleutels die u gebruikt wanneer u verbinding maakt met een cache waarvoor clustering niet is ingeschakeld. Redis beheert de clustering op de backend, zodat u deze niet vanaf uw client hoeft te beheren.

Laravel-code voor het maken van Predis\Client instanties:
https://github.com/laravel/framework/blob/v5.3.28/src/Illuminate/Redis/Database.php#L25-L66



  1. MongoDB - admin-gebruiker niet geautoriseerd

  2. Als redis al deel uitmaakt van de stapel, waarom wordt Memcached dan nog steeds naast Redis gebruikt?

  3. Update geneste array-objecten op basis van een eigenschap in MongoDB

  4. vakbond op dezelfde collectie in mongodb