{"id":91846,"date":"2020-08-19T19:41:57","date_gmt":"2020-08-19T17:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster"},"modified":"2020-08-19T19:41:57","modified_gmt":"2020-08-19T17:41:57","slug":"o-pereezde-s-redis-na-redis-cluster","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","title":{"rendered":"Transizione da Redis a Redis-cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Transizione da Redis a Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/ea8bc47f73ef3b06ccfdf94d323592bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quando si entra in un prodotto che si sviluppa da oltre dieci anni, non sorprende trovare tecnologie obsolete. Ma cosa succede se tra sei mesi devi sostenere un carico dieci volte maggiore e i costi delle interruzioni aumentano di centinaia di volte? In questo caso, hai bisogno di un esperto in Highload davvero capace. Ma in assenza di uno, il problema \u00e8 stato affidato a me. Nella prima parte dell'articolo, racconter\u00f2 come siamo passati da Redis a Redis-cluster e nella seconda parte dar\u00f2 consigli su come iniziare a utilizzare il cluster e a cosa prestare attenzione durante l'uso.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"vybor-tehnologii\">Scelta della tecnologia<\/h1>\n<p><\/p>\n<p>\u00c8 cos\u00ec male <em>un Redis separato<\/em> (redis standalone) in configurazione 1 master e N slave? Perch\u00e9 lo definisco una tecnologia obsoleta?<\/p>\n<p><\/p>\n<blockquote><p>No, Redis non \u00e8 cos\u00ec male... Tuttavia, ci sono alcune carenze che non possono essere ignorate.<\/p><\/blockquote>\n<p><\/p>\n<ul>\n<li>\n<p>In primo luogo, Redis non supporta meccanismi di ripristino in caso di caduta del master. Per risolvere questo problema, abbiamo utilizzato una configurazione con il failover automatico degli VIP su un nuovo master, cambiando il ruolo di uno degli slave e attivando gli altri. Questo meccanismo funzionava, ma non si poteva definire una soluzione affidabile. In primo luogo, si verificavano falsi allarmi e, in secondo luogo, era monouso, e dopo il suo attivamento erano necessarie azioni manuali per riattivarlo.<\/p>\n<p>\n<\/li>\n<li>\n<p>In secondo luogo, avere un solo master portava a un problema di sharding. Era necessario creare pi\u00f9 cluster indipendenti '1 master e N slave', distribuendo manualmente i database su queste macchine e sperando che domani uno dei database non crescesse a tal punto da dover essere spostato su un'istanza separata.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Quali sono le opzioni disponibili?<\/p>\n<p><\/p>\n<ul>\n<li>La soluzione pi\u00f9 costosa e completa \u00e8 Redis-Enterprise. Si tratta di una soluzione confezionata con supporto tecnico completo. Anche se sembra ideale dal punto di vista tecnico, per noi non \u00e8 stata adeguata per motivi ideologici. <\/li>\n<li>Redis-cluster. Support for failover and sharding is included out of the box. The interface is almost indistinguishable from the standard version. It looks promising; we will discuss potential pitfalls later.<\/li>\n<li>Tarantool, Memcache, Aerospike, and others. All these tools do essentially the same thing. However, each has its own drawbacks. We decided not to put all our eggs in one basket. We use Memcache and Tarantool for other tasks, and, to give you a heads up, we have encountered more issues with them in our experience.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"specifika-ispolzovaniya\">Usage specifics<\/h1>\n<p><\/p>\n<p>Let's take a look at the tasks we have historically solved with Redis and the functionalities we utilized:<\/p>\n<p><\/p>\n<ul>\n<li>Cache before requests to remote services like 2GIS | Golang<br \/>\n<blockquote><p>OTTENERE IMPOSTAZIONI MGET MSET \"SELEZIONA DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Cache before MYSQL | PHP<br \/>\n<blockquote><p>OTTENERE IMPOSTAZIONI MGET MSET SCAN \"CHIAVE PER PATRONE\" \"SELEZIONA DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Main storage for the session handling and drivers' coordinates service | Golang<br \/>\n<blockquote><p>OTTENERE IMPOSTAZIONI MGET MSET \"SELEZIONA DB\" \"AGGIUNGI CHIAVE GEO\" \"OTTENERE CHIAVE GEO\" SCAN\n<\/p><\/blockquote>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>As you can see, there's no advanced mathematics involved. So what's the complexity? Let's break down each method individually.<\/p>\n<p><\/p>\n<p>Metodo<br \/>\nDescrizione<br \/>\nFeatures of Redis-cluster<br \/>\nSoluzione<\/p>\n<p>GET SET<br \/>\nWrite\/read a key<\/p>\n<p>MGET MSET<br \/>\nWrite\/read multiple keys<br \/>\nLe chiavi saranno distribuite su diverse nodi. Le librerie pronte sanno eseguire operazioni multi solo all'interno di un singolo nodo.<br \/>\nSostituire MGET con un pipeline di N operazioni GET.<\/p>\n<p>SELEZIONA DB<br \/>\nSelezionare il database con cui lavoreremo.<br \/>\nNon supporta pi\u00f9 database.<br \/>\nConservare tutto in un solo database. Aggiungere prefissi alle chiavi.<\/p>\n<p>SCAN<br \/>\nScorrere tutte le chiavi nel database.<br \/>\nPoich\u00e9 abbiamo un solo database, scorrere tutte le chiavi nel cluster \u00e8 troppo costoso.<br \/>\nMantenere l'invariante all'interno di una singola chiave e fare HSCAN su questa chiave. Oppure rinunciare completamente.<\/p>\n<p>GEO<br \/>\nOperazioni con geochiave.<br \/>\nLa geochiave non \u00e8 sharded.<\/p>\n<p>KEY BY PATTERN<br \/>\nRicerca della chiave per modello.<br \/>\nPoich\u00e9 abbiamo un solo database, cercheremo tra tutte le chiavi nel cluster. Troppo costoso.<br \/>\nRinunciare o mantenere l'invariante, come nel caso di SCAN.<\/p>\n<p><\/p>\n<h1 id=\"redis-vs-redis-cluster\">Redis vs Redis-cluster<\/h1>\n<p><\/p>\n<p>Cosa perdiamo e cosa guadagniamo passando al cluster?<\/p>\n<p><\/p>\n<ul>\n<li>Svantaggi: perdiamo la funzionalit\u00e0 di pi\u00f9 database. \n<ul>\n<li>Se vogliamo memorizzare in un unico cluster dati logicamente non correlati, sar\u00e0 necessario creare 'soluzioni di ripiego' con prefissi. <\/li>\n<li>Perdiamo tutte le operazioni 'per database', come SCAN, DBSIZE, CLEAR DB, ecc.<\/li>\n<li>Le operazioni multiple sono diventate significativamente pi\u00f9 complesse da implementare, poich\u00e9 potrebbe essere necessario fare riferimento a pi\u00f9 nodi.<\/li>\n<\/ul>\n<\/li>\n<li>Vantaggi: \n<ul>\n<li>Resilienza tramite failover del master.<\/li>\n<li>Sharding lato Redis.<\/li>\n<li>Trasferimento atomico dei dati tra nodi e senza tempi di inattivit\u00e0.<\/li>\n<li>Aggiunta e ridistribuzione delle risorse e dei carichi senza interruzioni.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><\/p>\n<p><em>Concluderei che, se non \u00e8 necessario garantire un alto livello di resilienza, non vale la pena migrare a un cluster, poich\u00e9 potrebbe non essere un compito banale. Ma se si deve scegliere tra una versione standalone e una cluster, \u00e8 meglio optare per il cluster, poich\u00e9 non \u00e8 in alcun modo inferiore e allevier\u00e0 parte del vostro mal di testa.<\/em><\/p>\n<p><\/p>\n<h1 id=\"podgotovka-k-pereezdu\">Preparazione per la migrazione<\/h1>\n<p><\/p>\n<p>Iniziamo con i requisiti per la migrazione:<\/p>\n<p><\/p>\n<ul>\n<li>Deve essere senza soluzione di continuit\u00e0. Un'interruzione completa del servizio per 5 minuti non \u00e8 accettabile.<\/li>\n<li>Deve essere il pi\u00f9 sicura e graduale possibile. Vogliamo avere un certo controllo sulla situazione. Non desideriamo caricare tutto in una volta e pregare sul pulsante di rollback.<\/li>\n<li>Minime perdite di dati durante la migrazione. Comprendiamo che sar\u00e0 molto difficile eseguire una migrazione atomica, quindi ammettiamo una certa desincronizzazione tra i dati nel Redis normale e in quello cluster.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"obsluzhivanie-klastera\">Manutenzione del cluster<\/h1>\n<p><\/p>\n<p>Prima di procedere alla migrazione, \u00e8 importante considerare se possiamo mantenere il cluster:<\/p>\n<p><\/p>\n<ul>\n<li>Grafici. Utilizziamo Prometheus e Grafana per il monitoraggio del carico della CPU, della memoria utilizzata, del numero di clienti, delle operazioni GET, SET, AUTH, ecc.<\/li>\n<li>Esperienza. Immagina che domani sar\u00e0 sotto la tua responsabilit\u00e0 un enorme cluster. Se si guasta, nessuno tranne te sar\u00e0 in grado di ripararlo. Se inizia a rallentare, tutti si rivolgeranno a te. Se \u00e8 necessario aggiungere risorse o ridistribuire il carico, sar\u00e0 di nuovo su di te. Per non diventare grigi a 25 anni, \u00e8 preferibile prevedere queste situazioni e testare in anticipo come si comporter\u00e0 la tecnologia in determinate condizioni. Ne parleremo pi\u00f9 dettagliatamente nella sezione 'Esperienza'.<\/li>\n<li>Monitoraggio e notifiche. Quando il cluster si guasta, vogliamo essere i primi a saperlo. Qui ci siamo limitati a notificare che tutti i nodi restituiscono le stesse informazioni sullo stato del cluster (s\u00ec, a volte non \u00e8 cos\u00ec). Altri problemi possono essere notati pi\u00f9 rapidamente tramite le notifiche dei servizi client di Redis.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"pereezd\">Trasferimento<\/h1>\n<p><\/p>\n<p>Come procederemo con il trasferimento:<\/p>\n<p><\/p>\n<ul>\n<li>Innanzitutto, \u00e8 necessario preparare la libreria per lavorare con il cluster. Come base per la versione in Go, abbiamo utilizzato go-redis e abbiamo apportato alcune modifiche. Abbiamo implementato metodi Multi tramite pipeline e abbiamo anche apportato alcune modifiche alle regole di ripetizione delle richieste. Con la versione per PHP ci sono stati pi\u00f9 problemi, ma alla fine abbiamo scelto php-redis. Recentemente hanno implementato il supporto per i cluster, e a nostro avviso funziona bene.<\/li>\n<li>Successivamente, \u00e8 necessario distribuire il cluster stesso. Questo si fa letteralmente con due comandi sulla base di un file di configurazione. Discuteremo ulteriormente la configurazione di seguito.<\/li>\n<li>Per una migrazione graduale utilizziamo la modalit\u00e0 dry. Poich\u00e9 abbiamo due versioni della libreria con lo stesso interfaccia (una per la versione standard, l'altra per il cluster), \u00e8 semplice creare un wrapper che lavori con una versione specifica e al contempo duplichi tutte le richieste nel cluster, confronti le risposte e registri le discrepanze nei log (nel nostro caso su NewRelic). Cos\u00ec, anche se durante il deployment la versione del cluster fallisse, il nostro production non ne risentirebbe. <\/li>\n<li>Dopo aver rilasciato il cluster in modalit\u00e0 dry, possiamo tranquillamente osservare il grafico delle discrepanze nelle risposte. Se la percentuale di errori tende lentamente ma costantemente verso una piccola costante, significa che va tutto bene. Perch\u00e9 ci sono comunque delle discrepanze? Perch\u00e9 la registrazione nella versione separata avviene leggermente prima che nel cluster e, a causa dei micro-lag, i dati possono discostarsi. Resta solo da guardare i log delle discrepanze e, se tutte sono spiegabili con la non-atomicit\u00e0 della registrazione, si pu\u00f2 andare avanti.<\/li>\n<li>Ora \u00e8 possibile invertire il dry-mode. Scriveremo e leggeremo dal cluster, duplicando in una versione separata. Perch\u00e9? Nel corso della prossima settimana vogliamo monitorare il funzionamento del cluster. Se dovessimo riscontrare problemi durante i picchi di carico o se ci fosse qualcosa che abbiamo trascurato, abbiamo sempre un rollback d'emergenza sul codice precedente e sui dati attuali grazie al dry-mode.<\/li>\n<li>Resta da disattivare il dry-mode e smontare la versione separata. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"ekspertiza\">Esperienza<\/h1>\n<p><\/p>\n<p>Iniziamo con una breve panoramica sul funzionamento del cluster.<\/p>\n<p><\/p>\n<p>Per prima cosa, Redis \u00e8 un archivio chiave-valore. Le chiavi sono stringhe arbitrarie. I valori possono essere numeri, stringhe o intere strutture. Ce ne sono molte, ma per comprendere la struttura generale questo non \u00e8 fondamentale.<br \/>\nIl livello di astrazione successivo alle chiavi sono gli slot (SLOTS). Ogni chiave appartiene a uno dei 16.383 slot. All'interno di ciascuno slot possono esserci un numero illimitato di chiavi. In questo modo, tutte le chiavi sono suddivise in 16.383 insiemi non sovrapposti.<br \/>\n<img decoding=\"async\" alt=\"Transizione da Redis a Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/a5e4be23381b42287f693e01d5d59a99.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In un cluster devono esserci N master node. Ogni nodo pu\u00f2 essere visto come un'istanza separata di Redis, che conosce tutto sugli altri nodi all'interno del cluster. Ogni master node contiene un certo numero di slot. Ogni slot appartiene a una sola master node. Tutti gli slot devono essere distribuiti tra i nodi. Se alcuni slot non sono distribuiti, le chiavi memorizzate in essi non saranno accessibili. Ha senso avviare ogni master node su una macchina logica o fisica separata. Inoltre, \u00e8 importante ricordare che ogni nodo funziona solo su un core, e se desideri avviare pi\u00f9 istanze di Redis su una sola macchina logica, assicurati che funzionino su core diversi (non abbiamo provato, ma in teoria dovrebbe funzionare). Fondamentalmente, le master node forniscono una normale partizione, e un numero maggiore di master node consente di scalare le richieste di lettura e scrittura.<\/p>\n<p><\/p>\n<p>Una volta che tutte le chiavi sono distribuite tra i slot e gli slot sono distribuiti tra i master node, \u00e8 possibile aggiungere un numero arbitrario di slave node a ciascun master node. All'interno di ciascuna di queste coppie \"master-slave\", funzioner\u00e0 la replica normale. Gli slave servono per scalare le richieste di lettura e per il failover in caso di malfunzionamento del master.<br \/>\n<img decoding=\"async\" alt=\"Transizione da Redis a Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/90feb7ef9dacb858d5f21edc214df14d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ora parliamo delle operazioni che \u00e8 meglio sapere fare.<\/p>\n<p><\/p>\n<p>Ci riferiremo al sistema tramite Redis-CLI. Poich\u00e9 Redis non ha un unico punto di accesso, le operazioni seguenti possono essere eseguite su qualsiasi nodo. In ogni punto, sottolineo la possibilit\u00e0 di eseguire l'operazione sotto carico.<\/p>\n<p><\/p>\n<ul>\n<li>La prima e pi\u00f9 importante operazione di cui avremo bisogno \u00e8: cluster nodes. Restituisce lo stato del cluster, mostra un elenco dei nodi, i loro ruoli, la distribuzione degli slot, ecc. Ulteriori informazioni possono essere ottenute con cluster info e cluster slots.<\/li>\n<li>\u00c8 importante sapere come aggiungere e rimuovere le nodi. A questo scopo, ci sono le operazioni cluster meet e cluster forget. Si noti che cluster forget deve essere applicato a OGNI nodo, sia ai master che ai replica. Al contrario, \u00e8 sufficiente invocare cluster meet su un solo nodo. Questa distinzione pu\u00f2 essere disorientante, quindi \u00e8 meglio conoscerla prima di mettere in produzione il cluster. L'aggiunta di un nodo viene eseguita in modo sicuro in produzione e non influisce sul funzionamento del cluster (cosa logica). Tuttavia, se si intende rimuovere un nodo dal cluster, \u00e8 fondamentale assicurarsi che non ci siano slot rimasti (altrimenti si rischia di perdere l'accesso a tutte le chiavi su quel nodo). Inoltre, non rimuovere un master che ha slave, altrimenti si attiver\u00e0 una votazione non necessaria per un nuovo master. Se non ci sono pi\u00f9 slot sui nodi, \u00e8 un problema minore, ma perch\u00e9 complicarsi la vita, se si pu\u00f2 prima rimuovere gli slave.<\/li>\n<li>Se \u00e8 necessario scambiare forzatamente master e slave, si pu\u00f2 usare il comando cluster failover. Chiamandolo in azione, \u00e8 importante tenere presente che durante l'esecuzione dell'operazione il master sar\u00e0 inattivo. Di solito, lo switch avviene in meno di un secondo, ma non in modo atomico. Puoi aspettarti che parte delle richieste al master durante questo tempo terminer\u00e0 con un errore.<\/li>\n<li>Prima di rimuovere un nodo dal cluster, non devono rimanere slot. \u00c8 meglio ridistribuirli usando il comando cluster reshard. Gli slot verranno trasferiti da un master all'altro. L'intera operazione pu\u00f2 richiedere alcuni minuti, a seconda della quantit\u00e0 di dati da trasferire, ma il processo di trasferimento \u00e8 sicuro e non influisce sul funzionamento del cluster. Pertanto, \u00e8 possibile trasferire tutti i dati da un nodo all'altro sotto carico, senza preoccuparsi della loro disponibilit\u00e0. Tuttavia, ci sono alcune sottigliezze. In primo luogo, il trasferimento dei dati comporta un certo carico sul nodo destinatario e su quello mittente. Se il nodo destinatario \u00e8 gi\u00e0 molto carico di CPU, non \u00e8 consigliabile sovraccaricarlo anche con l'accettazione di nuovi dati. In secondo luogo, non appena non ci saranno pi\u00f9 slot sul master mittente, tutti i suoi slave passeranno immediatamente al master su cui questi slot sono stati trasferiti. E il problema \u00e8 che tutti questi slave vorranno sincronizzare i dati contemporaneamente. E sarai fortunato se si tratta di una sincronizzazione parziale e non totale. Tieni presente ci\u00f2 e combina le operazioni di trasferimento degli slot con la disattivazione\/trasferimento degli slave. Oppure spera di avere un margine di sicurezza sufficiente.<\/li>\n<li>Cosa fare se durante il trasferimento ti accorgi di aver perso dei slot? Spero che questo problema non ti riguardi, ma in caso contrario, c'\u00e8 l'operazione cluster fix. Essa redistribuir\u00e0 gli slot tra i nodi in modo casuale. Ti consiglio di verificarne il funzionamento, rimuovendo in precedenza il nodo con gli slot distribuiti dal cluster. Dato che i dati negli slot non distribuiti non sono comunque disponibili, ora \u00e8 tardi per preoccuparsi dei problemi di accessibilit\u00e0 di quegli slot. D'altra parte, l'operazione non influisce sugli slot distribuiti.<\/li>\n<li>Un'altra operazione utile \u00e8 monitor. Essa consente di vedere in tempo reale l'intero elenco delle richieste che arrivano al nodo. Inoltre, \u00e8 possibile utilizzare grep per verificare se \u00e8 presente il traffico desiderato.<\/li>\n<\/ul>\n<p><\/p>\n<p>Vale la pena menzionare anche la procedura di failover del master. In breve, s\u00ec, esiste, e, a mio avviso, funziona molto bene. Tuttavia, non bisogna pensare che scollegando la spina da una macchina con nodo master, Redis commuti immediatamente e i client non notino la perdita. Dalla mia esperienza, il passaggio avviene in pochi secondi. Durante questo tempo, parte dei dati sar\u00e0 inaccessibile: viene rilevata l'inaccessibilit\u00e0 del master, i nodi votano per un nuovo master, gli slave si commutano, i dati si sincronizzano. Il modo migliore per assicurarsi personalmente che lo schema funzioni \u00e8 condurre esercitazioni locali. Avvia un cluster sul tuo laptop, fornisci un carico minimo, simula un guasto (ad esempio, bloccando le porte) e valuta la velocit\u00e0 di commutazione. A mio avviso, solo giocando in questo modo per un giorno o due si pu\u00f2 essere certi del funzionamento della tecnologia. Oppure, si pu\u00f2 sperare che il software utilizzato dalla met\u00e0 di Internet funzioni sicuramente.<\/p>\n<p><\/p>\n<h1 id=\"konfiguraciya\">Configurazione<\/h1>\n<p><\/p>\n<p>Spesso, la configurazione \u00e8 la prima cosa necessaria per iniziare a utilizzare lo strumento. E quando tutto funziona, non si desidera toccare la configurazione. Ci vuole un certo impegno per costringersi a tornare alle impostazioni e rivederle attentamente. Nella mia esperienza, abbiamo avuto almeno due grandi fallimenti a causa di scarsa attenzione alla configurazione. Prestate particolare attenzione ai seguenti punti:<\/p>\n<p><\/p>\n<ul>\n<li>timeout 0<br \/>\n<em>Il tempo dopo il quale le connessioni inattive vengono chiuse (in secondi). 0 \u2014 non vengono chiuse<\/em><br \/>\nNon tutte le nostre librerie riuscivano a chiudere correttamente le connessioni. Disattivando questa impostazione, rischiamo di raggiungere il limite massimo di clienti. D'altra parte, se esiste un problema simile, la disconnessione automatica delle connessioni perse lo mascherer\u00e0 e potremmo non accorgercene. Inoltre, non dovremmo attivare questa impostazione quando si usano le connessioni persistenti.<\/li>\n<li>Save x y &amp; appendonly yes<br \/>\n<em>Salvataggio dello snapshot RDB.<\/em><br \/>\nDiscuteremo in dettaglio dei problemi RDB\/AOF pi\u00f9 avanti.<\/li>\n<li>stop-writes-on-bgsave-error no &amp; slave-serve-stale-data yes<br \/>\n<em>Se attivato, quando si verifica un guasto all'RDB snapshot, il master smetter\u00e0 di ricevere richieste di modifica. Se la connessione con il master viene persa, lo slave pu\u00f2 continuare a rispondere alle richieste (s\u00ec). Oppure smetter\u00e0 di rispondere (no)<\/em><br \/>\nNon ci soddisfa una situazione in cui Redis si trasforma in una zucca.<\/li>\n<li>repl-ping-slave-period 5<br \/>\n<em>Dopo questo intervallo di tempo, inizieremo a preoccuparci del fatto che il master sia guasto e che sia il momento di eseguire la procedura di failover.<\/em><br \/>\nDovremo trovare manualmente un equilibrio tra falsi allarmi e avvio del failover. Nella nostra esperienza, sono 5 secondi.<\/li>\n<li>repl-backlog-size 1024mb &amp; epl-backlog-ttl 0<br \/>\n<em>Esattamente quanti dati possiamo memorizzare nel buffer per una replica che si \u00e8 disconnessa. Se il buffer finisce, sar\u00e0 necessario completare la sincronizzazione.<\/em><br \/>\nL'esperienza suggerisce che \u00e8 meglio impostare un valore maggiore. Le ragioni per cui la replica pu\u00f2 iniziare a ritardare sono molte. Se \u00e8 in ritardo, molto probabilmente il tuo master sta gi\u00e0 facendo fatica a gestire e la completa sincronizzazione sar\u00e0 l'ultima goccia.<\/li>\n<li>maxclients 10000<br \/>\n<em>Il numero massimo di clienti simultanei.<\/em><br \/>\nDalla nostra esperienza, \u00e8 meglio impostare un valore pi\u00f9 alto. Redis gestisce benissimo 10.000 connessioni. Assicurati solo che ci siano abbastanza socket nel sistema. <\/li>\n<li>maxmemory-policy volatile-ttl<br \/>\n<em>La regola che determina quali chiavi vengono rimosse al raggiungimento del limite di memoria disponibile.<\/em><br \/>\nQui \u00e8 importante non solo la regola, ma comprendere come avverr\u00e0. Redis merita elogi per la sua capacit\u00e0 di operare normalmente al raggiungimento del limite di memoria. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"problemy-rdb-i-aof\">Problemi RDB e AOF<\/h1>\n<p><\/p>\n<p>Sebbene Redis memorizzi tutte le informazioni in memoria, esiste anche un meccanismo per salvare i dati su disco. In particolare, tre meccanismi:<\/p>\n<p><\/p>\n<ul>\n<li>RDB-snapshot \u2014 uno snapshot completo di tutti i dati. Viene impostato tramite la configurazione SAVE X Y e viene letto come \u00abSalvare uno snapshot completo di tutti i dati ogni X secondi, se almeno Y chiavi sono state modificate\u00bb.<\/li>\n<li>Append-only file \u2014 un elenco delle operazioni nell'ordine in cui vengono eseguite. Aggiunge le nuove operazioni nel file ogni X secondi o ogni Y operazioni.<\/li>\n<li>RDB e AOF \u2014 combinazione delle due precedenti.<\/li>\n<\/ul>\n<p><\/p>\n<p>Tutti i metodi hanno i loro vantaggi e svantaggi; non elencher\u00f2 tutti, ma voglio mettere in evidenza alcuni aspetti che, a mio avviso, non sono ovvi.<\/p>\n<p><\/p>\n<p>Innanzitutto, per salvare lo snapshot RDB \u00e8 necessario chiamare FORK. Se ci sono molti dati, questo pu\u00f2 bloccare l'intero Redis per un periodo che va da alcune millisecondi a un secondo. Inoltre, il sistema necessita di allocare memoria per tale snapshot, il che porta alla necessit\u00e0 di mantenere una doppia scorta di memoria RAM sulla macchina logica: se a Redis sono allocati 8 GB, allora sulla macchina virtuale deve essere disponibile un totale di 16 GB.<\/p>\n<p><\/p>\n<p>In secondo luogo, ci sono problemi con la sincronizzazione parziale. In modalit\u00e0 AOF, durante il ricollegamento di uno slave, pu\u00f2 essere eseguita una sincronizzazione completa invece di una parziale. Non sono riuscito a capire perch\u00e9 ci\u00f2 accada. Ma \u00e8 importante ricordarsene.<\/p>\n<p><\/p>\n<p>Questi due punti ci fanno gi\u00e0 riflettere su quanto siano necessari questi dati su disco, considerando che tutto \u00e8 gi\u00e0 duplicato dai server secondari. I dati possono andare persi solo se tutti i server secondari falliscono, e questo \u00e8 un problema di livello \u00abincendio nel DC\u00bb. Come compromesso, potremmo considerare di conservare i dati solo sui server secondari, ma in questo caso bisogna assicurarsi che questi server non diventino mai un master durante un ripristino di emergenza (esiste un'impostazione di priorit\u00e0 dei server secondari nella loro configurazione). Ogni volta valutiamo se sia necessario conservare i dati su disco e nella maggior parte dei casi rispondiamo \u00abno\u00bb.<\/p>\n<p><\/p>\n<h1 id=\"zaklyuchenie\">Conclusione<\/h1>\n<p><\/p>\n<p>In conclusione, spero di aver fornito una panoramica generale sul funzionamento di redis-cluster a coloro che non ne hanno mai sentito parlare, e di aver messo in evidenza alcuni aspetti non ovvi per chi gi\u00e0 lo utilizza da tempo.<br \/>\nGrazie per il tempo dedicato e, come al solito, sono benvenuti commenti in merito.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/515620\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435 \u0434\u0435\u0441\u044f\u0442\u043a\u0430 \u043b\u0435\u0442, \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0432\u0441\u0442\u0440\u0435\u0442\u0438\u0442\u044c \u0432 \u043d\u0435\u043c \u0443\u0441\u0442\u0430\u0440\u0435\u0432\u0448\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438. \u041d\u043e \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u0432\u044b \u0434\u043e\u043b\u0436\u043d\u044b \u0434\u0435\u0440\u0436\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443 \u0432 10 \u0440\u0430\u0437 \u0432\u044b\u0448\u0435, \u0430 \u0446\u0435\u043d\u0430 \u043f\u0430\u0434\u0435\u043d\u0438\u0439 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u0441\u044f \u0432 \u0441\u043e\u0442\u043d\u0438 \u0440\u0430\u0437? \u0412 \u044d\u0442\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0430\u043c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c \u043a\u0440\u0443\u0442\u043e\u0439 Highload Engineer. \u041d\u043e \u0437\u0430 \u043d\u0435\u0438\u043c\u0435\u043d\u0438\u0435\u043c \u0433\u043e\u0440\u043d\u0438\u0447\u043d\u043e\u0439 \u0442\u0430\u043a\u043e\u0432\u043e\u0433\u043e, \u0440\u0435\u0448\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0434\u043e\u0432\u0435\u0440\u0438\u043b\u0438 \u043c\u043d\u0435. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91847,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91846","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435 \u0434\u0435\u0441\u044f\u0442\u043a\u0430 \u043b\u0435\u0442, \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0432\u0441\u0442\u0440\u0435\u0442\u0438\u0442\u044c \u0432 \u043d\u0435\u043c \u0443\u0441\u0442\u0430\u0440\u0435\u0432\u0448\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438. \u041d\u043e \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u0432\u044b \u0434\u043e\u043b\u0436\u043d\u044b \u0434\u0435\u0440\u0436\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443 \u0432 10 \u0440\u0430\u0437 \u0432\u044b\u0448\u0435, \u0430 \u0446\u0435\u043d\u0430 \u043f\u0430\u0434\u0435\u043d\u0438\u0439 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u0441\u044f \u0432 \u0441\u043e\u0442\u043d\u0438 \u0440\u0430\u0437? \u0412 \u044d\u0442\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0430\u043c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c \u043a\u0440\u0443\u0442\u043e\u0439 Highload Engineer. \u041d\u043e \u0437\u0430 \u043d\u0435\u0438\u043c\u0435\u043d\u0438\u0435\u043c \u0433\u043e\u0440\u043d\u0438\u0447\u043d\u043e\u0439 \u0442\u0430\u043a\u043e\u0432\u043e\u0433\u043e, \u0440\u0435\u0448\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0434\u043e\u0432\u0435\u0440\u0438\u043b\u0438 \u043c\u043d\u0435. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e \u043f\u0435\u0440\u0435\u0435\u0437\u0434\u0435 \u0441 Redis \u043d\u0430 Redis-cluster | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435 \u0434\u0435\u0441\u044f\u0442\u043a\u0430 \u043b\u0435\u0442, \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0432\u0441\u0442\u0440\u0435\u0442\u0438\u0442\u044c \u0432 \u043d\u0435\u043c \u0443\u0441\u0442\u0430\u0440\u0435\u0432\u0448\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438. \u041d\u043e \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u0432\u044b \u0434\u043e\u043b\u0436\u043d\u044b \u0434\u0435\u0440\u0436\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443 \u0432 10 \u0440\u0430\u0437 \u0432\u044b\u0448\u0435, \u0430 \u0446\u0435\u043d\u0430 \u043f\u0430\u0434\u0435\u043d\u0438\u0439 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u0441\u044f \u0432 \u0441\u043e\u0442\u043d\u0438 \u0440\u0430\u0437? \u0412 \u044d\u0442\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0430\u043c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c \u043a\u0440\u0443\u0442\u043e\u0439 Highload Engineer. \u041d\u043e \u0437\u0430 \u043d\u0435\u0438\u043c\u0435\u043d\u0438\u0435\u043c \u0433\u043e\u0440\u043d\u0438\u0447\u043d\u043e\u0439 \u0442\u0430\u043a\u043e\u0432\u043e\u0433\u043e, \u0440\u0435\u0448\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0434\u043e\u0432\u0435\u0440\u0438\u043b\u0438 \u043c\u043d\u0435. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-19T17:41:57+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-19T17:41:57+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Spostamento da Redis a Redis-cluster | ProHoster","description":"Quando ci si avvicina a un prodotto che si sviluppa da pi\u00f9 di dieci anni, non sorprende trovare tecnologie obsolete. Ma cosa succederebbe se dopo sei mesi dovessi gestire un carico dieci volte superiore e il costo dei downtime aumentasse di centinaia di volte? In questo caso, hai bisogno di un esperto di Highload. Ma in assenza di un professionista cos\u00ec, la soluzione del problema \u00e8 stata affidata a me. Nella prima","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e \u043f\u0435\u0440\u0435\u0435\u0437\u0434\u0435 \u0441 Redis \u043d\u0430 Redis-cluster | ProHoster","og:description":"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435 \u0434\u0435\u0441\u044f\u0442\u043a\u0430 \u043b\u0435\u0442, \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0432\u0441\u0442\u0440\u0435\u0442\u0438\u0442\u044c \u0432 \u043d\u0435\u043c \u0443\u0441\u0442\u0430\u0440\u0435\u0432\u0448\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438. \u041d\u043e \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u0432\u044b \u0434\u043e\u043b\u0436\u043d\u044b \u0434\u0435\u0440\u0436\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443 \u0432 10 \u0440\u0430\u0437 \u0432\u044b\u0448\u0435, \u0430 \u0446\u0435\u043d\u0430 \u043f\u0430\u0434\u0435\u043d\u0438\u0439 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u0441\u044f \u0432 \u0441\u043e\u0442\u043d\u0438 \u0440\u0430\u0437? \u0412 \u044d\u0442\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0430\u043c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c \u043a\u0440\u0443\u0442\u043e\u0439 Highload Engineer. \u041d\u043e \u0437\u0430 \u043d\u0435\u0438\u043c\u0435\u043d\u0438\u0435\u043c \u0433\u043e\u0440\u043d\u0438\u0447\u043d\u043e\u0439 \u0442\u0430\u043a\u043e\u0432\u043e\u0433\u043e, \u0440\u0435\u0448\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0434\u043e\u0432\u0435\u0440\u0438\u043b\u0438 \u043c\u043d\u0435. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-19T17:41:57+00:00","article:modified_time":"2020-08-19T17:41:57+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91846","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:19:41","updated":"2022-10-03 14:54:15"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=91846"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91846\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/91847"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=91846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=91846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=91846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}