java - नेटटी बनाम अपाचे मिनिया




network-programming apache-mina (5)

वे दोनों मोटे तौर पर एक ही कार्यक्षमता प्रदान करते हैं। मुझे अपने उच्च प्रदर्शन वाले टीसीपी सर्वर को विकसित करने के लिए कौन सा चयन करना चाहिए? पेशेवरों और विपक्ष क्या हैं?

संदर्भ लिंक:

अपाचे मिनिया ( source )

Netty ( source )


जटिलता और अपेक्षाकृत खराब प्रदर्शन की लागत पर MINA के पास ऑफ़-द-बॉक्स सुविधाएं हैं। उनमें से कुछ सुविधाओं को कोर में एकीकृत किया गया था ताकि उन्हें हटाया जा सके, भले ही उन्हें किसी उपयोगकर्ता द्वारा आवश्यकता न हो। नेटटी में, मैंने मिनी के ज्ञात ताकत को बनाए रखते हुए इस तरह के डिजाइन मुद्दों को हल करने की कोशिश की।

वर्तमान में, MINA में उपलब्ध अधिकांश सुविधाएं नेटटी में भी उपलब्ध हैं। मेरी राय में, नेटटी के पास क्लीनर और अधिक दस्तावेज एपीआई है क्योंकि नेटटी खनन से MINA को पुनर्निर्माण करने और ज्ञात समस्याओं को हल करने का प्रयास करने का परिणाम है। यदि आपको लगता है कि एक आवश्यक सुविधा गुम है, तो कृपया फोरम में अपना सुझाव पोस्ट करने के लिए स्वतंत्र महसूस करें। मुझे आपकी चिंता का समाधान करने में खुशी होगी।

यह भी ध्यान रखना महत्वपूर्ण है कि नेटी के पास तेजी से विकास चक्र है। बस, हालिया रिलीज की रिलीज की तारीख देखें। साथ ही, आपको यह समझना चाहिए कि MINA टीम एक प्रमुख पुनर्लेखन, MINA 3 पर आगे बढ़ेगी, जिसका अर्थ है कि वे एपीआई संगतता को पूरी तरह से तोड़ देंगे।


जबकि MINA और नेटी की समान महत्वाकांक्षाएं हैं, वे अभ्यास में काफी अलग हैं और आपको अपनी पसंद पर ध्यान से विचार करना चाहिए। हम भाग्यशाली थे कि हमारे पास MINA के साथ बहुत अनुभव था और नेटटी के साथ खेलने का समय था। हमें विशेष रूप से क्लीनर एपीआई और बहुत बेहतर दस्तावेज पसंद आया। प्रदर्शन कागज पर भी बेहतर लग रहा था। सबसे महत्वपूर्ण बात यह है कि हम जानते थे कि हमारे पास किसी भी प्रश्न का उत्तर देने के लिए ट्रस्टिन ली हाथ में होगा, और उसने निश्चित रूप से ऐसा किया।

हमने नेटटी में सबकुछ आसान पाया। अवधि। जबकि हम उसी कार्यक्षमता को फिर से लागू करने की कोशिश कर रहे थे जो हमारे पास पहले से ही MINA पर था, हमने स्क्रैच से ऐसा किया था। उत्कृष्ट दस्तावेज़ीकरण और उदाहरणों का पालन करके हम बहुत अधिक कार्यक्षमता के साथ समाप्त हुए, बहुत कम कोड।

नेटटी पाइपलाइन ने हमारे लिए बेहतर काम किया। यह MINA की तुलना में किसी भी तरह से सरल है, जहां सब कुछ एक हैंडलर है और यह तय करने के लिए आप पर निर्भर है कि अपस्ट्रीम घटनाओं, डाउनस्ट्रीम घटनाओं को संभालना है या दोनों कम स्तर की सामग्री का उपभोग करना है या नहीं। "रीप्लेइंग" डिकोडर्स में गोबलिंग बाइट्स लगभग एक खुशी थीं। पाइपलाइन ऑन-द-फ्लाई को आसानी से पुन: कॉन्फ़िगर करने में सक्षम होना भी बहुत अच्छा था।

लेकिन नेटटी, इम्हो का सितारा आकर्षण, "एक के कवरेज" के साथ पाइपलाइन हैंडलर बनाने की क्षमता है। आपने दस्तावेज़ में पहले से ही इस कवरेज एनोटेशन के बारे में पढ़ा है, लेकिन अनिवार्य रूप से यह आपको कोड की एक पंक्ति में राज्य देता है। बिना किसी गड़बड़ी के, कोई सत्र मानचित्र, सिंक्रनाइज़ेशन और उस तरह की चीजें नहीं, हम नियमित रूप से नियमित चर (कहने, "उपयोगकर्ता नाम") घोषित करने में सक्षम थे और उनका उपयोग करते थे।

लेकिन फिर हमने एक रोडब्लॉक मारा। हमारे पास पहले से ही MINA के तहत एक बहु-प्रोटोकॉल सर्वर था, जिसमें हमारा एप्लिकेशन प्रोटोकॉल टीसीपी / आईपी, HTTP और यूडीपी पर चला। जब हमने नेटी पर स्विच किया तो हमने कुछ मिनटों में सूची में एसएसएल और एचटीटीपीएस जोड़े! अब तक इतना अच्छा है, लेकिन जब यह यूडीपी में आया तो हमें एहसास हुआ कि हम फिसल गए हैं। मिनिया हमारे लिए बहुत अच्छा था कि हम यूडीपी को "जुड़े" प्रोटोकॉल के रूप में देख सकते थे। नेटटी के तहत ऐसा कोई अमूर्त नहीं है। यूडीपी कनेक्शन रहित है और नेटटी इस तरह से व्यवहार करता है। नेटटी की तुलना में नेटटी कम स्तर पर यूडीपी की अधिक कनेक्शन रहित प्रकृति का खुलासा करता है। ऐसी चीजें हैं जो आप नेटी के तहत यूडीपी के साथ कर सकते हैं, आप मिनीए द्वारा प्रदान किए जाने वाले उच्च स्तरीय अमूर्तता के तहत नहीं कर सकते हैं, लेकिन जिस पर हमने भरोसा किया था।

"कनेक्टेड यूडीपी" रैपर या कुछ जोड़ने के लिए इतना आसान नहीं है। समय की बाधाओं और ट्रस्टिन की सलाह पर देखते हुए कि आगे बढ़ने का सबसे अच्छा तरीका नेटी में अपने स्वयं के परिवहन प्रदाता को लागू करना था, जो जल्दी नहीं होगा, हमें अंत में नेटी को त्यागना पड़ा।

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


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


मैं नेटटी पसंद करते हैं।

ट्विटर ने अपनी नई खोज प्रणाली बनाने के लिए नेटी को भी चुना और इसे 3x तेज तक बढ़ा दिया।

रेफरी: ट्विटर खोज अब 3x तेज है

हमने नीना को अपने कुछ अन्य प्रतिस्पर्धियों जैसे मीना और जेट्टी पर चुना है, क्योंकि इसमें क्लीनर एपीआई, बेहतर दस्तावेज और अधिक महत्वपूर्ण बात है, क्योंकि ट्विटर पर कई अन्य परियोजनाएं इस ढांचे का उपयोग कर रही हैं।


मैंने सर्वर का एक छोटा http बनाने के लिए कभी भी MINA का उपयोग किया है। अब तक की सबसे बड़ी समस्याएं हैं:

  1. यह स्मृति में आपका "अनुरोध" और "प्रतिक्रिया" रखेगा। यह केवल एक मुद्दा है क्योंकि मैं जिस प्रोटोकॉल का उपयोग करना चुनता हूं वह http है। हालांकि आप अपने आसपास के प्रोटोकॉल का उपयोग कर सकते हैं।
  2. यदि आप बड़ी फ़ाइलों को सेवा देना चाहते हैं तो डिस्क से स्ट्रीम को स्ट्रीम करने का कोई विकल्प नहीं है। फिर से अपने प्रोटोकॉल को लागू करके काम किया जा सकता है

इसके बारे में अच्छी चीजें:

  1. बहुत सारे कनेक्शन संभाल सकते हैं
  2. यदि आप कुछ प्रकार के वितरित कार्य प्रणाली को लागू करना चुनते हैं तो यह जानना कि आपके नोड्स में से एक कब नीचे जाता है और कनेक्शन खो देता है, किसी अन्य नोड पर काम को पुनरारंभ करने के लिए उपयोगी होता है।




netty