Come gestire troppe connessioni simultanee anche dopo aver utilizzato un pool di connessioni?

Question

Scenario

Supponiamo che tu abbia un sito Web o un'app con traffico intenso. E anche con un pool di connessione al database, le prestazioni stanno prendendo un vero successo (il sito/l'app potrebbe addirittura andare in crash) perché ci sono troppe connessioni simultanee.

Domanda

Quali sono le opzioni di qualcuno per affrontare questo problema?

I miei pensieri

pensavo qualcuno con questo problema potrebbe creare più database (possibilmente su macchine diverse anche se non sono sicuro che sia necessario), ciascuno con le stesse informazioni e aggiornati allo stesso tempo, che concederebbe un multiplo del numero originale di connessioni per un singolo database. Ma se il database è grande non sembra una soluzione molto valida.

Answer 1

lo stelo non è sufficientemente specifica da dare un suggerimento ferma, ma l'elenco completo di ciò che potrebbe essere fatto è la seguente:

• cluster del database: Adatto a situazioni in cui non si desidera cambia il livello dell'applicazione e il database è tutto ciò che tocchi. C'è un limite su quanto puoi uscire da un cluster di database. Se il volume della richiesta continua a crescere, anche questa soluzione avrà esito negativo. Ma la buona notizia è che hai tutte le funzionalità che hai già avuto in un normale MySQL a istanza singola.
• Sharding: Poiché la tua domanda è codificata con MySQL e non supporta sharding da sola, se si desidera utilizzare questa soluzione è necessario implementarla nel livello dell'applicazione. In questa soluzione disperderai i tuoi dati su più database (preferibilmente in più istanze MySQL su hardware separato) logicamente. Sarà tua responsabilità trovare il database appropriato contenente i dati designati. È una delle soluzioni più efficaci di sempre, ma non è sempre fattibile. Il suo più grande difetto è che i dati sparsi tra due o più database non possono essere inclusi in una transazione.
• Replica: A seconda dello scenario, è possibile incorporare la replica del database e disporre di copie dei dati su di essi. In questo modo è possibile connettersi a loro anziché al database master e ridurre il carico su di essi. La definizione di replica predefinita è scenario master/slave in cui il flusso di dati è a senso unico, dal master allo slave. Quindi i cambiamenti che potresti fare sullo schiavo mentre saranno applicati sulla salve, non influenzeranno il maestro. Ma esiste anche una configurazione di replica master/master in cui il flusso di dati è in entrambi i modi. Tuttavia, non è possibile assumere l'integrità atomica per le modifiche simultanee dei dati tra entrambi i master. Alla fine questa soluzione è più efficace se si prevede di utilizzarla in modalità master/slave e utilizzando gli slave per l'accesso in sola lettura.
• Caching: Forse questa soluzione non dovrebbe essere inclusa qui ma dal momento che il gambo non la rifiuta, qui va. Uno dei modi per ridurre il carico del database è quello di memorizzare nella cache i suoi dati una volta estratti. Questa soluzione può essere utile specialmente se l'estrazione dei dati è costosa. Esistono molti server cache, come memcached o redis. In questo modo puoi omettere così tante connessioni al database ma solo per l'estrazione dei dati.
• Altri motori di archiviazione: È sempre possibile passare a motori più performanti se quello attuale non fornisce ciò che è necessario. Naturalmente questo è fattibile solo se le tue esigenze ti permettono di farlo. Oggigiorno ci sono i motori NoSQL, molto più performanti di RDBMS, che supportano lo sharding in modo nativo e puoi ridimensionarli linearmente con il minimo sforzo. Esistono anche soluzioni basate su Lucene, con potenti funzionalità di ricerca full-text che forniscono lo stesso sharding automatico. In effetti, l'unico motivo per cui dovresti utilizzare un RDBMS tradizionale è il comportamento atomico delle transazioni. Ma se le transazioni non sono un must, ci sono soluzioni molto migliori di RDBMS.

Answer 2

Se non lo si è già, è possibile provare a eseguire l'applicazione su un server di applicazioni, per ottenere del middleware dietro l'app. La maggior parte dei server applicativi eseguirà il proprio pool di connessioni (poiché ottenere una connessione da un'app Web a un pool di connessione al database è ancora molto costoso). Inoltre, dovresti essere in grado di configurare il tuo server delle applicazioni per utilizzare le connessioni condivise, il che implica che il collegamento consenta la condivisione delle connessioni ovunque sia possibile.

In breve, utilizzare un appserver. Se lo sei già, magari menziona quale stai usando e possiamo cercare di ottimizzare la configurazione del server da lì.

Answer 3

Ci sono molte cose che dovreste investigare per questo problema.
- Quante connessioni simultanee ci sono. È sempre possibile aumentare la RAM e aumentare il numero di connessioni massime. MySQL può supportare milioni di connessioni.

- assicurati che la tua app stia chiudendo le connessioni. Anche con un pool, l'app deve restituire le connessioni al pool.

-run database su server separato.

-Assicurarsi di aver ottimizzato le query. Una query di lunga durata può rallentare un sistema.

-finalmente utilizzare il cluster MySQL se altri approcci falliscono. Con un sito ad alto traffico potresti voler considerare questo per evitare singoli punti di errore.

Answer 4

Questo è un tipico problema di ridimensionamento delle app e sono state ideate molte soluzioni, ad esempio Google Big Table e Amazon Elastic. Se passare a un cloud e sfruttare le opzioni di ridimensionamento automatico fornite da tutti non è un'opzione, quindi è necessario creare la propria configurazione. Date un'occhiata alla documentazione per Postgres e MySQL, e troverete che le idee sono piuttosto simili, compresi i concetti di

• sharding: diffondere i dati dei clienti in diverse banche dati e clienti instradare le richieste al le istanze di database corrette.

• Bilanciamento del carico: distribuire l'app in diversi server e utilizzare un middleware per instradare le richieste in base al carico sul server. Sarà necessario un qualche tipo di strumento di sincronizzazione DB come SymmetricDS per mantenere i database sincronizzati.

Questa non è affatto una panoramica completa di tutte le opzioni, ma potrebbe aiutarti a iniziare.

Answer 5

Replica - Master più un numero qualsiasi di slave. Questo ti dà letture scalabili "illimitate".

Disconnetti - Una connessione non deve mantenere la connessione aperta più a lungo del necessario.

Unix, non Windows - Devo elaborare?

InnoDB - Utilizzare InnoDB, non MyISAM.

SlowLog - Impostare long_query_time su 1 e osservare la coppia superiore di query; ottimizzarli Vedere pt-query-digest per un aiuto nel riepilogo del log lento.

Answer 6

Mi sono imbattuto in problemi simili, anche se l'app stava presumibilmente chiudendo le sue connessioni potrei vederle accatastamento in SQL come connessioni dormienti. Dopo aver controllato la questione, aggiungo il seguente alla mia stringa di connessione in WebConfig con il seguente alla prova:

Connection Lifetime=600 

Questo avrebbe dovuto uccidere i collegamenti di sonno dopo 10 minuti - ma non ha ...

In seguito ho avuto aggiornamenti Windows in sospeso sia sul mio server web che sul server SQL. E magicamente, il problema è andato via!

Vorrei poter avere una risposta più specifica per te, ma da qualche parte tra l'aggiunta del fatto che "Connection Lifetime" e ottenere i miei server web e SQL aggiornati con le patch ha completamente eliminato il problema per me. Sono stato pulito per 3 settimane, nessun problema.

Answer 7

Nel nostro caso, ci hanno anche affrontando lo stesso problema quando mysql connessione simultanea raggiunto 100.

Infine, abbiamo trovato un ottimo modulo npm cabinato myconnection (https://www.npmjs.com/package/express-myconnection). Rilascia automaticamente le connessioni al termine. Supporta le strategie di connessione Single e Pool.

Funziona bene.