Quale sistema programmabile può fornire una programmazione persistente? [chiuso]

0

Voglio scrivere un'applicazione che crea eventi programmati in momenti specifici. Trascorso il ritardo, l'evento notifica all'applicazione. Gli eventi programmati non devono essere archiviati nella memoria dell'applicazione perché se l'applicazione si arresta tutti gli eventi pianificati andranno persi - Non voglio scrivere un livello di persistenza personalizzato per la pianificazione degli eventi. Quale sistema è in grado di fornire una programmazione persistente per la mia applicazione che richiamerà la mia applicazione al termine di ogni evento?

Ho guardato le code dei messaggi e Redis. Non sono interessato alle soluzioni Java. La soluzione più vicina che ho trovato era RabbitMQ. Ai messaggi di coniglio può essere assegnato un TTL e posizionato su una coda che non viene mai consumata. Messaggi che scadono il fuoco messaggi DLX che possono essere esaminati per determinare se il messaggio non è riuscito a causa della scadenza TTL. Tuttavia, i messaggi non scadono necessariamente nell'ordine corretto a causa di un avvertimento applicabile al messaggio TTL in cui il messaggio in testa alla coda bloccherà altri messaggi (con TTL potenzialmente più brevi) dallo scadere prima di se stesso. Questo avvertimento significa che RabbitMQ non è adatto a questo scopo e non riesco a trovare alcun broker di messaggi non Java che soddisfi i requisiti per uno scheduler persistente.

Esiste un software di programmazione persistente programmabile per Linux?

    
posta Quolonel Questions 24.11.2014 - 23:47
fonte

1 risposta

2

Esistono programmazioni persistenti programmabili per Linux? Sì.

Il comando è progettato per eseguire comandi una volta in un momento specifico in futuro. Ma caveat emptor . Come cron , lo scheduler di eventi ripetuti di Unix, at è stato disponibile essenzialmente per sempre. Ma non ha la stessa attenzione di cron , e in alcuni casi ha una certa reputazione per aver dimenticato di tanto in tanto gli eventi.

Concordo con la tua scelta di non utilizzare la funzionalità time-to-live del middleware di routing dei messaggi. Il comportamento di blocco e altre possibili modalità di fallimento fanno sì che si tratti di un approccio basato su molti presupposti, probabilmente fragile.

Se la tua applicazione ha solo un modesto numero di eventi di segnalazione futuri, e se può resistere alla possibilità che un sistema esterno non segnali sempre al momento stabilito, l'agricoltura con at potrebbe avere senso. Se hai un volume elevato di segnali futuri e / o hai bisogno di una consegna ad altissima fedeltà / garantita, considera di portare questa funzionalità sotto il tuo sviluppo e controllo. Se si archiviano i record degli eventi in un gestore di persistenza standard comprovato (ad esempio RDBMS), la logica di "evento di attivazione" è semplice.

    
risposta data 25.11.2014 - 00:36
fonte

Leggi altre domande sui tag