Idee per ridimensionare la chat in AWS?

Question

Sto cercando di trovare la soluzione migliore per ridimensionare un servizio di chat in AWS. Mi è venuta in mente un paio di possibili soluzioni:

1. Redis Pub/Sub - Quando un utente stabilisce una connessione a un server che server di sottoscrive ID di quell'utente. Quando qualcuno invia un messaggio a quell'utente, un server eseguirà una pubblicazione sul canale con l'id dell'utente. Il server a cui l'utente è connesso riceverà il messaggio e lo sposterà sul client appropriato.

2. SQS - Ho pensato di creare una coda per ogni utente. Il server a cui è connesso l'utente eseguirà il polling (o utilizzerà il polling lungo SQS) in coda. Quando viene scoperto un nuovo messaggio, verrà inviato all'utente dal server.

3. SNS - Mi è piaciuto molto questa soluzione fino a quando ho scoperto il limite di 100 argomento. Avrei bisogno di creare un argomento per ogni utente, che supporterebbe solo 100 utenti.

I loro altri modi in cui la chat potrebbe essere ridimensionata utilizzando AWS? L'approccio SQS è fattibile? Quanto tempo impiega AWS per aggiungere un messaggio a una coda?

Answer 1

Costruire un servizio di chat non è facile come si penserebbe.

Ho costruito piena XMPP server, client e SDK e può attestare alcuni dei problemi sottili e difficili che si presentano. Un prototipo in cui gli utenti si vedono e la chat è facile. Un sistema completo di funzionalità con creazione di account, sicurezza, scoperta, presenza, consegna offline e liste di amici è molto più di una sfida. È quindi particolarmente difficile ridimensionarlo su un numero arbitrario di server.

PubSub è una funzionalità offerta da servizi di chat (see XEP-60) piuttosto che un mezzo tradizionale di costruire un servizio di chat. Posso vedere il fascino, ma PubSub può avere degli svantaggi.

Alcune domande per voi: 1. stai facendo questo sul Web? Gli utenti si collegheranno e si collegheranno a lungo oppure avete una soluzione Web Sockets?

2. Quanti utenti? Quante connessioni per utente? Rapporto tra scritture e letture?

3. La tua idea per l'utilizzo di SQS in questo modo è interessante, ma probabilmente non in scala. Non è raro avere 50 o più utenti su un server di chat. Se stai eseguendo il polling di ogni coda SQS per ogni utente, non ti avvicineresti. Sarebbe meglio avere una coda per ogni server, e il server interroga solo quella coda. Quindi è su di te capire a quale server si trova un utente e mettere il messaggio nella coda giusta.

ho il sospetto si vorrà andare qualcosa come:

1. Una grande banca dati RDS sul backend.
2. Un gruppo di server front-end che gestiscono le connessioni client.
3. Un codice Java/C# di livello intermedio che tiene traccia di tutto e indirizza i messaggi nel posto giusto.

Per avere un'idea della complessità della costruzione di un server di chat lettura del XMPP RFC: RFC 3920 RFC 3921

Answer 2

il modo in cui mi piacerebbe implementare una cosa del genere (se non si utilizza un quadro di riferimento) è il seguente:

hanno un server web (eC2) che accetta i msg dall'utente. utilizza il gruppo Autoscalling su questo server web. il webserver può aggiornare qualsiasi DB su Amazon RDS che può scalare facilmente.

se si utilizza il proprio db, si potrebbe considerare di disaccoppiare il db dal server web utilizzando le SQS (con l'invio di tutte le richieste della stessa coda), e poi u può avere un consumatore che consumano la coda. questo consumatore può anche essere posizionato dietro un gruppo di autoscaling, in modo che se la coda è più grande di X msgs, verrà ridimensionato (è possibile configurarlo con gli allarmi)

sqs normalmente si aggiorna abbastanza velocemente in meno di un secondo. (dal momento in cui l'hai inviato, al momento appare in coda), e raramente di più.

Answer 3

SQS/SNS potrebbe non essere contenute requisito loquace. abbiamo osservato una certa latenza in SQS che potrebbe non essere adatta per un'applicazione di chat. Inoltre SQS non garantisce FIFO. Ho lavorato con Redis su AWS. È abbastanza facile e stabile se è configurato tenendo a mente tutte le migliori pratiche.

Answer 4

Ho pensato di creare un server di chat usando SNS, ma invece di fare un argomento per utente, come descrivi, facendo un argomento per l'intero sistema di chat e facendo in modo che ogni server si iscriva all'argomento - dove ogni server è esecuzione di una sorta di sistema di chat di polling o web socket lungo. Quindi, quando si verifica un evento, i dati vengono inviati nel payload della notifica SNS. Il server può quindi utilizzare questo payload per determinare quali client nella propria coda dovrebbero ricevere la risposta, lasciando intatti tutti i client non correlati. Io in realtà costruito un piccolo prototipo per questo, ma non ho fatto un sacco di test per vedere se è abbastanza robusto per un gran numero di utenti.

Answer 5

Dal momento che un nuovo servizio di AWS IoT ha iniziato a sostenere WebSockets, Keepalive e Pub/Sub paio di mesi fa, si può facilmente costruire videochat elastico su di esso. AWS IoT è un servizio gestito con un sacco di SDK per lingue diverse, tra cui JavaScript che è stato costruito per gestire carichi di mostri (miliardi di messaggi) con la somministrazione zero.

Si può leggere di più su aggiornamento qui:

https://aws.amazon.com/ru/about-aws/whats-new/2016/01/aws-iot-now-supports-websockets-custom-keepalive-intervals-and-enhanced-console/

---

Edit:

Ultimo aggiornamento SQS (2016/11): è ora possibile utilizzare Amazon Simple Queue Service (SQS) per le applicazioni che richiedono che i messaggi vengano elaborati in una sequenza rigorosa e esattamente una volta utilizzando le code FIFO (First-in, First-out). code FIFO sono progettate per assicurare che l'ordine in cui i messaggi vengono inviati e ricevuti è rigorosamente conservato e che ogni messaggio viene elaborato esattamente una volta.

Fonte: https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-sqs-introduces-fifo-queues-with-exactly-once-processing-and-lower-prices-for-standard-queues/

ora in poi, attuazione SQS + SNS sembra una buona idea anche.

Answer 6

HI chat in tempo reale non funziona bene con SNS. È progettato per e-mail/SMS o servizio 1 o qualche secondo di latenza è accettabile.Nella chat in tempo reale, 1 o pochi secondi sono non accettabili.

check this link

Latency (i.e. “Realtime”) for PubNub vs SNS 

Amazon SNS fornisce alcuna garanzia latenza, e la stragrande maggioranza delle latenze vengono misurate più di 1 secondo, e spesso molti secondi più lento. Ancora una volta, questo è alquanto irrilevante; Amazon SNS è progettato per le notifiche da server a server (o email/SMS), dove una latenza di molti secondi è spesso accettabile e prevista.

Poiché PubNub fornisce dati tramite un socket di rete aperto esistente e stabilito, le latenze sono inferiori a 0,25 secondi dalla pubblicazione per iscriversi nel percentile del 95% dei dispositivi sottoscritti. La maggior parte degli umani percepisce qualcosa come "tempo reale" se l'evento è percepito entro 0,6 - 0,7 secondi.