1 of 25

How to skin the RabbitMQ

2 of 25

Davide Guida

Principal Software Engineer @ Dell�

https://www.davideguida.com

3 of 25

Agenda

  • Storia
  • Message Flow
  • Tipologie di Exchanges
  • Demo
  • Alternative
  • Q/A

4 of 25

RabbitMQ

È un middleware di messaggistica open source scritto in Erlang nel 2007 da LShift e CohesiveFT come implementazione del protocollo AMQP

Acquistato nel 2010 da SpringSource, una divisione di VMware

Nel 2013 diventa parte di Pivotal Software

5 of 25

RabbitMQ è...

  • Stabile
  • Scalabile
  • Interoperable
  • Praticamente una scheggia
  • Facile da usare ( e da incasinare… )

6 of 25

Principali casi d’uso

RabbitMQ è molto spesso usato per eseguire attivitá in asincrono, oppure quando si vuole separare un’applicazione in moduli e servizi diversi

  • File transcoding
  • Notifications
  • Asynchronous operations
  • Scaling

7 of 25

AMQP

AMQP (Advanced Message Queuing Protocol) è un protocollo di messaggistica che consente alle applicazioni client di ricevere ed inviare messaggi attraverso Messaging Brokers

I Messaging Brokers ricevono messaggi dai Publisher attraverso una Coda e li ridirezionano ai Consumers

Siccome è un protocollo di rete, Publishers, Consumers e Broker possono tutti risiedere su macchine diverse

8 of 25

AMQP

Un Publisher è un’applicazione che invia messaggi

Una Coda (o Queue) è un buffer che conserva i messaggi da processare

Un Consumer è un’applicazione che riceve messaggi e li elabora

9 of 25

RabbitMQ

Un Exchange riceve i messaggi dai Producer e li aggiunge alle Code in base all’algoritmo di routing

Ogni Coda ha un nome ed un Binding con una Routing Key

L’Exchange usa la Routing Key sul messaggio e sul Binding per capire la Coda di destinazione

10 of 25

Message flow

  1. Il Producer pubblica un messaggio sull’Exchange
  2. L’Exchange riceve il messaggio e lo redireziona alla Coda in base alle regole di routing
  3. Ogni coda ha un Binding con un Exchange che definisce il routing
  4. Il messaggio resta sulla coda finché non viene estratto da un Consumer
  5. Il Consumer riceve il messaggio e lo elabora

11 of 25

Connessioni in RabbitMQ

Sia Publisher che Producer devono stabilire una Connessione TCP con Rabbit

Aprire e chiudere una Connessione è molto costoso

I messaggi vengono quindi inviati attraverso i Canali, praticamente “connessioni virtuali” all’interno di quella fisica stabilita in precedenza.

Una best-practice è di avere un Canale per ogni thread dell’applicazione (non sono thread-safe)

12 of 25

Tipologie di Exchanges

  • Direct
  • Default
  • Topic
  • Headers
  • Fanout

13 of 25

Direct Exchange

Molto comodo per separare i messaggi pubblicati sull’Exchange in base alla Routing Key e al Binding con le Code

Ad ogni messaggio è associata una Routing Key

Una Coda riceve un messaggio con chiave “A” se il suo Binding ha la stessa chiave

14 of 25

Default Exchange

Praticamente uguale al Direct Exchange

Il Binding delle Code con l’Exchange usa come chiave il nome della Coda

Utile per scenari semplici

15 of 25

Header Exchange

Simile al Direct Exchange ma invece della Routing Key, vengono usati dei custom headers.

Una Coda può fare il binding su un Exchange usando più header.

Un messaggio viene inviato ad una Coda se tutti gli header corrispondono (o anche no)

16 of 25

Topic Exchange

I messaggi vengono inviati alle Code usando pattern matching con la routing key.

Ad esempio

Routing key: user.deleted

Coda A: users.* <- riceve�Coda B: orders.* <- NON riceve

17 of 25

Fanout Exchange

I messaggi vengono inviati a tutte le Code, ignorando la routing key.

Comodo negli scenari in cui tutti i consumer devono ricevere i messaggi ma li processeranno in maniera diversa

18 of 25

Dead Letter Exchange

Può essere usato per i messaggi impossibili da consegnare

Opzionale, si installa tramite plugin

E’ un exchange normalissimo, appartenente ad una delle precedenti categorie

Ce ne può essere più di uno

19 of 25

Aggiornamento dati del front-end

search.mysite.com

Catalog

Pricing

Localization

Doc DB

Pub/Sub

Background Worker

20 of 25

Demo

21 of 25

Alternative: Redis

Sviluppato nel 2009 da un italiano, Salvatore Sanfilippo per gestire la cache della sua start-up, LLOOGG

E’ sostanzialmente un data store in-memory ad alte performance

Può essere usato sia come un sistema chiave-valore (una cache per intenderci) o come message broker

L’operazione di ricerca e’ estremamente veloce, complessità O(1)

Può memorizzare diversi tipi di dato come liste, insiemi, bit array e stream

22 of 25

Alternative: Apache Kafka

Apache Kafka venne sviluppato da LinkedIn nel 2011 con Scala per facilitare la gestione dei log

E’ pensato per alti volumi di messaggi pub/sub e stream continui, dove l’ordine dei messaggi e’ garantito.

I messaggi vengono salvati su disco e sono accessibili in maniera estremamente veloce e scalabile.

Al contrario di RabbitMQ, Kafka usa un “dumb broker”: gran parte della logica di routing va gestita nei consumer

23 of 25

RabbitMQ vs Kafka vs Redis

RabbitMQ

  • General purpose
  • Ottima interfaccia di gestione
  • Routing complesso
  • Ottima documentazione e supporto ai linguaggi di programmazione

Ottimo per:

  • Operazioni “resource-heavy”
  • Bilanciare il carico su diversi nodi

Apache Kafka

  • Ottima scalabilità orizzontale
  • Messaggi persistenti
  • Replay

Ottimo per:

  • Event Sourcing
  • Stream Processing
  • Website Activity Tracking
  • Metrics
  • Log Aggregation

Redis

  • Molto facile da installare e configurare
  • Buona scalabilità
  • Buone performance con messaggi < 1 MB

Ottimo per:

24 of 25

Domande?

25 of 25