বার্তা দালাল বোঝা। ActiveMQ এবং Kafka এর সাথে মেসেজিং এর মেকানিক্স শেখা। অধ্যায় 1

হ্যালো সবাই!

একটি ছোট বই অনুবাদ শুরু:
«বার্তা দালাল বোঝা",
লেখক: Jakub Korab, প্রকাশক: O'Reilly Media, Inc., প্রকাশের তারিখ: জুন 2017, ISBN: 9781492049296।

বইয়ের ভূমিকা থেকে:
"... এই বইটি আপনাকে শেখাবে কিভাবে ব্রোকারড মেসেজিং সিস্টেম সম্পর্কে চিন্তা করতে হয় দুটি জনপ্রিয় ব্রোকিং প্রযুক্তির তুলনা এবং বৈসাদৃশ্য করে: Apache ActiveMQ এবং Apache Kafka। এটি ব্যবহারের ক্ষেত্রে এবং বিকাশের প্রণোদনাগুলির রূপরেখা দেবে যা তাদের বিকাশকারীদের সিস্টেমের মধ্যে ব্রোকারড মেসেজিংয়ের একই ক্ষেত্রে ব্যাপকভাবে ভিন্ন পদ্ধতি গ্রহণ করতে পরিচালিত করেছে। আমরা গ্রাউন্ড আপ থেকে এই প্রযুক্তিগুলির দিকে নজর দেব এবং পথ ধরে বিভিন্ন ডিজাইন পছন্দগুলির প্রভাবকে হাইলাইট করব৷ আপনি উভয় পণ্য সম্পর্কে গভীর উপলব্ধি অর্জন করতে পারবেন, কীভাবে সেগুলি ব্যবহার করা উচিত এবং কী করা উচিত নয় সে সম্পর্কে একটি বোঝা এবং ভবিষ্যতে অন্যান্য মেসেজিং প্রযুক্তিগুলি বিবেচনা করার সময় কীসের দিকে নজর দেওয়া উচিত তা বোঝার। ... "

এ পর্যন্ত অনুবাদকৃত অংশ:
অধ্যায় 1 ভূমিকা
অধ্যায় 3. কাফকা

আমি সম্পূর্ণ অধ্যায় পোস্ট করব যেহেতু সেগুলি অনুবাদ করা হয়েছে।

অধ্যায় 1

ভূমিকা

ইন্টারসিস্টেম মেসেজিং হল আইটির সবচেয়ে কম বোঝার ক্ষেত্রগুলির মধ্যে একটি। একজন বিকাশকারী বা স্থপতি হিসাবে, আপনি বিভিন্ন ফ্রেমওয়ার্ক এবং ডাটাবেসের সাথে খুব পরিচিত হতে পারেন। যাইহোক, সম্ভবত আপনি ব্রোকার-ভিত্তিক মেসেজিং প্রযুক্তি কীভাবে কাজ করে তার একটি আভাস পাবেন। আপনি যদি এমনই অনুভব করেন, চিন্তা করবেন না, আপনি ভাল কোম্পানিতে আছেন।

মেসেজিং পরিকাঠামোর সাথে মানুষের সাধারণত খুব সীমিত যোগাযোগ থাকে। প্রায়শই তারা একটি দীর্ঘ সময় আগে তৈরি একটি সিস্টেমের সাথে সংযোগ স্থাপন করে, বা ইন্টারনেট থেকে একটি বিতরণ কিট ডাউনলোড করে, এটি PROM এ ইনস্টল করে এবং এটির জন্য কোড লেখা শুরু করে। একবার পরিকাঠামো তৈরি হয়ে গেলে এবং PROM-এ চলমান হলে, ফলাফলগুলি মিশ্রিত হতে পারে: ক্র্যাশে বার্তাগুলি হারিয়ে যায়, প্রেরণগুলি আপনার প্রত্যাশা অনুযায়ী কাজ করে না, বা দালালরা আপনার প্রযোজকদের আটকে রাখে বা আপনার গ্রাহকদের বার্তা পাঠায় না।

পরিচিত শব্দ?

একটি সাধারণ দৃশ্য যেখানে আপনার মেসেজিং কোড আপাতত ভাল কাজ করে। যতক্ষণ না এটি কাজ করা বন্ধ করে দেয়। এই সময়টি সতর্কতা হ্রাস করে এবং নিরাপত্তার একটি মিথ্যা ধারণা দেয়, যা প্রযুক্তির মৌলিক আচরণ সম্পর্কে মিথ্যা ধারণার উপর ভিত্তি করে আরও বেশি কোডের দিকে পরিচালিত করে। যখন জিনিসগুলি ভুল হতে শুরু করে, তখন আপনি একটি অস্বস্তিকর সত্যের মুখোমুখি হন: আপনি সত্যিই পণ্যটির অন্তর্নিহিত আচরণ, বা লেখকদের দ্বারা নির্বাচিত ট্রেড-অফগুলি বুঝতে পারেননি, যেমন কর্মক্ষমতা বনাম দৃঢ়তা, বা লেনদেন বনাম অনুভূমিক মাপযোগ্যতা।

দালালরা কীভাবে কাজ করে সে সম্পর্কে গভীর ধারণা ছাড়াই, লোকেরা তাদের মেসেজিং সিস্টেম সম্পর্কে আপাতদৃষ্টিতে যুক্তিসঙ্গত দাবি করে, যেমন:

• সিস্টেম বার্তা হারাবে না
• বার্তা ক্রমানুসারে প্রক্রিয়া করা হবে
• ভোক্তা যোগ করলে সিস্টেম দ্রুততর হবে
• বার্তা শুধুমাত্র একবার বিতরণ করা হবে

দুর্ভাগ্যবশত, এই বিবৃতিগুলির মধ্যে কিছু অনুমানের উপর ভিত্তি করে যা শুধুমাত্র নির্দিষ্ট পরিস্থিতিতে প্রযোজ্য, অন্যগুলি কেবল সত্য নয়।

এই বইটি আপনাকে শেখাবে কিভাবে ব্রোকারড মেসেজিং সিস্টেম সম্পর্কে দুটি জনপ্রিয় ব্রোকার টেকনোলজির তুলনা ও বৈসাদৃশ্য করে যুক্তি করতে হয়: Apache ActiveMQ এবং Apache Kafka। এটি ব্যবহারের ক্ষেত্রে এবং বিকাশের প্রণোদনাগুলির রূপরেখা দেবে যা তাদের বিকাশকারীদের সিস্টেমের মধ্যে ব্রোকারড মেসেজিংয়ের একই ক্ষেত্রে ব্যাপকভাবে ভিন্ন পদ্ধতি গ্রহণ করতে পরিচালিত করেছে। আমরা গ্রাউন্ড আপ থেকে এই প্রযুক্তিগুলির দিকে নজর দেব এবং পথ ধরে বিভিন্ন ডিজাইন পছন্দগুলির প্রভাবকে হাইলাইট করব৷ আপনি উভয় পণ্য সম্পর্কে গভীর উপলব্ধি অর্জন করতে পারবেন, কীভাবে সেগুলি ব্যবহার করা উচিত এবং কী করা উচিত নয় সে সম্পর্কে একটি বোঝা এবং ভবিষ্যতে অন্যান্য মেসেজিং প্রযুক্তিগুলি বিবেচনা করার সময় কীসের দিকে নজর দেওয়া উচিত তা বোঝার।

আমরা শুরু করার আগে, এর মূল বিষয়গুলি নিয়ে যাওয়া যাক।

একটি মেসেজিং সিস্টেম কি এবং কেন এটি প্রয়োজন

দুটি অ্যাপ্লিকেশন একে অপরের সাথে যোগাযোগ করার জন্য, তাদের প্রথমে একটি ইন্টারফেস সংজ্ঞায়িত করতে হবে। এই ইন্টারফেসের সংজ্ঞার মধ্যে একটি পরিবহন বা প্রোটোকল যেমন HTTP, MQTT, বা SMTP, এবং সিস্টেমগুলি বিনিময় করা বার্তা বিন্যাসের আলোচনা অন্তর্ভুক্ত করে। এটি একটি কঠোর প্রক্রিয়া হতে পারে, যেমন একটি বার্তার জন্য পেলোড খরচের প্রয়োজনীয়তা সহ একটি XML স্কিমা সংজ্ঞায়িত করা, অথবা এটি অনেক কম আনুষ্ঠানিক হতে পারে, যেমন দুটি বিকাশকারীদের মধ্যে একটি চুক্তি যে একটি HTTP অনুরোধের কিছু অংশে একটি ক্লায়েন্ট শনাক্তকারী থাকবে।

যতক্ষণ পর্যন্ত বার্তাগুলির বিন্যাস এবং সেগুলি যে ক্রমানুসারে পাঠানো হয় তা সিস্টেমগুলির মধ্যে সামঞ্জস্যপূর্ণ থাকে, তারা অন্য সিস্টেমের বাস্তবায়নের বিষয়ে চিন্তা না করে একে অপরের সাথে যোগাযোগ করতে সক্ষম হবে। এই সিস্টেমের অভ্যন্তরীণ, যেমন প্রোগ্রামিং ভাষা বা ফ্রেমওয়ার্ক ব্যবহৃত হয়, সময়ের সাথে সাথে পরিবর্তিত হতে পারে। যতক্ষণ চুক্তি নিজেই বজায় থাকে, ততক্ষণ অন্য দিকে মিথস্ক্রিয়া অপরিবর্তিত চলতে পারে। এই ইন্টারফেস দ্বারা দুটি সিস্টেম কার্যকরভাবে ডিকপল (বিচ্ছিন্ন) হয়।

মেসেজিং সিস্টেম সাধারণত দুটি সিস্টেমের মধ্যে একটি মধ্যস্থতাকারীকে জড়িত করে যা প্রাপক বা প্রাপকদের থেকে প্রেরককে আরও ডিকপল (আলাদা) করতে ইন্টারঅ্যাক্ট করে। এই ক্ষেত্রে, মেসেজিং সিস্টেম প্রেরককে বার্তা পাঠাতে দেয় প্রাপক কোথায় অবস্থিত, সে সক্রিয় কিনা বা তাদের কতগুলি উদাহরণ।

একটি মেসেজিং সিস্টেম যে ধরনের সমস্যার সমাধান করে তার জন্য কিছু সাদৃশ্য দেখি এবং কিছু মৌলিক পদ প্রবর্তন করি।

বিন্দু বিন্দু

আলেকজান্দ্রা অ্যাডামকে একটি প্যাকেজ পাঠাতে পোস্ট অফিসে যায়। সে জানালার কাছে যায় এবং পার্সেলটি কর্মচারীর হাতে দেয়। কর্মচারী প্যাকেজটি তুলে নেয় এবং আলেকজান্দ্রাকে একটি রসিদ দেয়। প্যাকেজ পাঠানোর সময় অ্যাডামকে বাড়িতে থাকতে হবে না। আলেকজান্দ্রা আত্মবিশ্বাসী যে প্যাকেজটি ভবিষ্যতে কোনো এক সময়ে অ্যাডামের কাছে পৌঁছে দেওয়া হবে এবং তার ব্যবসা চালিয়ে যেতে পারবে। পরে, এক পর্যায়ে, অ্যাডাম একটি প্যাকেজ পায়।

এটি একটি মেসেজিং মডেলের উদাহরণ বিন্দু বিন্দু. এখানে পোস্ট অফিস একটি প্যাকেজ বিতরণ প্রক্রিয়া হিসাবে কাজ করে, প্রতিটি প্যাকেজ একবার বিতরণ করা হয় তা নিশ্চিত করে। পোস্ট অফিসের ব্যবহার পার্সেল পাঠানোর কাজকে পার্সেলের ডেলিভারি থেকে আলাদা করে।
ক্লাসিক মেসেজিং সিস্টেমে, পয়েন্ট-টু-পয়েন্ট মডেলের মাধ্যমে প্রয়োগ করা হয় বেণী. সারিটি FIFO (প্রথম ইন, ফার্স্ট আউট) বাফার হিসাবে কাজ করে যা এক বা একাধিক গ্রাহক সদস্যতা নিতে পারেন। প্রতিটি বার্তা শুধুমাত্র বিতরণ করা হয় সাবস্ক্রাইব করা ভোক্তাদের একজন. সারি সাধারণত গ্রাহকদের মধ্যে বার্তা বিতরণ করার চেষ্টা করে। শুধুমাত্র একজন ভোক্তা এই বার্তাটি পাবেন।

"টেকসই" শব্দটি সারিগুলিতে প্রয়োগ করা হয়। বিশ্বাসযোগ্যতা একটি পরিষেবা সম্পত্তি যা গ্যারান্টি দেয় যে মেসেজিং সিস্টেম সক্রিয় গ্রাহকদের অনুপস্থিতিতে বার্তাগুলি রাখবে যতক্ষণ না ভোক্তা বার্তা বিতরণ সারিতে সাবস্ক্রাইব করে।

নির্ভরযোগ্যতা প্রায়ই বিভ্রান্ত হয় অধ্যবসায় এবং, যদিও দুটি পদ বিনিময়যোগ্য, তারা বিভিন্ন কার্য সম্পাদন করে। অধ্যবসায় নির্ধারণ করে যে একটি বার্তা মেসেজিং সিস্টেম দ্বারা এটি গ্রহণ করা এবং ভোক্তার কাছে পাঠানোর মধ্যে কোন ধরনের স্টোরেজ লেখা হয়েছে কিনা। সারিতে পাঠানো বার্তাগুলি স্থায়ী হতে পারে বা নাও থাকতে পারে।
পয়েন্ট-টু-পয়েন্ট মেসেজিং ব্যবহার করা হয় যখন একটি ব্যবহারের ক্ষেত্রে একটি বার্তার উপর একক পদক্ষেপের প্রয়োজন হয়। উদাহরণগুলির মধ্যে একটি অ্যাকাউন্টে তহবিল জমা করা বা ডেলিভারি অর্ডার পূরণ করা অন্তর্ভুক্ত। আমরা পরে আলোচনা করব কেন একটি মেসেজিং সিস্টেম নিজেই এককালীন ডেলিভারি প্রদান করতে অক্ষম এবং কেন সারি সর্বোত্তমভাবে একটি ডেলিভারি গ্যারান্টি দিতে পারে। অন্তত একবার.

প্রকাশক-সাবস্ক্রাইবার

গ্যাব্রিয়েলা কনফারেন্স নম্বর ডায়াল করে। তিনি কনফারেন্সের সাথে সংযুক্ত থাকাকালীন, তিনি কলের বাকি অংশগ্রহণকারীদের সাথে স্পিকার যা বলেন তা সবই শোনেন। যখন সে ব্ল্যাক আউট করে, তখন সে যা বলে তা মিস করে। পুনরায় সংযোগ করার সময়, তিনি কী বলা হচ্ছে তা শুনতে থাকেন।

এটি একটি মেসেজিং মডেলের উদাহরণ সাবস্ক্রাইব প্রকাশ. কনফারেন্স কল একটি সম্প্রচার প্রক্রিয়া হিসাবে কাজ করে। যে ব্যক্তি কথা বলছে সে বিবেচনা করে না যে বর্তমানে কতজন লোক কলে আছে - সিস্টেমটি নিশ্চিত করে যে বর্তমানে সংযুক্ত যে কেউ কি বলা হচ্ছে তা শুনতে পাবে।
ক্লাসিক মেসেজিং সিস্টেমে, প্রকাশ-সাবস্ক্রাইব মেসেজিং মডেলের মাধ্যমে প্রয়োগ করা হয় টপস. একটি বিষয় কনফারেন্সিং প্রক্রিয়া হিসাবে একই সম্প্রচার পদ্ধতি প্রদান করে। যখন একটি বার্তা একটি বিষয় পোস্ট করা হয়, এটি বিতরণ করা হয় সমস্ত সদস্যতা নেওয়া ব্যবহারকারীদের জন্য.

বিষয় সাধারণত অবিশ্বস্ত (অনির্ভরযোগ্য). একজন শ্রোতার মতো যিনি কনফারেন্স কলে যা বলা হচ্ছে তা শুনতে পারেন না, যখন শ্রোতা অফলাইনে চলে যায়, তখন বিষয় গ্রাহকরা অফলাইনে থাকাকালীন প্রেরিত কোনো বার্তা মিস করে। এই কারণে, আমরা বলতে পারি যে শীর্ষগুলি ডেলিভারির গ্যারান্টি প্রদান করে। একবারের বেশি নয় প্রতিটি ভোক্তার জন্য।

পাবলিশ-সাবস্ক্রাইব মেসেজিং সাধারণত ব্যবহার করা হয় যখন বার্তাগুলি তথ্যপূর্ণ প্রকৃতির হয় এবং একটি একক বার্তার ক্ষতি বিশেষভাবে উল্লেখযোগ্য নয়। উদাহরণস্বরূপ, একটি বিষয় প্রতি সেকেন্ডে একবার সেন্সরগুলির একটি গ্রুপ থেকে তাপমাত্রা রিডিং প্রেরণ করতে পারে। একটি সিস্টেম যা বর্তমান তাপমাত্রায় আগ্রহী এবং যেটি একটি বিষয়ের সদস্যতা নেয় যদি এটি একটি বার্তা মিস করে তবে চিন্তা করবে না - অন্যটি শীঘ্রই আসবে৷

হাইব্রিড মডেল

দোকান ওয়েবসাইট একটি "বার্তা সারিতে" অর্ডার বার্তা রাখে. এই বার্তাগুলির প্রধান ভোক্তা হল নির্বাহী ব্যবস্থা। উপরন্তু, অডিটিং সিস্টেমে পরবর্তী ট্র্যাকিংয়ের জন্য এই আদেশ বার্তাগুলির অনুলিপি থাকতে হবে। উভয় সিস্টেমই বার্তাগুলি মিস করতে পারে না, এমনকি যদি সিস্টেমগুলি নিজেই কিছু সময়ের জন্য অনুপলব্ধ থাকে। ওয়েবসাইটটি অন্য সিস্টেম সম্পর্কে সচেতন হওয়া উচিত নয়।

ব্যবহারের ক্ষেত্রে প্রায়ই প্রকাশ-সাবস্ক্রাইব এবং পয়েন্ট-টু-পয়েন্ট মেসেজিং মডেলের মিশ্রণের প্রয়োজন হয়, যেমন যখন একাধিক সিস্টেমের একটি বার্তার অনুলিপি প্রয়োজন এবং বার্তার ক্ষতি রোধ করার জন্য নির্ভরযোগ্যতা এবং অধ্যবসায় উভয়ই প্রয়োজন।

এই ক্ষেত্রে, একটি গন্তব্য (সারি এবং বিষয়গুলির জন্য সাধারণ শব্দ) প্রয়োজন, যা মূলত একটি বিষয়ের মতো বার্তাগুলি বিতরণ করে, যাতে প্রতিটি বার্তা এই বার্তাগুলিতে আগ্রহী একটি পৃথক সিস্টেমে প্রেরণ করা হয়, তবে এতে প্রতিটি সিস্টেম বেশ কয়েকটি গ্রাহককে সংজ্ঞায়িত করতে পারে। যে ইনকামিং বার্তাগুলি গ্রহণ করে, যা একটি সারির মতো। এই ক্ষেত্রে পড়ার ধরন হল − প্রতিটি স্টেকহোল্ডারের জন্য একবার. এই হাইব্রিড গন্তব্যগুলির প্রায়শই স্থায়িত্বের প্রয়োজন হয় যাতে কোনও ভোক্তা সংযোগ বিচ্ছিন্ন করলে, সেই সময়ে পাঠানো বার্তাগুলি গ্রহণ করা হয় যখন ভোক্তা পুনরায় সংযোগ করে।

হাইব্রিড মডেলগুলি নতুন নয় এবং বেশিরভাগ মেসেজিং সিস্টেমে প্রয়োগ করা যেতে পারে, যার মধ্যে ActiveMQ (ভার্চুয়াল বা যৌগিক গন্তব্যগুলির মাধ্যমে যা বিষয় এবং সারিগুলিকে একত্রিত করে) এবং কাফকা (উপলব্ধভাবে, এর গন্তব্য নকশার একটি মৌলিক সম্পত্তি হিসাবে) উভয়ই সহ।

এখন যেহেতু আমাদের কাছে কিছু মৌলিক পরিভাষা এবং একটি বার্তাপ্রেরণ সিস্টেম কীসের জন্য উপযোগী হতে পারে সে সম্পর্কে একটি বোঝাপড়া আছে, আসুন বিস্তারিত জেনে নেওয়া যাক।

অনুবাদ সম্পন্ন: tele.gg/middle_java

পরবর্তী অনূদিত অংশ: অধ্যায় 3. কাফকা

চলবে…

উত্স: www.habr.com