1. 1. Introduction to ZeroMQ 1 December 2011 Pieter Hintjens, iMatix
2. 2. Why did we need MQ?
   • Moore's Law means more moving pieces
   • 3. Cost of connecting pieces was too high
     • Custom TCP or UDP
     • 4. Broker-based messaging
     • 5. Clumsy RPC solutions
   • We needed cheaper connectivity
   • 6. It had to bereally fastandreally simple
3. 7. What is MQ?
   • Intelligent socket library for messaging
   • 8. Many kinds of connection patterns
   • 9. Multiplatform, multi-language (30+)
   • 10. Fast (8M msg/sec, 30usec latency)
   • 11. Small (20K lines of C++ code)
   • 12. Open source LGPL (large community)
4. 13. MQ Hello World import org.zeromq.ZMQ; public class hwclient { public static void main (String[] args){ ZMQ.Context context = ZMQ.context (1); ZMQ.Socket socket = context.socket (ZMQ.REQ); socket.connect ("tcp://localhost:5555"); socket.send ("Hello", 0); System.out.println (socket.recv(0)); } } import org.zeromq.ZMQ; public class hwserver { public static void main (String[] args) { ZMQ.Context context = ZMQ.context(1); ZMQ.Socket socket = context.socket(ZMQ.REP); socket.bind ("tcp://*:5555"); while (true) { byte [] request = socket.recv (0); socket.send("World", 0); } } }
5. 14. Request-Reply Pattern
6. 15. Publish-Subscribe Pattern
7. 16. Pipeline Pattern
8. 17. Simple MQ Application
9. 18. MQ Transports
   • Threads in one process (inproc://)
   • 19. Processes on one box (ipc://)
   • 20. Processes on one network (tcp://)
   • 21. Multicast group (pgm://)
10. 22. Multihop MQ Application
11. 23. Typical MQ Design
12. 24. MQ Routing
    • Round-robin (REQ, PUSH, DEALER)
    • 25. Multicast (PUB)
    • 26. Fair-queuing (REP, SUB, PULL, DEALER)
    • 27. Explicit addressing (ROUTER)
    • 28. Unicast (PAIR)
13. 29. MQ Features
    • Message blobs of 0 to N bytes
    • 30. One socket connect to many sockets
    • 31. Queuing at sender and receiver
    • 32. Automatic TCP (re)connect
    • 33. Zero-copy for large messages
14. 34. MQ for Multithreading
    • Don't use locks, semaphores, mutexes
    • 35. Design app as message-driven tasks
    • 36. Each task reads from 1..n sockets
    • 37. Tasks can talk over inproc://
    • 38. Tasks can be split into processes over tcp://
    • 39. No wait states, no locks, full CPU use
    • 40. Scalable to any number of cores
15. 41. MQ Benefits
    • Start with simple / fast language (Python)
    • 42. Move to faster language where needed (C)
    • 43. Run on arbitrary platforms (Windows, Android)
    • 44. Scale to arbitrary sizes (2 cores, 16 cores...)
    • 45. No per-core or per-seat licensing
    • 46. Easy to experiment and learn
16. 47. Working with MQ
    • Rapid prototyping of main components
    • 48. Small protocols for main flows
    • 49. MQ patterns for main flows
    • 50. Break components up for performance
    • 51. Profile and test
    • 52. Improve incrementally over many cycles
17. 53. MQ Origins
    • iMatix history of enterprise middleware
    • 54. 2004 AMQP standard for JPMorganChase
    • 55. 2005 OpenAMQ message broker/client
    • 56. 2008 MQ/0.x for the avant-garde
    • 57. 2009 MQ/1.x for pioneers (finance)
    • 58. 2010 MQ/2.x for early adopters (foss)
    • 59. 2011 MQ/3.x for mass market (cloud)
18. 60. MQ Community
    • Large, 24/7 community of experts
    • 61. 1,000 people on dev list, 120 on IRC
    • 62. Responsible for everything:
      • Core development & packaging
      • 63. Language bindings (35 or more)
      • 64. Events and presentations
    • MQ is 100% owned by the community
      • Which iMatix is a happy part of
19. 65. MQ Resources
    • www.zeromq.org main web site
    • 66. zero.mq community wiki
    • 67. #zeromq IRC channel on Freenode
    • 68. zeromq-dev email list on zeromq.org
    • 69. github.com/zeromq git repositories
    • 70. zguide.zeromq.org user guide
    • 71. api.zeromq.org reference manual