Più server memcached in discussione

Question

ipoteticamente - se ho più server memcached come questo:

//PHP 
$MEMCACHE_SERVERS = array(
    "10.1.1.1", //web1 
    "10.1.1.2", //web2 
    "10.1.1.3", //web3 
); 
$memcache = new Memcache(); 
foreach($MEMCACHE_SERVERS as $server){ 
    $memcache->addServer ($server); 
} 

E poi impostare i dati in questo modo:

$huge_data_for_frong_page = 'some data blah blah blah'; 
$memcache->set("huge_data_for_frong_page", $huge_data_for_frong_page); 

E poi recuperare i dati così:

$huge_data_for_frong_page = $memcache->get("huge_data_for_frong_page"); 

Quando vorrei recuperare questi dati dai server memcached - in che modo php memcached client sa quale server interrogare per questi dati? Oppure il client memcached sta andando a interrogare tutti i server memcached?

Answer 1

Beh, potresti scrivere libri su questo, ma il principio base è che ci sono alcuni approcci diversi.

L'approccio più comune e sensato per il caching è il sharding. Il che significa che i dati vengono sottrati solo su un server e viene utilizzato un metodo per determinare quale server è. Quindi può essere prelevato da questo stesso server e solo un server è coinvolto.

Questo ovviamente funziona bene in ambienti chiave/valore come memcached.

Una pratica comune è prendere un hash crittografico della chiave. Calcola questo numero di server hash MOD e il risultato è il server che archivierai e recupererai i dati.

Questa procedura produce un bilanciamento più o meno uguale.

Come esattamente fatto in memcached, non so certo quale tipo di hash.

Ma attenzione che questa teqnique non è altamente disponibile. Quindi, se un server fallisce, le voci sono sparite. Quindi ovviamente puoi usare questo solo per scopi di cache.

Altre teqniques, in cui è necessaria, ad esempio, un'elevata disponibilità di risorse, che richiedono molto tempo per calcolare e sono riscaldate automaticamente in background, coinvolgono la replica.

La forma più comune negli ambienti di memorizzazione nella cache è la replica master-master con la risoluzione dei conflitti dell'ultimo momento. Che in sostanza significa che ogni server riceve i dati da everyserver che non è ancora sul server locale (questo viene fatto usando i log di replica e gli offset di byte). In caso di conflitto viene utilizzata l'ultima versione (il leggero spostamento temporale tra i server viene ignorato).

Ma in altri ambienti in cui per esempio solo molto poco è scritto ma viene letto molto, c'è spesso una cascata in cui sono coinvolti solo uno o pochi server master e il resto è pura replica di lettura.

Ma questi setup sono molto rari in quanto lo sharding come descritto sopra offre le migliori prestazioni e negli ambienti di memorizzazione nella cache la perdita di dati è per lo più tollerabile. quindi è anche l'impostazione predefinita per memcached.

Answer 2

alcuni giorni fa stavo cercando una soluzione per ottimizzare il ridimensionamento dei nostri server memcached e ho trovato questa risposta. Dalle esperienze fatte, la soluzione descrittiva con la generazione di un hash e il numero di server MOD per trovare il server di destinazione, non è la migliore.

Se si desidera eseguire il downgrade o il downscale del numero dei server, è probabile che si verifichi lo stesso scenario durante il lavaggio della cache. La maggior parte degli hash ottiene un altro server e quindi non ci sarà un risultato fuori dalla cache per la prima richiesta.

La soluzione migliore da utilizzare per tali scenari è l'hashing coerente. Con l'hashing coerente, ogni server ottiene un hashrange fisso. Pertanto, se ora si esegue il downgrade del numero di server, solo gli hash di questo particolare hashrange verranno passati a un altro server. Tutti gli altri hash rimangono sui server e solo una piccola parte verrà rigenerata.

Per PHP esiste una libreria chiamata "flexihash" che esegue l'hashing coerente per te.

Nel nostro Blog, è possibile trovare un esempio di come utilizzarlo con il proprio client di cache. L'articolo è in tedesco ma il codice sorgente dovrebbe essere autoesplicato.