Lots of people need job scheduling, microservices communication, asynchronous message passing… There is a stable and reliable solution: AMQP. Event if it seems to be complicated at first, it can solve lots of problems. RabbitMQ is a stable and battle tested product, has great performance, and provides simple access from C, java, python, ruby, node.js, scala, go… This talk is about rabbitMQ, how to start using it, how to work with it, fundamental and various pattern to use it in real world cases. http://www.meetup.com/fr-FR/Leboncoin-Tech/events/228722371/ Video is here https://www.youtube.com/watch?v=VBUQXM96hpw

1. RABBITMQ 101 :
JOB SCHEDULING,
MICROSERVICES
COMMUNICATION, EVENT-
BASED DATA STREAM…
HOW TO COOK THE
RABBIT?
QUENTIN ADAM
@WAXZCE
CLEVER CLOUD

2. Quentin ADAM from the Clever Cloud
@waxzce on twitter – github- soundcloud – instagram ….
WHO AM I ?

3. MY DAY TO DAY WORK :
CLEVER CLOUD, THE IT
AUTOMATION COMPANY

4. And learn a lot of things about your code, apps, and good/bad design…
KEEP YOUR APPS ONLINE. MADE WITH
NODE.JS, SCALA, JAVA, RUBY, PHP,
PYTHON, GO…

5. AND LEARN A LOT OF THINGS ABOUT
YOUR CODE, APPS, AND GOOD/BAD
DESIGN…

6. APPLICATIONS

7. MORE AND MORE COMPLEX

8. SPLIT APPLICATIONS?

9. FOCUS ON SPECIFIC STACK FOR
SPECIFIC USE?

10. COMMON CASE: PHP SITE WITH
WEBSOCKETS, GO TO NODE?

11. APPLICATIONS NEEDS TO
COMMUNICATES

12. WEB DEV FIRST THINK : HTTP

13. UNIDIRECTIONAL

14. NO ACK

15. ROUTING

16. AUTH

17. WHAT DO WE
NEED TO
SHARE WITH
OTHERS
SERVICES?

18. EVENTS

19. DIFFUSE
EVENTS TO ALL
SERVICES
COMPONENTS
WHERE IT’S
NEED

20. MESSAGE BROKER

21. MESSAGE BROKER
• JMS
• 0MQ
• Redis
• Celery
• Kafka
• Files + Cron
• rabbitMQ

22. ADVANCED
MESSAGE
QUEUING
PROTOCOL
PROTOCOL

23. Originally made by JP Morgan Bank (USA)
AMQP

24. Now OASIS section
AMQP

25. Many implementations
AMQP

26. RABBITMQ

27. Is the well known implementation & made with erlang
RABBIT MQ

28. Speak almost all languages and platform
RABBIT MQ

29. FEW
CONCEPTS

30. Think as cluster name for sharing cluster nodes for multiples purpose
VIRTUAL HOST

31. Client pushing messages
PUBLISHER

32. Client getting messages
CONSUMER

33. Yeah, basically tcp + auth
CONNECTIONS

34. “logical connection”
CHANNELS

35. See this as INBOX
EXCHANGES

36. See this as WAY OUT
QUEUES

37. And use a routing key
YOU HAVE TO EXPLICITLY BIND A
QUEUE ON AN EXCHANGE

38. It’s an event, what we need to share
MESSAGES

39. WRAP UP

40. THE DIFFERENT EXCHANGES

41. Perfect repartition with load balancing & routing key
AMQP.DIRECT

42. Tell all messages to Anyone suscribe
AMQP.FANOUT

43. Basically a FANOUT using routing key
AMQP.TOPIC

44. Direct exchange using matching on Headers
AMQP.MATCH

45. LISTENING ONE QUEUE USING MANY
CONSUMERS

46. YOU CAN NOW
DESCRIBE
YOUR
TOPOLOGY

47. ACK

48. STATE OF A MESSAGE SCHEMA

49. NO-ACK DOWNSIDE

50. BUFFER BY CONSUMER

51. QUEUE LIFE CYCLE

52. Disk or RAM debate
LOTS OF MESSAGES IN MEMORY?

53. REQUEST/REPLY PATTERN

54. ENJOY
TOPOLOGY CRASH TEST

55. WRITE
HERE SOME
TOPOLOGY

56. CLUSTER WAY OF LIFE

57. QUEUE HA

58. FEDERATION

59. PLUGINS

60. STOMP, MQTT, WEBSOCKETS

61. More than 5 years production history
IS IT BATTLE TESTED ?

62. WHY IT’S
SO COOL

63. I CAN BRANCH WHERE I WANT

64. EXAMPLE
EVOLUTION OF USAGES

65. PUT HERE
SOME CODE
EXAMPLE

66. Soon a regular add-on
YOU CAN TEST IT ON CLEVER CLOUD ;-)

67. Give CLEVER-CLOUD.COM a try 
I’m @waxzce on twitter
THX FOR LISTENING