Home > Documents > Messaging - zeromqzeromq.wdfiles.com/local--files/area:whitepapers/messaging-2010-02... · Why...

Messaging - zeromqzeromq.wdfiles.com/local--files/area:whitepapers/messaging-2010-02... · Why...

Date post: 30-Jan-2018
Category:
Author: vuonghuong
View: 216 times
Download: 0 times
Share this document with a friend
Embed Size (px)
of 41 /41
 Messaging  Low Latency, High Throughput, Durable, RESTful, Open, Standards, ..
Transcript
  • Messaging

    LowLatency,HighThroughput,Durable,RESTful,Open,Standards,..

  • Whybother?

    We'vespentyearsmakingmessaging WorkingonprotocolslikeAMQPandRestMS WorkingonsoftwarelikeOpenAMQand

    ZeroMQ WorkingwithpartnerslikeHP,Intel,Cisco Itisalotofwork...:) Thequestionis...why?

  • Messagingsaves$$$

    Messagingsavesapplicationarchitectsmoney Cheapertodesign Cheapertomake Cheapertodeploy Cheapertoscale Cheapertomaintain

  • Howitusedtobe...

    Option1:buildmessagingaspartofyourapplication

    Option2:buyaveryexpensivemessagingsolution

    Option3:cludgesomethingtogether Whereistheopenmessagingstack?

    Fast,efficient,scalable,powerful,etc. Freesoftware,openstandards,competition...

  • AimingforLazy&Stupid

    Lazy&Stupidapplicationsarebest Lazy,becausetheyonlyworkwhentheyhave

    to Applicationsareasynchronous,eventdriven,

    queuedriven

    Stupid,becausetheyknowalmostnothingabouttherestoftheworld Allknowledgeisinthemessageandonlyinthe

    message

  • Whyisthisamazing?

    Totalseparationbetweendevelopersandarchitects

    Messagesarecontracts Justaddandremovepiecestoscale Replaceanypieceatanytime Lowestpossiblecostoverwholeapplifecycle

  • Doweneedproof?

    Internationalbanking:SWIFT Basedonmessages(thousandsofthem) Eachpiece(bank)operatesindependently NowstandardforEuropeanpayments

  • Idealmessaginghas...

    Messagesasblobs Virtualaddressing Queuesallovertheplace Adocumentedwireprotocol Opensourcestacks &theperfectQoS/performancetradeoff

  • QoSvs.Performance

    Storeinmemoryorondisk? Flushtodiskorusewritecache? Uselargerenvelopesorsmallerones? Usebinaryframingortextframing? Multiplexconnectionsornot? Heartbeating...max.messagesize...HTTP

    compatibility...andsoon

  • Whatwelearned

    Thereisnooneanswer.Wefoundthree: Datacentermessaging

    Lowlatency,smallmessages,multicast,thinenvelopes,nosecurity,nopersistence.

    Enterprisemessaging 10xlargermessages,higherlatency,unicast,fatter

    envelopes,basicsecurity,persistence,transactions. Internetmessaging

    highlatency,massivescaleout,paranoidsecurity

  • Andthusweget

    Datacentremessaging 0MQ,libraryforpeertopeermessagingusing

    'hypersocket'paradigm Norealprotocol,justblobencoding

    Enterprisemessaging OpenAMQ,broker+client AMQPprotocol,100pagesorso

    Internetmessaging RestMSprotocol,XMLoverHTTP(RESTful)

  • AlittleaboutiMatix

    Startedin1996tobuildopensourcestacksforInternetapplications

    Developsopensourceproducts(0MQ,OpenAMQ,andothers)

    Sellssupportlicensesandservices PrimarydesignerofAMQPprotocol In2010,stillsupportsOpenVMSclients!

    TouroperatorusingACMSandASTfrontendsforLAT,VT220,TelnetandTN3270,builtbyiMatix.

  • Formoreinformation

    0MQisat www.zeromq.org OpenAMQisat www.openamq.org iMatixisat www.imatix.com Pieterisat [email protected]

  • Fastest.Messaging.Ever.

  • Missingpieceinnetworkingstack

    WhatcanIdo? Buildthemissingpiecemyself. Buyamessagingproduct.

    Physicallayer

    Ethernet,Infinband...

    IP

    TCP,UDP,...

    Application

    ?

  • Buildingityourself

    Doingthesameworkoverandoveragain. Codehastobeimprovedandmaintainedfora

    longtime. Givenenoughdevelopmentiterations,

    messagingcodetendstobecomethemostcomplexpartoftheapplication.

  • Buyingamessagingproduct

    It'sexpensive. It'sterriblyexpensive. Evenifit'sfreeit'sterriblyexpensive. Proof:Smallprojectsneverusemessaging

    thecostwouldkillthem. Tounderstandthecostcomparingitwith

    standardnetworkingstackhelps.

  • Duplicationofnetworkingstack

    Lowerqualityofcode. Lowerperformance. Constrainedfunctionality. Requiresparallelsetof

    skills/admins/developers. Physicallayer

    Ethernet

    IProuting,multiplexing,trafficshaping,...

    TCPflowcontrol,reliability,congestioncontrol,...

    DNSlocation

    Messaginglocation,multiplexing,trafficshaping

    flowcontrol,reliability,routing,...

    Therootsoftheevilarebackin80'swhennetworkingstackwasn'tasubiquitousasitisnow.

    Duplicationcauses:

  • Complexity

    Complexinstallation. Complexadministration. ComplexAPIs. Complexprotocols. Steeplearningcurve. Adoptionofamessagingsystemis

    extremelyexpensive.

  • Nichesolutions

    Messagingsystemsarefocusedonbigcustomersthatcanaffordthecost.

    Theyincorporatealotofnichefunctionalitythat'snotneededforcommonusage.

    Thatmakesthemevenmorecomplexandexpensive.

    Additionally,itmakesthemverylarge.Nowayrunningitonaphoneoranindustrialsensor.

  • Howtoaddresstheproblem?

  • Offloadeverything!

    Messaging

    location(DNS)

    multiplexing(IP)

    security(IPSec,VPN)

    serialisation(GPB,nativelibraries)

    routing(IP)

    flowcontrol(TCP)

    trafficshaping(networking)

    monitoring(networking)

  • Whatarethebenefits?

    Almostnoneedfornicheexperts. SimpleAPIsandprotocols. Lightweightsystem. Betterperformance(includingHWsupport!). Broaderfunctionality. Nottiedtoaspecificniche. Ubiquitous.

  • Extendednetworkingstack

    Physicallayer

    Ethernet

    IP

    TCP

    Application

    Signaltransmission

    Datatransmission,packaging

    Routing,multiplexing,trafficshaping

    Reliability,flowcontrol

    Businesslogic

    Messagingpatterns

    GPBDatatypemarshalling/unmarshalling

  • Huh?Messagingpatterns?

    Patternsofhowthemessagesareexchanged. Messagingpatterninvolvesmultiple

    connectionsbetweenmultipleendpoints. Sofarwe'veidentifiedthreemessaging

    patterns:request/reply,publish/subscribeandmessagestreaming.

  • Request/reply(a.k.a.RPC)

    Workslikeawebserver. Clientsendsarequest,serverresponds. Repliesareroutedtotherightclient

    automatically.

  • Simplerequest/reply(client/server)

    REQREQ REQ

    REP

    request

    reply

    REQzmq::context_tctx(1,1);zmq::socket_ts(ctx,ZMQ_REQ);s.connect(tcp://192.168.0.111:5555);zmq::message_trequest,reply;...s.send(request);s.recv(&reply);...

    REP

    zmq::context_tctx(1,1);zmq::socket_ts(ctx,ZMQ_REP);s.bind(tcp://eth0:5555);zmq::message_trequest,reply;while(true){s.recv(&request);...s.send(reply);}

  • Complexrequest/reply(SOA)

    sharedqueue

    REQ

    REP REP

    REQ

    Queuestoresmessagesevenifthere'snoserviceonline.

    Loadbalancing. Locationtransparency. Multithreadedserver

    scenario.

  • Verycomplexrequest/reply

    REQ

    sharedqueue

    REQ

    REP REP

    WAN

    sharedqueue

    REQ

    REP REP

    failover

  • Publish/subscribe

    It'slikearadiotransmission. Publishersendscontinuousstreamof

    messages,subscribersjointhestream,receivemessages,thenleavethestream.

    Eachmessageisdeliveredtoeverysubscriber. Messagesmaybefilteredw.r.t.topics. Mapstomulticastnicely.

  • Simplepublish/subscribe

    REQSUB*

    SUBforex.*

    REP

    SUBforex.usd

    zmq::context_tctx(1,1);zmq::socket_ts(ctx,ZMQ_SUB);s.setsockopt(ZMQ_SUBSCRIBE,forex.,6);s.connect(pgm://eth0;224.0.0.1:5555);zmq::message_tquote;while(true){s.recv(&quote);}

    PUB

    zmq::context_tctx(1,1);zmq::socket_ts(ctx,ZMQ_PUB);s.bind(pgm://eth0;224.0.0.1:5555);zmq::message_tquote;while(true){...s.send(quote);}

  • Complexpublish/subscribe

    REQSUB*

    SUBforex.*

    REP

    SUBforex.usd

    forwarder

    SUB*

    SUBforex.*

    PUB

    WAN

    TCP

    PGM

    TCP

    PGM

  • Messagestreaming

    ClassicHPCordatacenterscenario. Solvestheproblemofdistributingmonolithic

    applicationonmanyboxes. Tasksarestreamlinedthroughoneormore

    processingsteps. Eachstepcanbehandledbymultiple

    applicationinstances(loadbalancing). Applicationinstancescanbeaddeddynamically

    toaddressactualneeds.

  • Messagestreaming

    queue

    StepA

    StepA

    StepA

    queue

    StepB

    StepB

    StepB

    queue

    zmq::context_tctx(1,1);zmq::socket_tin(ctx,ZMQ_UPSTREAM);s.connect(tcp://192.168.0.111:5555);zmq::socket_tout(ctx,ZMQ_DOWNSTREAM);s.connect(tcp://192.168.0.112:5556);zmq::message_trequest,reply;while(true){in.recv(&request);out.send(reply);}

  • Performance

    Linuxexhibitsendtoendlatenciesof3040us. ThroughputonLinuxis34millionofsmall

    messagespersecondinasinglestream. Gettingthebestpossibleperformanceon

    OpenVMSisaproblemBrettwilladdressinhispresentation.

  • [email protected]

  • OpenAMQ and MQ on OpenVMSPortedtobothOpenVMSAlphaandIntegrity

    Nomajorchallengestoporting

    StandardC/C++code

    OpenVMSCRTLsufficientlycomprehensive

    BiggestjobwasportingApachePortableRuntime(APR)

    OpenAMQusesthisextensively

    PortprovidedbyApacheonOpenVMSveryslow

    ProbablytookadaytoportthebitsofAPRweneeded

    FoundbuginTCP/IPservicessocketpair()function

    Hasbeenfixed

    Somelimitations(butwe'reworkingonit)

    Useofmulticast(OpenPGM)withMQ

  • StillsomeworktodoMultithreadedOpenAMQbrokerstillalittleunstable(singlethreadedisfine)

    Performanceoptimizations

    Latenciesdownto160uswithMQ

    Roomforimprovement Caneasilydo15000messagespersecondwithOpenAMQ

    Thiswillimproveoncewesortoutacoupleofissues Threading Polling

    Supportmodel

    OpenVMSspecificAMQPAPIthatcanbecalledfromanylanguage

    Mostlydone

    TestprogramsinFORTRANandCOBOL

  • Futures

    WorkingonprovidingsupportforthesetechnologiesonOpenVMS

    InvestigatinginclusionofAMQPand/orMQcapabilitiesintoRTR

    VariousotherinterestingplansthatIreallycan'ttalkabout...

    Watchthisspace!

  • [email protected]

  • Questions?

    Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41


Recommended