वेबस्पेयर एमक्यू या टिबको रेंडेज़वस जैसे मैसेजिंग समाधानों के बजाय अभिनेताओं का उपयोग कब करें?

Question

मैंने पहले ही What design decisions would favour Scala's Actors instead of JMS? पर प्रश्न और उत्तर पढ़े हैं।

आमतौर पर, हम मैसेजिंग समाधान का उपयोग करते हैं जो कि पहले से ही अस्तित्व में है: या तो वेबस्पेयर एमक्यू या अपाचे एक्टिवएमक्यू जैसे जेएमएस कार्यान्वयन का उपयोग पॉइंट-टू-प्वाइंट संचार के लिए किया जाता है, या मल्टीकास्ट मैसेजिंग के लिए टिब्को रेंडेवस।

वे बहुत स्थिर, सिद्ध और उच्च उपलब्धता और प्रदर्शन प्रदान करते हैं। फिर भी, विनका और सेटअप अक्का की तुलना में अधिक जटिल लगते हैं।

कुछ उपयोग मामलों के लिए मुझे अक्का का उपयोग क्यों करना चाहिए, जहां उपरोक्त उत्पादों - वेबस्पेयर एमक्यू या एक्टिवएमक्यू का सफलतापूर्वक उपयोग किया गया है? मुझे अपनी भविष्य की परियोजना में वेबस्पेयर एमक्यू या तिब्को आरवी के बजाय अक्का का उपयोग क्यों करना चाहिए?

और मुझे अकका से कब बचना चाहिए? क्या यह अन्य समाधानों के समान उच्च उपलब्धता और प्रदर्शन प्रदान करता है? या क्या अक्का को अन्य मैसेजिंग मिडलवायर से तुलना करना भी बुरा विचार है?

शायद जेवीएम पर्यावरण में एक और संदेश समाधान भी है जिसे मुझे जेएमएस (प्वाइंट-टू-प्वाइंट), तिब्कोआरवी (मल्टीकास्ट) और अक्का के अलावा विचार करना चाहिए?

Answer 1

मै मैसेजिंग सिस्टम में कोई विशेषज्ञ नहीं हूं, लेकिन आप उन्हें अपने ऐप्स में अक्का के साथ जोड़ सकते हैं, दोनों दुनिया के सर्वश्रेष्ठ प्राप्त कर सकते हैं। यहाँ एक उदाहरण है कि आप इस मामले में, अक्का और संदेश प्रणाली के साथ प्रयोग ZeroMQ के लिए उपयोगी लग सकते है:

https://github.com/zcox/akka-zeromq-java

Answer 2

सबसे पहले "पुराने" संदेश सिस्टम (MQ) कार्यान्वयन में पुराने हैं, लेकिन वे एक नए हैं इंजीनियरिंग विचार में: लेनदेन लगातार लगातार कतार। स्कैला अभिनेता और अक्का शायद एक नया कार्यान्वयन है लेकिन अभिनेताओं के पुराने समवर्ती मॉडल पर बनाया गया है।

हालांकि दो मॉडल अभ्यास में बहुत समान हैं क्योंकि वे दोनों ईवेंट संदेश आधारित हैं: RabbitMQ vs Akka पर मेरा उत्तर देखें।

यदि आप केवल JVM के लिए कोड पर जा रहे हैं तो अक्का शायद एक अच्छी पसंद है। अन्यथा मैं RabbitMQ का उपयोग करूंगा।

यदि आप स्कैला डेवलपर हैं, तो अक्का को कोई ब्रेनर नहीं होना चाहिए। हालांकि अक्का की जावा बाइंडिंग बहुत जावा-आश नहीं हैं और स्कैला के प्रकार प्रणाली के कारण कास्टिंग की आवश्यकता है।

जावा में भी लोग आम तौर पर अपरिवर्तनीय वस्तुएं नहीं बनाते हैं जो मैं आपको संदेश के लिए करने की सलाह देता हूं। नतीजतन जावा में यह बहुत आसान है कि अक्का का उपयोग करके कुछ ऐसा करें जो स्केल नहीं करेगा (संदेश के लिए म्यूटेबल ऑब्जेक्ट्स का उपयोग करके, अजीब बंद कॉलबैक स्थिति पर निर्भर करता है)। एमक्यू के साथ यह कोई समस्या नहीं है क्योंकि संदेश हमेशा गति की कीमत पर क्रमबद्ध होते हैं। अक्का के साथ वे आम तौर पर नहीं होते हैं।

अक्का भी अधिकांश एमक्यू की तुलना में बड़ी मात्रा में उपभोक्ताओं के साथ बेहतर पैमाने पर स्केल करता है। ऐसा इसलिए है क्योंकि अधिकांश एमक्यू (जेएमएस, एएमक्यूपी) ग्राहकों के लिए प्रत्येक कतार कनेक्शन के लिए एक थ्रेड की आवश्यकता होती है ... इस प्रकार बहुत सारे कतार == बहुत सारे स्थायी रूप से चल रहे थ्रेड होते हैं। हालांकि यह मुख्य रूप से एक ग्राहक मुद्दा है। मुझे लगता है कि ActiveMQ अपोलो में एक गैर-अवरोधक प्रेषक है जो एएमक्यूपी के लिए उस मुद्दे को स्पष्ट रूप से ठीक करता है। खरगोश एमक्यू क्लाइंट में ऐसे चैनल होते हैं जो आपको कई उपभोक्ताओं को गठबंधन करने की अनुमति देते हैं लेकिन अभी भी बड़ी संख्या में उपभोक्ताओं के साथ समस्याएं हैं जो संभावित रूप से डेडलॉक्स या कनेक्शन मरने का कारण बनती हैं, इसलिए आम तौर पर इस मुद्दे से बचने के लिए अधिक धागे जोड़े जाते हैं।

कहा जा रहा है कि Akka's remoting अपेक्षाकृत नया है और शायद अभी भी सभी विश्वसनीय संदेश गारंटी और क्यूओएस प्रदान नहीं करता है कि पारंपरिक संदेश कतार प्रदान करते हैं (लेकिन यह हर रोज बदल रहा है)। यह आम तौर पर पीयर-टू-पीयर भी है, लेकिन मुझे लगता है कि समर्थन सर्वर-टू-पीयर जो आम तौर पर अधिकांश एमक्यू सिस्टम (यानी असफलता का एक बिंदु) करता है लेकिन एमक्यू सिस्टम हैं जो पीयर-टू-पीयर हैं (RabbitMQ सर्वर- झांकना)।

अंत में खरगोश एमक्यू और अकका वास्तव में एक अच्छी जोड़ी बनाते हैं। आप अब्का को रैपिटएमक्यू के लिए एक रैपर के रूप में उपयोग कर सकते हैं, खासकर जब से RabbitMQ संदेशों की खपत को संभालने और स्थानीय रूप से संदेशों को रूट करने में मदद नहीं करता है (एक एकल जेवीएम में)।

जब अक्का चुनने के लिए

• उपभोक्ताओं के बहुत सारे (लाखों लगता है) है।
• कम विलंबता अभिनेता संगामिति मॉडल के लिए

उदाहरण प्रणाली की आवश्यकता है

ओपन: एक इंटरैक्टिव वास्तविक समय चैट प्रणाली

जब MQ

• करने की आवश्यकता है चुनने के लिए कई अलग-अलग प्रणालियों (यानी गैर जेवीएम) के साथ एकीकृत करें
• संदेश विश्वसनीयता विलंबता से ज्यादा महत्वपूर्ण है
• अधिक उपकरण और व्यवस्थापक यूआई चाहेंगे
क्योंकि पिछले अंक लंबी चलने कार्यों के लिए बेहतर
• अभिनेता तुलना में एक अलग संगामिति मॉडल का उपयोग करना चाहेंगे की

उदाहरण प्रणाली: एक निर्धारित लेनदेन बैच प्रसंस्करण प्रणाली

संबंधित टिप्पणियों के आधार पर संपादित करें

मैंने एक धारणा की है कि ओपी वितरित प्रसंस्करण से संबंधित था जो Akka और संदेश पंक्तियां संभाल सकती हैं। मुझे लगता है कि वह distributed Akka के बारे में बात कर रहा था। स्थानीय समेकन के लिए अक्का का उपयोग अधिकांश संदेश कतार से नारंगी तुलना करने के लिए एक सेब है। मैं सबसे ज्यादा कहता हूं क्योंकि आप संदेश कतार मॉडल को स्थानीय रूप से एक समवर्ती मॉडल (यानी विषय, कतार, एक्सचेंज) के रूप में लागू कर सकते हैं, जो Reactor लाइब्रेरी और simple-react दोनों करते हैं।

कम विलंबता अनुप्रयोग/पुस्तकालय चुनना कम विलंबता अनुप्रयोगों के लिए बहुत महत्वपूर्ण है। एक संदेश कतार जैसे एक वितरित प्रसंस्करण समाधान आम तौर पर आदर्श नहीं है क्योंकि रूटिंग लगभग हमेशा तार पर किया जाता है जो स्पष्ट रूप से आवेदन के मुकाबले धीमा होता है और इस प्रकार अक्का बेहतर विकल्प होगा। हालांकि मुझे विश्वास है कि कुछ स्वामित्व वाली एमक्यू प्रौद्योगिकियां स्थानीय रूटिंग के लिए अनुमति देती हैं। जैसा कि मैंने पहले उल्लेख किया था कि अधिकांश एमक्यू क्लाइंट थ्रेडिंग के बारे में बहुत बेवकूफ हैं और गैर-अवरुद्ध आईओ पर भरोसा नहीं करते हैं और प्रति कनेक्शन/कतार/चैनल धागा है ... विडंबना यह है कि गैर-अवरुद्ध आईओ हमेशा कम विलंबता नहीं है लेकिन आमतौर पर अधिक संसाधन होता है कुशल।

जैसा कि आप वितरित प्रोग्रामिंग और समवर्ती प्रोग्रामिंग का विषय देख सकते हैं, बल्कि यह बड़ा है और हर रोज बदल रहा है, इसलिए मेरा मूल इरादा भ्रमित नहीं था बल्कि वितरित संदेश प्रसंस्करण के एक विशेष क्षेत्र पर ध्यान केंद्रित किया गया था, जो कि ओपी के साथ चिंतित था । संगामिति के संदर्भ में एक पर "प्रतिक्रियाशील" प्रोग्रामिंग (आरएफपी/धाराओं) अपनी खोजों ध्यान केंद्रित करने की है जो एक "नए" लेकिन इसी तरह अभिनेता मॉडल और संदेश कतार मॉडल जिनमें से इन मॉडलों के सभी आम तौर पर जोड़ा जा सकता है के लिए मॉडल है चाहते हो सकता है क्योंकि वे घटना आधारित हैं।

Answer 3

ज़ीरोएमक्यू की तुलना में अक्का-कैमल एक बेहतर उदाहरण होगा - ज़ीरोएमक्यू टीसीपी संचार के लिए सीधा टीसीपी है (इसलिए शून्य - कोई संदेश कतार नहीं है)।

अक्काकामेल के साथ आप कतार को दूर कर सकते हैं और संदेश कतार संदेश पुशिंग/खींचने से निपटने के लिए किसी भी कोड के बिना किसी अभिनेता से सीधे संदेश का उत्पादन/उपभोग कर सकते हैं।

आप अक्का-जेरोमक से आगे निकल सकते हैं और सीधे रीकाटिंग के साथ अक्का का उपयोग कर सकते हैं। मुझे लगता है कि अक्का-zeromq कोर पुस्तकालय से हटाया जा रहा है, लेकिन हम एक अच्छा zeromq पुस्तकालय बनाया अक्का बुलाया स्केला-zeromq के लिए (https://github.com/mDialog/scala-zeromq)

अक्का में कुछ मुख्य कोर उपयोग के मामलों है:

1) परिवर्त्य राज्य

यह एक अभिनेता में यह छुपा कर साझा राज्य को संभालने के लिए आसान है। अभिनेताओं तुल्यकालिक संदेशों को संभालने के रूप में, आप एक अभिनेता में राज्य पकड़ और अभिनेता एपीआई

2) वितरण के माध्यम से उच्च स्थिरता के साथ उस क्षेत्र का पर्दाफाश कर सकते हैं

कन्करेंसी अक्का में नि: शुल्क तो आप कहते हैं कि यह वास्तव में वितरण की समस्याओं को सुलझाने के बारे में है। मशीनों और कोरों में वितरण। तार पर संदेश भेजने के लिए अक्का ने "स्थान पारदर्शिता" में निर्माण किया है। इसमें क्लस्टरिंग और पैटर भी एक ही सेवा को स्केल करने के लिए जुड़े हुए हैं। यह वितरण के लिए एक बहुत अच्छा समाधान (जैसे सूक्ष्म सेवा वास्तुकला) बनाता है

यहाँ अक्का-ऊंट के साथ ActiveMQ (Java8 का उपयोग कर)

import akka.actor.Props; 
import akka.camel.Camel; 
import akka.camel.CamelExtension; 
import akka.testkit.TestActorRef; 
import akka.testkit.TestProbe; 
import org.junit.Ignore; 
import org.junit.Test; 
import akka.camel.javaapi.UntypedProducerActor; 
import akka.camel.javaapi.UntypedConsumerActor; 
import static com.rogers.totes.TotesTestFixtures.*; 
import org.apache.activemq.camel.component.*; 

public class MessagingTest { 
    @Test @Ignore 
    public void itShouldStoreAMessage() throws Exception{ 
     String amqUrl = "nio://localhost:61616"; 
     Camel camel = (Camel) CamelExtension.apply(system); 
     camel.context().addComponent("activemq", ActiveMQComponent.activeMQComponent(amqUrl)); 

     TestProbe probe = TestProbe.apply(system); 
     TestActorRef producer = TestActorRef.create(system, Props.create((Producer.class))); 
     TestActorRef consumer = TestActorRef.create(system, Props.create((Consumer.class))); 
     producer.tell("Produce", probe.ref()); 

     Thread.sleep(1000); 
    } 
} 

class Producer extends UntypedProducerActor{ 

    @Override 
    public String getEndpointUri() { 
     return "activemq:foo.bar"; 
    } 
} 

class Consumer extends UntypedConsumerActor{ 

    @Override 
    public String getEndpointUri() { 
     return "activemq:foo.bar"; 
    } 

    @Override 
    public void onReceive(Object message) throws Exception { 
     System.out.println("GOT A MESSAGE!" + message); 

    } 
}