Ho un'applicazione web Java che supporta la multi-tenancy per conservare i dati dei clienti separato.
I pool di connessione a ciascun database clienti vengono creati in fase di runtime. Il i dettagli di ogni shard cliente (url jdbc, credenziali, ecc.) sono memorizzati in un frammento database "di controllo". Quando l'applicazione deve accedere a un frammento di cliente, prova per ottenere una connessione JDBC dal pool di connessione di quel frammento. Se quella connessione pool non è stato ancora stabilito, l'applicazione cerca i dettagli necessari da lo schema di controllo e crea il pool.
Questa è una configurazione eccellente, ma ha un grosso problema che non sono sicuro del modo migliore risolvere. Questa applicazione verrà infine raggruppata in cluster con ciascuna istanza di app gestendo i propri pool di connessioni shard dei clienti. Il problema è cosa fare quando cambia la posizione di un cliente. Questo non succede molto spesso, ma succede. L'applicazione ha un'interfaccia di amministrazione per la gestione dei dettagli di shard e potrei inserire una funzione lì che dice "Ricrea il pool di connessione di questo shard" ma si interagirebbe solo con qualsiasi istanza di applicazione a cui il servizio di bilanciamento del carico ha inviato quella richiesta e tutte le altre istanze non sarebbero a conoscenza del fatto che si desidera ricreare il pool.
Quindi ecco i modi in cui riesco a pensare di affrontare questo insieme ai pro e ai contro mentre li vedo.
1) Poiché questo scenario non è un evento frequente, è sufficiente riavviare forzatamente tutte le istanze del cluster dell'applicazione quando si verifica questa situazione e chiamarla un giorno.
PRO: non richiede ulteriore lavoro.
CONS: questa soluzione è più che soluzione. Detto questo, riavvio di tutte le app le istanze in un cluster potrebbero non essere facili come spingere un pulsante e poi andare a fare una pausa caffè. Inoltre, un'applicazione l'utente con il permesso di gestire i frammenti dei clienti potrebbe non essere qualcuno che è consentito avviare un riavvio del cluster.
2) Prima di rilasciare una connessione dal pool di connessioni, controllare il database di controllo per verificare se la definizione del pool è stata modificata e, in caso affermativo, riconfigurare il pool prima di rilasciare la connessione a chi lo ha richiesto.
PRO: approccio più diretto. Le istanze dell'applicazione sono garantite per ottenere una connessione al frammento giusto utilizzando le informazioni più recenti.
CONS: maggiori costi generali delle prestazioni. È necessario colpire lo schema di controllo e leggere tutte le definizioni di shard e quindi confrontarle con ciò che si è attualmente caricato per ogni singola richiesta di connessione nell'applicazione.
3) Avere un thread in background su un timer che cerca le modifiche alla definizione di shard e ricostruisce i pool quando necessario.
PRO: evita il colpo di performance coinvolto nel fare il controllo su ogni richiesta di connessione.
CONS: una volta modificata la definizione di shard, ci sarà un periodo di tempo in cui ogni istanza dell'applicazione ha le informazioni sbagliate. Questo può avere molte conseguenze incluse le eccezioni dell'applicazione fino a quando non viene rilevata la modifica della definizione di shard. Più è lungo l'intervallo di controllo, più questo problema si verifica, quindi ti piacerebbe che fosse il più breve possibile, ma più corto è, maggiore è il rendimento, perché è necessario caricare le definizioni shard dal database di controllo .
4) Attendere il lancio di un'eccezione durante il tentativo di ottenere una connessione dal pool di connessioni di un frammento e quindi cogliere l'opportunità per colpire lo schema di controllo e vedere se la definizione di shard è cambiata.
PRO: nessuno dei problemi di prestazioni delle opzioni 2 e 3
CONS: Si presuppone che si stia cambiando la definizione di shard perché la vecchia posizione non funziona più e potrebbe non essere vera. Questo solo penso sia una ragione sufficiente per uccidere questa opzione, ma la sto elencando qui perché mi è venuta in mente.
5) Creare un argomento di "modifica della definizione dello shard" nell'infrastruttura di messaggistica a cui tutte le istanze delle applicazioni verranno sottoscritte e ricaricare i pool di connessione in risposta a tali.
PRO: nessuno dei problemi di prestazioni delle opzioni 2 e 3. Nessuno dei problemi di dati obsoleti dell'opzione 3.
CONS: Non ho alcuna infrastruttura di messaggistica a mia disposizione oggi. Sta arrivando, ma non posso ancora dare un appuntamento.
Apprezzerei qualsiasi pensiero / esperienza / consiglio che potresti condividere con questo problema.