Questa è una lunga domanda che conosco. Ho alcune opzioni per quello che voglio. Non voglio sapere "questo è ovviamente il migliore", ma forse qualsiasi pro o contro mi può mancare riguardo le opzioni, così come tutte le opzioni di cui non sono a conoscenza.
Abbiamo un'applicazione java che funziona separatamente come demoni multipli, ognuno una JVM separata. In questo momento SQL è usato per archiviare dati ed effettuare con efficacia la nostra 'memoria condivisa', ma fortunatamente non molto è dinamico una volta in memoria.
Presto creeremo e distruggeremo le connessioni in modo dinamico e ciò significherà che i cambiamenti dinamici avvengono in modo semi-veloce e necessitano di qualcosa di meglio di un database SQL. Noi pensiamo tutte le cose dinamiche accadranno in un solo demone, ma non ne siamo certi.
Avremo bisogno di un metodo più veloce per salvare e caricare questi dati di stato, andare su disco ogni volta è semplicemente troppo lento. Il database attuale ha bisogno di una revisione per questo cambiamento comunque, quindi siamo aperti alla modifica o al lancio di esso pure. Possiamo ri-imparare tutto lo stato che conserviamo nella memoria; ma è un processo lento. Persistere alcuni o tutti i dati su un DB tra le esecuzioni per salvare lo stato di apprendimento del tempo all'avvio è bello, se possiamo essere sicuri che venga mantenuto corretto.
La possibilità di interrogare facilmente un "database" per vedere lo stato corrente per il debug è un vantaggio importante.
Le soluzioni che ho considerato e alcuni dei pro e amp; i contro sono:
1) una sorta di soluzione di ibernazione combinata con un database sql in memoria. Non ho ancora usato la modalità ibernazione (lo voglio davvero!), Ma penso che possa affrontare la persistenza ed evitare oggetti obsoleti tra JVM per noi e SQL sarà ancora vicino alla velocità di altre opzioni se in memoria? Non so quanto sia il sovraccarico per questo o come ridimensiona a più JVM e possibili (semi?) Modifiche veloci ai dati. Presumibilmente questo è più lento di tutte le altre opzioni, ma pensi che sia abbastanza veloce per le nostre esigenze?
2) Ogni archivio JVM ha il proprio stato interno senza alcun sistema condiviso. Utilizzare l'intercomunicazione affidabile (probabilmente JVM) per cercare di mantenere lo stato coerente. Lo stato più importante è in un demone, quindi non ci sarà molta condivisione dello stato dinamico, ma sarà comunque necessario indirizzare lo stato e le dataraces incoerenti quando ciò avviene. Non sono sicuro di come vorremmo registrare lo stato persistente per consentire il riavvio veloce anche se il demone muore in modo imprevisto. Inoltre, questa soluzione richiede l'implementazione di alcuni messaggi rapidi per consentire il recupero di una descrizione dello stato della memoria per facilitare il debug. Offrire le massime prestazioni una volta che abbiamo capito bene, ma probabilmente il tempo più lungo da implementare (prevedo bug oscuri dovuti a dati razziali e dati incoerenti?).
3) Utilizzare un sistema per consentire un po 'di memoria condivisa tra JVM. La ricerca rapida ha suggerito MappedByteBuffer ed Ecache come opzioni possibili, potrebbe essercene di più. L'ho esaminato solo un po 'finora, quindi non conosco ancora bene pro e contro. Un po 'paura di creare un singolo punto di errore se la nostra memoria è condivisa.
4) Una sorta di alternativa che non conosco o possibile unire due di queste idee.