Come panoramica di alto livello, come faccio a strutturare il mio server e il codice cliente con un database persistente?

Question

Come panoramica di alto livello, come faccio a strutturare il mio server e il codice cliente con un database persistente?

#1 da (3 voti)
#2 da (0 voti)

1

La necessità per l'utente client è di eseguire attività mentre non sono attualmente loggati (quindi possiamo supporre che sia basata sul tempo). Ad esempio: un utente accede, esegue attività, si disconnette e ottiene una "ricompensa" in circa 6 ore. Come si manterrebbe il tempo in questa situazione in quanto il client non è connesso?

Ho l'opzione per un server e un database (persistente). Una possibile soluzione a cui pensavo era il salvataggio del tempo di accesso utente precedente e quando la prossima volta che si collegano, controllerebbe se erano trascorse 6 ore e aggiornava il database da lì.

Tuttavia, il problema delle attività, degli utenti e dell'hardware aumenta quando ho bisogno di aggiornare ogni informazione di ogni utente in modo diverso ogni minuto.

C'è un modo più intelligente per progettare questo?

design database-design project-structure

posta user2676326 07.01.2018 - 06:36

fonte

2 risposte

0

Suggerirei di utilizzare una sorta di Scheduler per pianificare un'attività periodica eseguita in background x ore dopo che un determinato utente si è disconnesso dal sistema.

Usando questo approccio non è necessario controllare se x ore è passato dalla precedente disconnessione per calcolare il premio, ogni volta che un utente accede al sistema.

risposta data 07.01.2018 - 14:03

fonte

Leggi altre domande sui tag design database-design project-structure

Devo scrivere vares computati che dipendono tutti da un'altra var, o dovrei assegnarli come vars normali nel setter di quella singola variabile? Come possiamo utilizzare le RFC nei progetti closed source?

score 3 · Accepted Answer

Dipende da quali sono i requisiti esatti.

Aggiornamento retroattivo ti è venuta l'idea di aggiornare semplicemente i dati dell'utente quando effettuerà l'accesso la prossima volta.

Questa è una soluzione semplice e robusta, e la consiglierei se soddisfa i tuoi requisiti. Tuttavia, non funziona se l'aggiornamento ha conseguenze per altri utenti. Ad esempio, se stai mantenendo un consiglio direttivo, non vuoi che il punteggio dell'utente si aggiorni solo quando riaccede.

Aggiornamento proattivo L'alternativa in questo scenario è di memorizzare immediatamente la ricompensa, ma avere un campo ActivationTime che hai impostato tra sei ore.

Ogni volta che hai bisogno dello stato attuale del sistema, ti basta interrogare tutti i premi che sono già stati attivati. Questa soluzione è quasi altrettanto semplice e altrettanto robusta. Tuttavia, richiede che tu sappia in anticipo quando deve essere data una ricompensa. Se la ricompensa dipende da molte altre cose che potrebbero o non potrebbero accadere in futuro, questo diventerà più complicato, anche se potrebbe comunque funzionare abbastanza bene.

Aggiornamento pianificato In alternativa, puoi implementare un meccanismo di aggiornamento programmato, come suggerito da Pedro Tavares.

Questo ha il vantaggio che puoi far accadere le cose proprio come dovrebbero accadere concettualmente. Ad esempio,

Wait 6 hours
Check something
Give reward

Tuttavia, è necessario un modo per recuperare da un errore di sistema durante tali 6 ore. Ciò significa essenzialmente che devi mantenere le attività pianificate o trovare un modo per ricrearle quando il sistema torna online.