Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Switch or broker

2,127 views

Published on

Presentation made to AMQP working group in January 2006

Published in: Software, Technology
  • Be the first to comment

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.

×