Problema di progettazione: condivisione, sincronizzazione, accesso ai dati nell'applicazione & # 8230; l'approccio migliore?

Question

Ho un'applicazione web (asp.net) in cui gli elementi di lavoro vengono inviati e assegnati agli utenti in base al loro carico di lavoro.

Il carico di lavoro di un utente viene calcolato utilizzando un algoritmo basato sul numero di elementi attualmente assegnati all'utente (e su alcuni altri fattori). Ogni nuovo elemento viene assegnato all'utente con il carico di lavoro corrente più basso, aumentandone il carico di lavoro. Il carico di lavoro di un utente diminuisce quando termina un articolo. Gli articoli verranno inviati, allocati e finiti contemporaneamente, quindi i livelli di carico di lavoro cambieranno continuamente. Gli elementi di lavoro sono archiviati in un database SQL.

Ho bisogno di un modo per garantire che ogni decisione sull'allocazione venga presa utilizzando un'immagine aggiornata del carico di lavoro attraverso la base di utenti.

La mia idea è di fornire un archivio sincronizzato di lettura / scrittura delle informazioni sul carico di lavoro nella cache.

È questo l'approccio migliore? O dovrei usare il database per controllare il blocco? Come posso evitare il collo di bottiglia nella mia applicazione?

Consiglio molto apprezzato.

Answer 1

Questo dipende da molti fattori, quando ti riferisci alla cache intendi la cache standard fornita da Asp.Net?

È assolutamente fondamentale disporre sempre delle informazioni più aggiornate, o se vengono fatte due richieste per essere allocate, è giusto che vengano allocate ai due utenti meno occupati al momento della richiesta?

Puoi effettivamente utilizzare una cache per archiviare queste informazioni, tuttavia in genere si presuppone che utilizzerai un solo server, è probabile che utilizzerai il clustering o il bilanciamento del carico per carichi elevati?

Il miglior consiglio che posso darti è quello di creare un'applicazione ben progettata, con un modello di dominio ricco che rappresenti i carichi di ciascun utente e la coda e l'accesso ai dati liberamente accoppiati e numerosi test automatici di unità e sistema. In questo modo è possibile creare un'applicazione funzionante, avviare rapidamente il sistema senza preoccuparsi troppo dell'ottimizzazione e iniziare il test delle prestazioni \ profiling al più presto.

Se \ quando si verificano problemi di prestazioni, è quindi possibile identificare i colli di bottiglia profilando \ tracing e aggiungere l'ottimizzazione in base alle esigenze, che potrebbe essere la memorizzazione nella cache o query ottimizzate \ viste o combinazioni di cose.

Se provi a indovinare dove sono i colli di bottiglia e rimuoverli, probabilmente indovinerai male e danneggierai il design del sistema. Un sistema ben progettato può essere ottimizzato quando ne hai bisogno.

Il modo in cui inizialmente lo immaginerei sarebbe un database relazionale (possibilmente usando viste o procedure memorizzate per catturare rapidamente le informazioni di riepilogo del carico di lavoro) con un livello di mappatura dei dati tra questo e il modello di dominio (che può usare la cache, il caricamento lazy mappatura delle identità per fornire efficienza se necessario). Il modello di dominio avrebbe in gran parte rappresentato il carico di lavoro.

Mi aspetto che questo abbia utenti, elementi di lavoro, coda di lavoro e classi di strategia di allocazione. Gran parte di questo potrebbe essere tenuto in memoria o archiviato localmente tra le richieste, ogni richiesta potrebbe essere rappresentata da un evento che aggiornerebbe il modello.

es.
L'utente completa un oggetto di lavoro
Il sito genera un evento di dominio per notificare il modello di dominio del cambiamento
Il modello di dominio riceve l'evento e aggiorna il carico di lavoro dell'utente

L'allocazione del lavoro sarebbe quindi una questione di chiedere al modello di dominio di allocare il lavoro (cosa che farebbe attraverso una strategia per trovare l'utente meno allocato) quando necessario. Ciò potrebbe accadere in background al di fuori delle singole richieste di lavoro e degli eventi generati per informare gli utenti la prossima volta che chiedono lavoro.

Answer 2

Usa il database per controllarlo.

Se per qualche motivo, in futuro, è necessario espandersi per utilizzare una Web farm, non si verificherà alcun problema. Tuttavia, se si memorizzano nella cache i dati e si lavora localmente, si verificheranno cose interessanti.

Inoltre, puoi sfruttare le impostazioni del web garden per aiutare a gestire qualsiasi carico il tuo server avrebbe; che non è esattamente possibile in una situazione memorizzata nella cache.

Secondo, renditi conto che questo probabilmente non deve essere perfetto. Se hai una grande quantità di lavoro in arrivo (come distribuire lead in un call center), ti basta avvicinarti molto finché è veloce è tutto ciò che conta.

Answer 3

Vorrei utilizzare un database per controllare questo, poiché è altamente improbabile che gli utenti completino il lavoro abbastanza rapidamente da richiedere un approccio più in tempo reale.

Quindi avrei una serie di tabelle, relative agli oggetti di lavoro, che puoi interrogare per calcolare gli attuali livelli di lavoro, e quindi determinare la persona successiva a ricevere un particolare oggetto di lavoro.

È quindi possibile disporre di una serie di procedure memorizzate per contrassegnare gli elementi di lavoro come completi o per allocare un oggetto di lavoro a qualcuno.

Per ridurre al minimo il collo di bottiglia, assicurarsi che il database sia ben normalizzato e che le procedure memorizzate non utilizzino molte tabelle e questo dovrebbe accelerare.

Per verificare ciò, è possibile scrivere alcuni imbraghi di prova per garantire l'assegnazione degli oggetti di lavoro e le prestazioni sono ciò che si desidera in caso di utilizzo intenso.