Vous avez surement déjà rencontré un RabbitMQ ou un Apache Kafka dans vos projets sans trop savoir ce que vous pourriez en faire de plus, à part ce qui avait été prévu au départ , déplacer un message d'une application A vers une Application B. Sachez que ces serveurs de messages ou MOM sont capables de remplir plus de fonctionnalités et de fournir des solutions distribuées, résiliente et scalable répondant à plusieurs types de besoins. Vous serez étonné des uses cases que vous arrivez à résoudre avec un simple RabbitMQ et la bonne configuration. C'est ce que nous verrons ensemble durant cette présentation, nous finirons avec des REX tirées de nos missions.
Speakers : Antonio Gomes Rodrigues, safa mabrouk
10. Comparaison entre spécifications
JMS AMQP STOMP
Interopérab
ilité
Pas possible. Il faut avoir un client
JMS pour le producteur et le
consommateur et il faut avoir un
broker qui est compatible JMS
Complètement possible. Le
broker, le producteur et le
consommateur peuvent
utiliser différents
implémentation
Complètement possible.
Le broker, le producteur et
le consommateur peuvent
utiliser différents
implémentation
Formats d’
échanges
Point to Point
Publish Subscribe
Direct exchange
Fanout Exchange
Topic Exchange
Headers Exchange
System Exchange
Point to Point
Publish Subscribe
Formats de
messages
Object - Map - Text - Bytes -
Stream
Bytes Text
Structure
de
messages
Header section - Properties
section - message body
Header section - Properties
section - message Body
libre
Routing Généralement fait via un module
de routing applicatif. Le
MessageSelector peut être une
forme de routing
Le routing est fait par le
broker en utilisant la routing
key ou les propriétés des
messages et les tables de
binding
Ne fournit pas des
fonctionnalité de routing
20. Garantir la réception et le traitement du message
Partie 1 de la solution : Persistance des messages
21. Garantir la réception et le traitement du message
Partie 1 de la solution : Persistance des messages
22. Garantir la réception et le traitement du message
Partie 1 de la solution : Persistance des messages
FlushACK
23. Garantir la réception et le traitement du message
Partie 1 de la solution : Persistance des messages
ACK
24. Garantir la réception et le traitement du message
Partie 1 de la solution : Persistance des messages
25. Garantir la réception et le traitement du message
Partie 2 de la solution : utilisation d’un Durable Subscriber
26. Garantir la réception et le traitement du message
Partie 2 de la solution : utilisation d’un Durable Subscriber
27. Garantir la réception et le traitement du message
Partie 2 de la solution : utilisation d’un Durable Subscriber
28. Garantir la réception et le traitement du message
Partie 2 de la solution : utilisation d’un Durable Subscriber
29. Garantir la réception et le traitement du message
Partie 2 de la solution : utilisation d’un Durable Subscriber
Message 2 perdu
30. Garantir la réception et le traitement du message
Partie 2 de la solution : utilisation d’un Durable Subscriber
TopicSubscriber subscriber = session. createDurableSubscriber(topic, "subscriber");
31. Garantir la réception et le traitement du message
Partie 2 de la solution : utilisation d’un Durable Subscriber
32. Garantir la réception et le traitement du message
Partie 2 de la solution : utilisation d’un Durable Subscriber
33. Garantir la réception et le traitement du message
Pas de compromis
Client ACK
Plusieurs consommateurs
Client Failover
Durable Subscriber
Persistance des messages
Dead Letter Queue
HA/Cluster
Transaction
ACK
Envoyer à nouveau le
message perdu
34. Favoriser un type de message particulier
Les clients premium avant tout
35. Favoriser un type de message particulier
Les clients premium avant tout
QueueSender clientPayant = QueueSession.createSender(someQueue);
clientPayant.setPriority(9);
clientPayant.send(message, DeliveryMode.NON_PERSISTENT, 9, 0);
38. Garantir l’ordre de consommation des messages
Solution 1 : Regrouper les messages
Message message = session.createTextMessage("Mon super message");
message.setStringProperty(" JMSXGroupID", "Mon groupe");
producer.send(message);
39. Garantir l’ordre d'arrivée des messages
Et je fais comment lorsque j’ai plusieurs producteurs/consommateurs ?
40. Garantir l’ordre de consommation des messages
Solution 2 : Avoir le même ordre de consommation de message pour plusieurs
consommateurs
<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry topic="MonTopic.>">
<dispatchPolicy>
<strictOrderDispatchPolicy/>
</dispatchPolicy>
41. Mode dégradé sous forte charge
Comment ralentir avec le Producer Flow Control
<systemUsage>
<systemUsage>
<memoryUsage>
<memoryUsage limit="64 mb" />
</memoryUsage>
<storeUsage>
<storeUsage limit="100 gb" />
42. Mode dégradé sous forte charge
Comment ralentir avec le Producer Flow Control
43. Mode dégradé sous forte charge
Comment ralentir avec le Producer Flow Control
44. Mode dégradé sous forte charge
Comment ralentir avec le Producer Flow Control
45. Mode dégradé sous forte charge
Comment ralentir avec le Producer Flow Control
48. Lire des vieux messages
Retour vers le futur
topic = new ActiveMQTopic("MonTopic.Topic?consumer.retroactive=true");
consumer = session.createConsumer(topic);
64. Dupliquer le flux ou comment implémenter le pattern Wire Tap
Double run, piste d’audit… tout est possible
<destinationInterceptors>
<mirroredQueue copyMessage = "true" postfix=".mirror" prefix=""/>
</destinationInterceptors>
66. Gérer les traitements lourds en asynchrone et en tâche de fond
Laisser les traitements lourds à notre MOM
67. Gérer les traitements lourds en asynchrone et en tâche de fond
Laisser les traitements lourds à notre MOM
68. Gérer les traitements lourds en asynchrone et en tâche de fond
Laisser les traitements lourds à notre MOM
69. Ne lire que la dernière version du message et éviter du travail inutile par
la même occasion
Less is more
70. Ne lire que la dernière version du message et éviter du travail inutile par
la même occasion
Less is more
71. Ne lire que la dernière version du message et éviter du travail inutile par
la même occasion
Less is more
72. Ne lire que la dernière version du message et éviter du travail inutile par
la même occasion
Less is more
73. Ne lire que la dernière version du message et éviter du travail inutile par
la même occasion
Less is more
TextMessage message = session.createTextMessage("7");
message.setStringProperty("_AMQ_LVQ_NAME", "X");
74. Ne lire que la dernière version du message et éviter du travail inutile par
la même occasion
Less is more
75. Ne lire que la dernière version du message et éviter du travail inutile par
la même occasion
Less is more
84. Implémentation du pattern Event sourcing
Capturer tous les changements de statut d’un objet dans une séquence
d'événement
€
€
€
€
€
€
€
€€
€€ €
85. De l’action pour chaque changement en base
Merci Debezium
Binary log
Purge/update
Update index
Envoi
Synchro
Vue
86. Vers l'infini et au delà
<remoting-incoming-interceptors>
<class-name>MonInterceptor</class-name>
</remoting-incoming-interceptors>
<remoting-outgoing-interceptors>
<class-name>MonInterceptor2</class-name>
</remoting-outgoing-interceptors>
remoting-incoming-
interceptors
BAM
Remoting-output-
interceptors
87. Si on a encore un peu de temps pour...
Rate limited flow control
Delayed Redelivery
Message TTL
Queue TTL
Consummer priorities
Bridge
Synchrone (Request Reply)
Sinon faudra chercher sur Internet