Switch or broker

1,104 views
1,224 views

Published on

Presentation made to AMQP working group in January 2006

Published in: Software, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,104
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Switch or broker

  1. 1. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Switch or Broker? A comparison of two models for reliable AMQP architectures by Pieter Hintjens, iMatix Corporation January, 2006
  2. 2. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 The Classic View ● The "reliable message broker" ● Big, powerful message broker ● Uses high-availability and transactions ● Queues are durable, persistent, heavy ● Consistent with traditional world view ● Strong centralization ● One place to look for all data ● One server to configure, administer, etc.
  3. 3. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Reliable message broker App App App App Reliable message broker Persistent queues
  4. 4. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 What do we get? ● Point-to-point reliability ● When we have successfully passed a message to the broker, we can be sure it will be deliv- ered to the recipient. ● If there is a recipient... ● Pretty complex ● Pedantic message delivery ● Distributed transaction processing ● Performance vs. persistence trade-offs
  5. 5. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 High-availability cluster App App App App ?
  6. 6. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 HA reliability challenges ● Guarantee reliability during failover ● Coordination between HA peers ● Transactions between HA peers ● A problem area for most products ● Presumably a solvable problem... ● But even MQ Series occasionally drops mes- sages ● Broker is now very complex ● ...and HA is visible in the protocol
  7. 7. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 What about wide-area networks? ? ? ?
  8. 8. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 WAN reliability challenges ● Only as reliable as weakest link ● Excludes use of untrusted middlemen ● Excludes use of thin "edge" brokers ● Contrary to modern network design ● Requires few, expensive boxes ● Does not scale by adding hardware ● Reliability through complexity?
  9. 9. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 The iMatix View ● The "asynchronous message switch" ● Cheap, disposable message switches ● Organized into high-availability pairs ● Queues are transient and memory-based ● Consistent with modern world view ● Cheap and simple ● No data to look for ● Minimal configuration and administration
  10. 10. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Asynchronous message switch App App App App Asynchronous message switch
  11. 11. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 What do we get? ● No reliability in protocol or server ● Messages can be lost en-route ● Very simple ● Trivial message delivery ● No transactions ● Fastest possible performance ● Message loss is very rare ● But... ● Of course, we need full reliability
  12. 12. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Reliability over AMS (R/AMS) ● Three main messaging scenarios ● Data distribution (pub-sub) ● Request-response (service request) ● Data distribution can be unreliable ● Data can be resent periodically ● Request-response should be reliable ● This is the classic MQ scenario
  13. 13. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 R/AMS schema App App App App Persistence Asynchronous message switch
  14. 14. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 R/AMS technique ● Client API provides two messaging APIs ● Data distribution ● Request-response (R-R) ● R/AMS is implemented for R-R only ● Record request in store ● Send request to AMQP server ● Wait for a matching response ● If needed, send the request again ● When response arrives, update store ● After timeout, alert application to failure
  15. 15. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 R/AMS with a HA cluster App App App App Persistence
  16. 16. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 R/AMS + HA is simple ● No assumption of reliability in network ● HA is limited to peer-coordination ● No message flow between peers ● Proven solution in production use ● Broker remains relatively simple ● HA is invisible in the protocol ● Persistence is also invisible
  17. 17. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 What about wide-area networks?
  18. 18. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 R/AMS + WAN is simple ● No assumption of reliability in network ● It does not matter how large network grows ● Reliability is orthogonal to network ● Allows use of untrusted middlemen ● Allows use of thin "edge" servers ● Moves towards "AMQP in every wall- plug" vision
  19. 19. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Why is R/AMS nice? ● Protocol remains simple ● Even simpler than 0.8 release ● Brokers remain simple & light ● No persistence, no transactions, no acks ● R/AMS is (almost) unilateral ● No interoperability burden ● Recipient must detect & discard duplicates ● R/AMS is easy to understand ● Very intuitive, obvious for programmers
  20. 20. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 R/AMS is fast ● Data distribution can be scaled ● AMS fanout for high volumes & subscribers ● Zero overhead for data distribution ● No centralized storage bottleneck ● Reliable message broker can only run as fast as its data store ● Asynchronous message switch runs at full speed ● Persistence cost is spread out across network
  21. 21. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Can R/AMS do everything? ● No, it cannot ● R/AMS is a "90%" solution ● Specifically for request-response ● Also solves data distribution optimally ● Does not do file distribution ● Does not do other messaging models ● But... these can be layered on top ● Cannot solve “MQ Series” challenge
  22. 22. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 R/AMS as a transport layer ● How do we implement file distribution? ● Consider R/AMS as a transport layer ● Use only request-response messaging ● Construct services around R/AMS ● File distribution over R/AMS: ● Through use of "file broker" application ● R/AMS to and from file broker
  23. 23. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Vision of AMQP for R/AMS ● Fastest possible transport layer (SCTP) ● Removal of all reliability from protocol ● New "thin" content class ● No persistent messages ● No transactions ● No acknowledgments ● Stripped-down message properties
  24. 24. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 AMQP evolution for R/AMS ● Orthogonal transport protocols ● Ability to choose between TCP/IP, SCTP ● Central wiring management layer ● Exchanges, queues, bindings ● Orthogonal content classes ● Basic content class, thin content class ● No content class interoperability
  25. 25. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Switch vs Broker Switch ● Simple protocol ● Simple server ● Edge storage ● Intelligent API ● WAN friendly ● Silicon friendly ● Unconventional Broker ● Complex protocol ● Complex server ● Central storage ● Simple client API ● WAN hostile ● Silicon hostile ● Conventional
  26. 26. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Conclusions ● R/AMS has significant advantages ● Simply, cheap, flexible ● Compatible with AMQP->hardware strategy ● Elegant solution for HA & WAN ● Reliable message broker is outdated ● Solves problems of the past ● R/AMS is future-proof design ● Cheap, scalable, simple ● Forces standard messaging patterns
  27. 27. Copyright © 2006-2007 iMatix Corporation CreativeCommons Attribution-Share Alike 2.5 Thank you ● For more information please contact the author at ph@imatix.com.

×