Az üzenetközmű egy közmű technológia, amely üzenetátviteli mechanizmusból vagy üzenetsori módból áll, hatékony és megbízható üzenetküldési mechanizmust alkalmaz platformfüggetlen adatcserére, valamint integrálja az adatkommunikáción alapuló elosztott rendszereket. Jelenleg számos MQ termék van az iparágban, mint például a RabbitMQ, ActiveMQ, ZeroMQ stb., amelyek kiváló üzenetközmű szoftverek, de melyiket válasszuk a projektben? Ez a tanulmány a következő üzenetsor-termékeket értékeli és hasonlítja össze: RabbitMQ, ZeroMQ, ActiveMQ, MSMQ, Redis és memcacheQ
Kitérés: Itt először egy kis kérdésre gondolhatunk: "Miért van szükségünk üzenetsoros szolgáltatásokra a webalkalmazásokban?" ”
Például nagy számú beillesztés, frissítés és egyéb kérés egyszerre érkezik a MySQL-be, ami közvetlenül számtalan sor- és táblazároláshoz vezet, sőt túl sok kéréshez is vezet, így túl sok kapcsolati hibát vált ki. Az üzenetsorok használatával aszinkron módon tudjuk feldolgozni a kéréseket, csökkentve a rendszer terhelését.
RabbitMQ
Ez egy nyílt forráskódú üzenetsor, amelyet Erlang nyelven írtak, és számos protokollt támogat: AMQP, XMPP, SMTP, STOMP, ami nagyon nehézsúlyúvá és inkább vállalati szintű fejlesztésre alkalmasabbá. Ez az AMQP protokoll egyik vezető implementációja, amely egy brókerarchitektúrát valósít meg, ami azt jelenti, hogy az üzeneteket egy központi csomóponton sorba lehet állítani, mielőtt elküldenék az ügyfélnek. Jó támogatás van az útvonaltervezéshez, terheléselosztáshoz vagy adattartóssághoz. Ez a funkció megkönnyíti a RabbitMQ használatát és telepítését, amely sok helyzetre alkalmas, például útvonaltervezéshez, terheléselosztáshoz vagy üzenetkitartáshoz, és csak néhány kódsor üzenetsorral is megoldható. Ez azonban kevésbé skálázhatóvá és lassabbá teszi, mert a központi csomópont növeli a késleltetést, és nagyobb lesz az üzenet kapszulázása után. A RabbitMQ konfigurálásához telepítened kell az Erlang környezetet a célgépre.
Kattintson a kép megtekintéséhez az új ablakban
? MQ(ZeroMQ)
Ez a leggyorsabb üzenetsorrend-rendszerként ismert, különösen nagy áteresztőképességű kereslet esetén. Ez egy nagyon könnyű üzenetküldő rendszer, amelyet kifejezetten nagy áteresztőképességű/alacsony késleltetésű helyzetekhez fejlesztettek, és gyakran megtalálható pénzügyi alkalmazásokban. A RabbitMQ-hoz képest a ZeroMQ sok fejlett üzenetforgatókönyvet támogat, de egyedi blokkokat kell megvalósítani a ZeroMQ keretrendszerben (például socketeket vagy eszközöket, stb.).
? Az MQ (ZeroMQ) képes olyan fejlett/összetett sorokat megvalósítani, amelyekben a RabbitMQ nem jó, de a fejlesztőknek több technikai keretrendszert kell önmaguknak kombinálniuk, és a technikai összetettség kihívást jelent ennek az MQ-nak a sikeres alkalmazásában. A ZeroMQ egyedi, nem köztes szoftveres modellt kínál, ahol nem kell üzenetszervert vagy middleware-t telepítened és futtatnod, mert az alkalmazásod ezt a szolgáltatási szerepet tölti be. Csak a ZeroMQ könyvtárra kell hivatkoznod, amelyet telepíthetsz NuGet-szel, és örömmel küldhetsz üzeneteket alkalmazások között. Azonban a ZeroMQ csak nem tartós sorokat biztosít, ami azt jelenti, hogy ha a gép leáll, az adatok elvesznek. Közülük a Twitter Storm a ZeroMQ-t használja adatfolyamok továbbítására. A ZeroMQ nagyon rugalmas, de meg kell tanulnod a 80 oldalas kézikönyvét (ha elosztott rendszerről írsz, mindenképp olvasd el).
A ZeroMQ-nak nincs middleware architektúrája, és nem igényel szolgáltatási folyamatokat és futtatásokat. Valójában az alkalmazás végpontja is ezt a szolgáltatási szerepet tölti be. Ez nagyon egyszerűvé teszi a telepítést, de az aggodalom az, hogy nincs hol figyelni, ha valami baj történik vele. Tudomásunk szerint a ZeroMQ csak nem állandó sorokat kínál. Saját audit és adat-visszanyerési képességeid is megvalósíthatod, ahol szükséged van rá.
Kattintson a kép megtekintéséhez az új ablakban
MSMQ
Ez az egyetlen dolog a Microsoft termékében, amit értékesnek tartanak. Ha az MSMQ bizonyítani, hogy képes kezelni az ilyen feladatokat, akkor úgy döntenek, hogy használják. A lényeg, hogy ez a dolog nem bonyolult, csak elfogadás és küldés; Vannak kemény korlátai, például a maximális üzenetméret 4MB. Azonban ezeket a problémákat úgy is megoldhatja, ha csatlakozik olyan szoftverekhez, mint a MassTransit vagy az NServiceBus.
Kattintson a kép megtekintéséhez az új ablakban
Jafka/Kafka
A Kafka (amely különböző csomópontok között osztja el az üzeneteket) egy elosztott MQ rendszer, amelyet a LinkedIn fejlesztett és nyílt forráskódúvá tett 2010 decemberében, és jelenleg az Apache inkubációs projektje, amely egy nagy teljesítményű, nyelvek közötti elosztott Publish/Subscribe üzenetsorrend rendszer, és a Jafka a Kafka fölött inkubálódik, amely a Kafka továbbfejlesztett változata. A következő jellemzőkkel rendelkezik: gyors kitartás, amely képes üzeneteket megőrizni O(1) rendszerterhelés alatt; Magas áteresztőképesség, amely egy átlagos szerveren elérheti a 10W/s áteresztőképességet; A teljesen elosztott rendszer, a Broker, Producer és Consumer mind natívan támogatja az elosztott rendszert, és automatikusan eléri a komplex egyensúlyt. Támogatja a Hadoop adatok párhuzamos betöltését, ami életképes megoldás a naplóadatok és offline elemző rendszerekhez, mint a Hadoop, de a valós idejű feldolgozás korlátaival. A Kafka az online és offline üzenetfeldolgozást a Hadoop párhuzamos betöltési mechanizmusán keresztül egyesíti, ami szintén fontos a témában vizsgált rendszer számára. Az Apache Kafka egy nagyon könnyű üzenetküldő rendszer az ActiveMQ-hoz képest, és a kiváló teljesítmény mellett jól működő elosztott rendszer is.
Kattintson a kép megtekintéséhez az új ablakban
Apache ActiveMQ
Az ActiveMQ valahol a kettő (RabbitMQ és ZeroMQ) között helyezkedik el, hasonlóan a ZemoMQ-hoz, és mind proxy, mind P2P módban telepíthető. Hasonlóan a RabbitMQ-hoz, könnyű fejlett forgatókönyveket megvalósítani, és alacsony fogyasztást igényel.
Az ActiveMQ a Java világ gerinceként ismert. Hosszú múltra tekint vissza, és széles körben használják. Emellett több platformot is kínál, természetes integrációs hozzáférési pontot biztosít olyan termékek számára, amelyek nem a Microsoft platformján vannak. Azonban csak akkor lehet figyelembe venni, ha már túl futott az MSMQ-n. Az ActiveMQ konfigurálásához telepítened kell a Java környezetet a célgépre.
Kattintson a kép megtekintéséhez az új ablakban
Fontos megjegyezni, hogy az ActiveMQ következő generációs terméke az Apollo, amely az ActiveMQ prototípusán alapul, és gyorsabb, megbízhatóbb és könnyebben karbantartható üzenetközvetítő eszköz. Az Apache az Apollót a leggyorsabb és legrobusztentebb STOMP (Streaming Text Orientated Message Protocol) szervernek nevezi.
Az Apollo jellemzői a következők:
A Stomp 1.0 és Stomp 1.1 protokollok támogatottak
Témák és sorok
Sorböngő
Tematikus állandó előfizetések
Tükörsor
Megbízható üzenetküldés
Üzenet lejárt és cserélhető
Üzenetválasztó
JAAS hitelesített
ACL-alapú engedélyezés
Támogatás SSL/TLS és tanúsítvány érvényesítése
REST Management API
Kattintson a kép megtekintéséhez az új ablakban
Redis
Ez egy kulcsértékű NoSQL adatbázis, amelyet aktívan fejlesztenek és karbantartanak, bár kulcsérték adatbázis-tárolórendszer, de támogatja a MQ funkciókat, így könnyű sorszolgáltatásként használható. A RabbitMQ és Redis beszálló és kilépési sorban lévő műveleteknél mind-kettő egymillió, a végrehajtási időt pedig 100 000-enként rögzítik. A tesztadatok négy különböző méretre vannak osztva: 128 bájt, 512 bájt, 1 K és 10 K. A kísérletek kimutatták, hogy amikor csatlakozik a csapathoz, Redis teljesítménye magasabb, mint a RabbitMQ-é, ha az adatok összehasonlítása kicsi, és ha az adatméret meghaladja a 10K-t, Redis elviselhetetlenül lassú. Amikor kilépett a csapatból, Redis nagyon jó teljesítményt mutatott, függetlenül az adatok méretétől, míg a RabbitMQ teljesítménye sokkal alacsonyabb volt, mint Redisé.
MemcacheQ
A tartós üzenetsor, a Memcacheq (röviden MCQ) egy könnyű, üzenetsor, amelynek jellemzői:
1 Egyszerű és könnyen használható
2 Gyors feldolgozás
3 Többsoros sor
4 Jó egyidejű teljesítmény
5 Kompatibilis a Memcache protokollval. Ez azt jelenti, hogy csak telepítsd a memcache bővítményt, nincs szükség további pluginokra.
6 A zend keretrendszerben is kényelmes használat.
Végső soron ezek a termékek:
1. Mindkettőnek saját kliens API-ja van, vagy több programozási nyelvet támogat;
2. Rengeteg dokumentáció van;
3. Pozitív támogatást nyújtottak.
4. Az ActiveMQ, RabbitMQ, MSMQ, Redis mind el kell indítani a szolgáltatási folyamatokat, amelyeket lehet monitorolni és konfigurálni, a többi pedig problémás
5. Mindegyik viszonylag jó megbízhatóságot (konzisztenciát), skálázhatóságot és terheléselosztást, valamint természetesen teljesítményt is biztosít
Nem fogok hülyeségeket beszélni, alábbis egy internetről lefogott teszteredmények található. A másodpercenként elküldött és kapott üzenetek száma jelenik meg. Az egész folyamat összesen 1 millió 1K üzenetet generált. A tesztet egy Windows Vista önálló gépen végezték.
Ahogy látod, a ZeroMQ nem olyan szint, mint bármi más. Teljesítménye meglepően magas. Ennek ellenére ez a termék nem biztosít üzenetkitartóságot, nem képes könnyen tárolni és figyelni a köztes folyamatokat, és önauditálást és adatmentést igényel, így nem kielégítő a használat egyszerűsége és a HA szempontjából. A következtetés világos: ha azt szeretnéd, hogy egy alkalmazás a lehető leggyorsabban küldjön üzeneteket, akkor a ZeroMQ-t választod. Értékesebb, ha nem érdekel túl sokat, hogy bizonyos üzenetek véletlenül elveszítenek.
A cikkben szereplő blogger reméli (és nem nagyon reméli), hogy a Rabbit-et használja, a Rabbitmq-nak beépített funkciója van, ha klasztert alkotsz, nem kell aggódni olyan problémák miatt, mint a terheléselosztás, és beállíthatsz egy sortát. De az ilyenkor több tesztelésre lenne szükség, és végül kedvenced lesz, és minden, amit hallottam és olvastam a Rabbitről, azt érzem, hogy ez a legjobb választás.
|
Közzétéve 2016. 12. 15. 10:52:40
|
|
|
|
