Devo mantenere la notifica prima o dopo averla pubblicata tramite Redis pub / sub?

Naviga le tue risposte
0

Sto implementando un meccanismo per informare un gruppo di utenti sui commenti del blog appena inseriti. L'architettura utilizza il meccanismo Redis Pub / Sub.

Per definizione, il meccanismo pub / sub ha lo scopo di propagare il messaggio agli abbonati giusti, senza memorizzare / persistere nulla.

Sebbene i commenti sui blog siano ovviamente persistenti nel DB, mi aspetto anche che tutte le notifiche vengano inviate per essere mantenute per poter essere recuperate in qualsiasi momento da un utente non in linea che viene nuovamente registrato. Ovviamente, Redis potrebbe avere messaggi persistenti, ma il costo è piuttosto alto.

Uso un database principale distinto, prendiamo per l'esempio MySql. Attualmente, il flusso di lavoro è:

  1. Un commento sul blog pubblicato da un utente viene gestito dal mio back-end e archiviato per la prima volta nel DB.
  2. Viene generato un evento, chiamiamolo "CommentedBlogEvent", che attiva un worker che mira a rilevare tutti gli utenti target del commento.
  3. Supponendo che 10 utenti siano target del commento, inserisco 10 "righe di notifica" nel mio database associando il commentId e il userId targetizzato, ciascuno specifico per un utente poiché avrebbe un flag letto / non letto.
  4. Quindi, una volta che tutte le notifiche sono state mantenute, utilizzo Redis Pub / Sub per attivare gli iscritti che mirano a inviare risultati ai client online interessati (tramite WebSockets, ad esempio).

Il "problema" è che il processo potrebbe essere lento a causa del passaggio 3.

Sarebbe tollerato effettuare il passaggio 4 prima del passaggio 3, ovvero prima di persisterlo in DB, dal momento che una potenziale perdita di dati non è drammatica nel mio caso (dati non finanziari, ecc.)?
Vantaggio: il cliente ottiene risultati più rapidamente.
Svantaggio: l'utente può ricevere una notifica che non è stata salvata in background, portando a una notifica mancante quando l'utente aggiorna la pagina.

Qual è il modo migliore per gestire questo caso, mantenendo il mio database principale come archivio delle notifiche?

    
posta Mik378 01.07.2014 - 21:50
fonte

1 risposta

1

The "issue" is that the process could be slow because of the step 3.

Potrebbe essere utile utilizzare una pipeline: mentre il passaggio 3 sta ancora inserendo le notifiche, fare in modo che il passaggio 4 avvii le notifiche di processo già inserite. Potrebbe essere necessario ridisegnare come funziona il passaggio 3, ad es. dividendo gli utenti in lotti.

Would it be tolerated to make the step 4 before the step 3, since a potential data loss isn't dramatic in my case (non-financial data etc)?

Se la perdita di dati è drammatica o non molto dipende da come gli utenti percepiscono questa perdita e quanto spesso accade. Se dici ai tuoi utenti di "non perdere mai un commento sul blog" e poi non riesci a consegnare le notifiche in modo affidabile, potrebbe essere ancora abbastanza drammatico. Se non riesci a consegnare 1 ppm probabilmente non è così male, se non riesci a consegnare 500'000 ppm, beh questo è solo un cattivo design.

    
risposta data 01.07.2014 - 22:04
fonte

Leggi altre domande sui tag

Sincronizzazione dati tra app Android in LAN Grande rapporto csv in html