{"id":38171,"date":"2019-10-31T22:22:03","date_gmt":"2019-10-31T19:22:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-1\/"},"modified":"2019-10-31T22:22:03","modified_gmt":"2019-10-31T19:22:03","slug":"ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-1","title":{"rendered":"Forst\u00e5else af meddelelsesbrokere. Studere mekanikken bag meddelelsesudveksling gennem ActiveMQ og Kafka. Kapitel 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hej alle sammen!<\/p>\n<p>Jeg er begyndt at overs\u00e6tte en lille bog:<br \/>\n\u00ab<b><noindex><a rel=\"nofollow\" href=\"https:\/\/www.oreilly.com\/library\/view\/understanding-message-brokers\/9781492049296\/\">Understanding Message Brokers<\/a><\/noindex><\/b>\u00ab, <br \/>\nforfatter: Jakub Korab, forlag: O'Reilly Media, Inc., udgivelsesdato: juni 2017, ISBN: 9781492049296.<\/p>\n<p>Fra bogens indledning:<br \/>\n\u00ab\u2026 <i>Denne bog vil l\u00e6re dig at t\u00e6nke over systemer til beskedudveksling via m\u00e6glere, ved at sammenligne og kontrastere to popul\u00e6re m\u00e6glerteknologier: Apache ActiveMQ og Apache Kafka. Der vil blive pr\u00e6senteret anvendelseseeksempler og udviklingsmotiver, som har f\u00e5et deres udviklere til at anvende helt forskellige tilgange til det samme omr\u00e5de - beskedudveksling mellem systemer med en m\u00e6gler. Vi vil gennemg\u00e5 disse teknologier fra bunden og fremh\u00e6ve indflydelsen af forskellige designvalg undervejs. Du vil f\u00e5 en dybdeg\u00e5ende forst\u00e5else af begge produkter, vide hvordan de skal og ikke skal bruges, samt vide, hvad du skal v\u00e6re opm\u00e6rksom p\u00e5, n\u00e5r du overvejer andre teknologier til beskedudveksling i fremtiden.<\/i> \u2026\u00bb<\/p>\n<p>De dele, der er blevet oversat indtil nu:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\">Kapitel 1. Introduktion<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466585\">Kapitel 3. Kafka<\/a><\/noindex><\/p>\n<p>Jeg vil offentligg\u00f8re de f\u00e6rdige kapitler, efterh\u00e5nden som de bliver oversat.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>KAPITEL 1<\/h2>\n<p><\/p>\n<h2>Introduktion<\/h2>\n<p>\nBeskedudveksling mellem systemer er et af de mindst forst\u00e5ede omr\u00e5der inden for IT. Som udvikler eller arkitekt kan du v\u00e6re godt bekendt med forskellige rammer og databaser. Men det er meget sandsynligt, at du kun har en overfladisk forst\u00e5else af, hvordan m\u00e6glerbaserede beskedteknologier fungerer. Hvis du har det p\u00e5 denne m\u00e5de, s\u00e5 frygt ikke, du er i godt selskab.<\/p>\n<p>Folk interagerer typisk med beskedudvekslingsinfrastrukturen i meget begr\u00e6nset omfang. Det er ikke sj\u00e6ldent, at de tilslutter sig et system, der er blevet bygget for l\u00e6nge siden, eller downloader et distributionsprogram fra internettet, installerer det i PRODUKTION og begynder at skrive kode til det. Efter at infrastrukturen er blevet startet i PRODUKTION, kan resultaterne v\u00e6re tvetydige: tab af beskeder ved fejl, sending fungerer ikke som forventet, eller m\u00e6glere \"h\u00e6nger\" dine producenter eller sender ikke beskeder til dine forbrugere.<\/p>\n<p>Lyder det bekendt?<\/p>\n<p>Et almindeligt scenarie er, n\u00e5r din meddelelsesudvekslingskode fungerer perfekt, indtil den pludselig holder op med at virke. Denne periode kan f\u00f8re til falsk tryghed og en f\u00f8lelse af sikkerhed, hvilket resulterer i endnu mere kode, der er baseret p\u00e5 fejlagtige opfattelser af den grundl\u00e6ggende teknologiopf\u00f8rsel. N\u00e5r noget g\u00e5r galt, konfronteres du med en ubehagelig sandhed: at du faktisk ikke forstod produktets grundl\u00e6ggende adf\u00e6rd eller de kompromiser, som udviklerne har valgt, s\u00e5som ydeevne versus p\u00e5lidelighed, eller transaktionalitet versus horisontal skal\u00e9rbarhed.<\/p>\n<p>Uden en dyb forst\u00e5else af, hvordan m\u00e6glere fungerer, kommer folk til at lave tilsyneladende rimelige udsagn om deres meddelelsessystemer, s\u00e5som:<\/p>\n<ul>\n<li>Systemet vil aldrig miste beskeder<\/li>\n<li>Beskeder vil blive behandlet i r\u00e6kkef\u00f8lge<\/li>\n<li>Tilf\u00f8jelse af forbrugere vil g\u00f8re systemet hurtigere<\/li>\n<li>Beskeder vil blive leveret kun \u00e9n gang<\/li>\n<\/ul>\n<p>\nDesv\u00e6rre er nogle af disse udsagn baseret p\u00e5 antagelser, der kun g\u00e6lder under bestemte omst\u00e6ndigheder, mens andre simpelthen er forkerte.<\/p>\n<p>Denne bog vil l\u00e6re dig at t\u00e6nke over meddelelsessystemer baseret p\u00e5 m\u00e6glere ved at sammenligne og kontrastere to popul\u00e6re m\u00e6glerteknologier: Apache ActiveMQ og Apache Kafka. Her vil der blive pr\u00e6senteret brugstilf\u00e6lde og udviklingsincitamenter, der har f\u00f8rt til, at deres udviklere anvendte vidt forskellige tilgange til det samme omr\u00e5de \u2013 meddelelsesudveksling mellem systemer med en m\u00e6gler. Vi vil se p\u00e5 disse teknologier fra bunden og fremh\u00e6ve indflydelsen fra forskellige designmuligheder p\u00e5 denne rejse. Du vil f\u00e5 en dybdeg\u00e5ende forst\u00e5else af begge produkter, indsigt i, hvordan de b\u00f8r og ikke b\u00f8r anvendes, samt hvad du skal v\u00e6re opm\u00e6rksom p\u00e5, n\u00e5r du overvejer andre meddelelsesteknologier i fremtiden.<\/p>\n<p>F\u00f8r vi begynder, lad os gennemg\u00e5 grundl\u00e6ggende principper.<\/p>\n<h3>Hvad er et meddelelsessystem, og hvorfor er det n\u00f8dvendigt<\/h3>\n<p>\nFor two applications to communicate with each other, they first need to define an interface. Defining this interface includes choosing a transport or protocol, such as HTTP, MQTT, or SMTP, and agreeing on the message formats to be exchanged by the systems. This can be a strict process, such as defining an XML schema with payload requirements for the message, or it can be much less formal, like an agreement between two developers that a certain part of the HTTP request will contain the client ID.<\/p>\n<p>As long as the message formats and the order in which they are sent between the systems are agreed upon, they will be able to interact with each other without worrying about the implementation of the other system. The internals of these systems, such as the programming language or framework used, can change over time. As long as the contract itself is maintained, interaction can continue unchanged from the other side. These two systems are effectively decoupled by this interface.<\/p>\n<p>Messaging systems typically involve a mediator between the two systems that interact to further decouple the sender from the recipient or recipients. In this way, the messaging system allows the sender to send a message without knowing where the recipient is, whether they are active, or how many instances there are.<\/p>\n<p>Let\u2019s consider a couple of analogies of the types of problems that a messaging system solves, and introduce some basic terms.<\/p>\n<h4>Point-to-Point<\/h4>\n<p><\/p>\n<blockquote><p>Alexandra goes to the post office to send a package to Adam. She approaches the window and hands the package to the clerk. The clerk takes the package and gives Alexandra a receipt. Adam does not need to be home at the time of sending the package. Alexandra is confident that the package will be delivered to Adam at some point in the future and can continue with her business. Later, at some point, Adam receives the package.<\/p><\/blockquote>\n<p>This is an example of a messaging model <i>point-to-point<\/i>. The post office acts here as a mechanism for distributing packages, ensuring that each package is delivered exactly once. Using the post office separates the act of sending a package from delivering it.<br \/>\nI klassiske beskedudvekslingssystemer implementeres 'point-to-point'-modellen gennem <i>af<\/i>. En k\u00f8 fungerer som en FIFO-buffer (f\u00f8rst ind, f\u00f8rst ud), som \u00e9n eller flere forbrugere kan abonnere p\u00e5. Hver besked leveres kun <i>til \u00e9n af de tilmeldte forbrugere<\/i>. K\u00f8er fors\u00f8ger normalt at fordele beskeder retf\u00e6rdigt mellem forbrugerne. Kun \u00e9n forbruger vil modtage den p\u00e5g\u00e6ldende besked.<\/p>\n<p>K\u00f8er anvendes ofte med termen 'p\u00e5lidelig' ('durable'). <i>P\u00e5lidelighed <\/i> \u2014 det er en egenskab ved tjenesten, der sikrer, at beskedudvekslingssystemet vil gemme beskeder, n\u00e5r der ikke er aktive abonnenter, indtil en forbruger tilmelder sig k\u00f8en for at modtage beskeder.<\/p>\n<p>P\u00e5lidelighed forveksles ofte med <i>persistens<\/i> , og selvom disse to termer kan bruges om hinanden, udf\u00f8rer de forskellige funktioner. Persistens definerer, om systemet til beskedudveksling skriver en besked til en form for lager mellem modtagelsen og leveringen til forbrugeren. Beskeder sendt til k\u00f8en kan v\u00e6re eller ikke v\u00e6re persistente.<br \/>\nBeskedudveksling af 'point-to-point'-typen anvendes, n\u00e5r brugsscenariet kr\u00e6ver en enkelt handling med beskeden. Et eksempel kunne v\u00e6re at indbetale penge p\u00e5 en konto eller gennemf\u00f8re en leveringsbestilling. Vi vil senere diskutere, hvorfor beskedudvekslingssystemet ikke i sig selv kan garantere en enkelt levering, og hvorfor k\u00f8er kun i bedste fald kan sikre levering <i>mindst \u00e9n gang<\/i>.<\/p>\n<h4>Publisher-Subscriber<\/h4>\n<p><\/p>\n<blockquote><p>Gabriella ringer op til konferenceopkaldet. Mens hun er tilsluttet konferencen, h\u00f8rer hun alt, hvad taleren siger, sammen med de andre deltagere i opkaldet. N\u00e5r hun afbryder forbindelsen, g\u00e5r hun glip af hvad der bliver sagt. Ved at genoprette forbindelsen kan hun forts\u00e6tte med at h\u00f8re, hvad der bliver sagt.<\/p><\/blockquote>\n<p> This is an example of a messaging model <i>publikation-abonnement<\/i>. Konferenceopkald fungerer som en broadcastmekanisme. Taleren bryder sig ikke om, hvor mange mennesker der i \u00f8jeblikket er tilsluttet opkaldet \u2014 systemet sikrer, at enhver, der tilslutter sig, h\u00f8rer, hvad der bliver sagt.<br \/>\nI klassiske beskedudvekslingssystemer implementeres 'publikation-abonnement'-modellen gennem <i>emner<\/i>Et emne giver en lige s\u00e5 god mulighed for broadcast som konferencetelefoni-mekanismen. N\u00e5r en besked sendes til emnet, distribueres det <i>til alle tilmeldte brugere.<\/i>.<\/p>\n<p>Emner er typisk <i>ikke-p\u00e5lidelige (nondurable).<\/i>Ligesom en lytter, der ikke h\u00f8rer, hvad der bliver sagt p\u00e5 konferencen, n\u00e5r lytteren slukker, g\u00e5r emnets abonnenter glip af meddelelser, der sendes, mens de er offline. Af denne grund kan det siges, at emner giver en leveringsgaranti <i>ikke mere end \u00e9n gang <\/i>for hver forbruger.<\/p>\n<p>Messaging-typologien \"publikation-abonnement\" bruges typisk, n\u00e5r meddelelserne er informerende, og tabet af en enkelt meddelelse ikke er af s\u00e6rlig betydning. For eksempel kan et emne transmittere temperaturm\u00e5linger fra en gruppe sensorer \u00e9n gang i sekundet. Et system, der er interesseret i den aktuelle temperatur og som abonnerer p\u00e5 emnet, vil ikke bekymre sig, hvis det g\u00e5r glip af en meddelelse \u2014 en anden vil komme i n\u00e6r fremtid.<\/p>\n<h4>Hybridmodeller<\/h4>\n<p><\/p>\n<blockquote><p>Webshoppen placerer beskeder om ordrer i en \"beskedk\u00f8\". Den prim\u00e6re forbruger af disse beskeder er det eksekverende system. Derudover skal revisionssystemet have kopier af disse beskeder om ordrer til senere opf\u00f8lgning. Begge systemer m\u00e5 ikke g\u00e5 glip af beskeder, selvom systemerne selv er utilg\u00e6ngelige i en periode. Webshoppen skal ikke kende til de andre systemer.<\/p><\/blockquote>\n<p> Brugsscenarier kr\u00e6ver ofte en kombination af messaging-modellerne \"publikation-abonnement\" og \"punkt-til-punkt\", for eksempel n\u00e5r flere systemer har brug for en kopi af meddelelsen, og b\u00e5de p\u00e5lidelighed og persistens er n\u00f8dvendige for at forhindre tab af meddelelser.<\/p>\n<p>I disse tilf\u00e6lde kr\u00e6ves en modtager (destination) (et generelt udtryk for k\u00f8er og emner), som distribuerer beskeder is\u00e6r som et emne, s\u00e5 hver besked sendes til et separat system, der er interesseret i disse beskeder, men hvor hver system kan definere flere forbrugere, der modtager indkommende meddelelser, hvilket mere ligner en k\u00f8. L\u00e6setypen i dette tilf\u00e6lde er <i>\u00e9n gang for hver interesseret part.<\/i>Disse hybride adresser kr\u00e6ver ofte p\u00e5lidelighed, s\u00e5 hvis forbrugeren bliver frakoblet, accepteres de beskeder, der sendes i den periode, n\u00e5r forbrugeren genopretter forbindelsen.<\/p>\n<p>Hybride modeller er ikke nye og kan anvendes i de fleste meddelelsessystemer, herunder b\u00e5de ActiveMQ (gennem virtuelle eller sammensatte adresser, der kombinerer emner og k\u00f8er) og Kafka (implicit, som et grundl\u00e6ggende designelement af dens adresse).<\/p>\n<p>Nu hvor vi har noget grundl\u00e6ggende terminologi og forst\u00e5else af, hvad vi m\u00e5ske ville f\u00e5 brug for et meddelelsessystem til, lad os g\u00e5 videre til detaljerne.<\/p>\n<p><b> Overs\u00e6ttelsen er udf\u00f8rt: <noindex><a rel=\"nofollow\" href=\"http:\/\/tele.gg\/middle_java\">tele.gg\/middle_java<\/a><\/noindex><\/b><\/p>\n<p>N\u00e6ste oversatte del: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466585\">Kapitel 3. Kafka<\/a><\/noindex><\/p>\n<p><i>Forts\u00e6ttelsen f\u00f8lger\u2026<\/i><br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430\u0447\u0430\u043b \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: &#171;Understanding Message Brokers&#171;, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#8217;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u0418\u0437 \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u043a \u043a\u043d\u0438\u0433\u0435: &#171;\u2026 \u042d\u0442\u0430 \u043a\u043d\u0438\u0433\u0430 \u043d\u0430\u0443\u0447\u0438\u0442 \u0432\u0430\u0441 \u0440\u0430\u0441\u0441\u0443\u0436\u0434\u0430\u0442\u044c \u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043d\u0430 \u0431\u0440\u043e\u043a\u0435\u0440\u0430\u0445, \u0441\u0440\u0430\u0432\u043d\u0438\u0432\u0430\u044f \u0438 \u043f\u0440\u043e\u0442\u0438\u0432\u043e\u043f\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044f \u0434\u0432\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432: Apache ActiveMQ \u0438 Apache Kafka. \u0417\u0434\u0435\u0441\u044c \u0431\u0443\u0434\u0443\u0442 \u0438\u0437\u043b\u043e\u0436\u0435\u043d\u044b \u043f\u0440\u0438\u043c\u0435\u0440\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38171","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430\u0447\u0430\u043b \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: &quot;Understanding Message.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-1\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 1 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430\u0447\u0430\u043b \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: &quot;Understanding Message.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-1\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:22:03+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:22:03+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Forst\u00e5else af meddelelsesbrokere. En unders\u00f8gelse af mekanikken bag meddelelsesudveksling gennem ActiveMQ og Kafka. Kapitel 1 | ProHoster","description":"Hej alle sammen! Jeg er begyndt at overs\u00e6tte en lille bog: \"Understanding Message.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 1 | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041d\u0430\u0447\u0430\u043b \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: &quot;Understanding Message.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:22:03+00:00","article:modified_time":"2019-10-31T19:22:03+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38171","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 20:46:00","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:14:22","updated":"2026-01-23 20:46:00","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=38171"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38171\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=38171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=38171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=38171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}