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

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

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

অধ্যায় 3

কাফকা

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

এই চূড়ান্ত লক্ষ্যের প্রেক্ষিতে, স্বাভাবিকভাবেই অন্যান্য প্রয়োজনীয়তা দেখা দেয়। কাফকার উচিত:

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

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

ইউনিফাইড ডেস্টিনেশন মডেল

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

এই অধ্যায়ের বাকি অংশের জন্য, যদি না আমরা স্পষ্টভাবে অন্যথায় উল্লেখ করি, "বিষয়" শব্দটি একটি কাফকা বিষয়কে নির্দেশ করবে।

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

"লগ" এবং "পয়েন্টার" শব্দগুলি উপস্থিত হয় না৷ কাফকা ডকুমেন্টেশন. এই সুপরিচিত পদগুলি বোঝার জন্য এখানে ব্যবহার করা হয়েছে৷

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

চিত্র 3-1। কাফকা পার্টিশন

যখন একজন প্রযোজক একটি কাফকা বিষয়ে একটি বার্তা পাঠান, তখন এটি সিদ্ধান্ত নেয় কোন পার্টিশনে বার্তা পাঠাবে। আমরা পরে আরো বিস্তারিতভাবে এটি দেখব.

বার্তা পড়া

যে ক্লায়েন্ট বার্তাগুলি পড়তে চায় সে নামক পয়েন্টার পরিচালনা করে ভোক্তা গ্রুপ, যা নির্দেশ করে অফসেট পার্টিশনে বার্তা। অফসেট হল একটি ক্রমবর্ধমান অবস্থান যা পার্টিশনের শুরুতে 0 থেকে শুরু হয়। এই ভোক্তা গোষ্ঠী, ব্যবহারকারী-সংজ্ঞায়িত group_id এর মাধ্যমে API-তে উল্লেখ করা হয়েছে, এর সাথে মিলে যায় একটি যৌক্তিক ভোক্তা বা সিস্টেম.

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

পড়ার সমস্যাটি নিম্নরূপ উপস্থাপন করা যেতে পারে:

• বিষয় একাধিক পার্টিশন আছে
• ভোক্তাদের একাধিক গ্রুপ একই সময়ে একটি বিষয় ব্যবহার করতে পারেন
• ভোক্তাদের একটি গ্রুপের একাধিক পৃথক উদাহরণ থাকতে পারে

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

ভোক্তা এবং ভোক্তা গোষ্ঠী

একটি বিভাজন সহ একটি বিষয়কে প্রারম্ভিক বিন্দু হিসাবে ধরা যাক (চিত্র ২-৩).

চিত্র 3-2। ভোক্তা পার্টিশন থেকে পড়ে

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

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

চিত্র 3-3। বিভিন্ন ভোক্তা গোষ্ঠীর দুইজন ভোক্তা একই পার্টিশন থেকে পড়ে

একটি ভোক্তা গ্রুপের ভোক্তারা

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

চিত্র 3-4। একই ভোক্তা গোষ্ঠীর দুইজন ভোক্তা একই পার্টিশন থেকে পড়ে

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

উপরে বর্ণিত এই বার্তা বিতরণ আচরণ একটি সাধারণ JMS সারি কীভাবে আচরণ করে তার তুলনায় আশ্চর্যজনক হতে পারে। এই মডেলে, সারিতে পাঠানো বার্তা দুটি গ্রাহকের মধ্যে সমানভাবে বিতরণ করা হবে।

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

এটি করার একটি উপায় হল সমস্ত বার্তা পড়তে এবং থ্রেড পুলে পাঠানোর জন্য একটি একক ভোক্তার উদাহরণ ব্যবহার করা। যদিও এই পদ্ধতিটি প্রক্রিয়াকরণ থ্রুপুট বাড়ায়, এটি ভোক্তা যুক্তির জটিলতা বাড়ায় এবং পঠন ব্যবস্থার দৃঢ়তা বাড়ানোর জন্য কিছুই করে না। যদি বিদ্যুতের ব্যর্থতা বা অনুরূপ ঘটনার কারণে গ্রাহকের একটি অনুলিপি কমে যায়, তাহলে বিয়োগ বন্ধ হয়ে যায়।

কাফকার এই সমস্যাটি সমাধানের প্রামাণিক উপায় হল খ ব্যবহার করাОআরো পার্টিশন।

বিভাজন

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

চিত্র 3-5। একজন ভোক্তা একাধিক পার্টিশন থেকে পড়ে

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

20টি থ্রেডে সমান্তরালভাবে বার্তাগুলি প্রক্রিয়া করা হয়েছে তা নিশ্চিত করতে, আপনার কমপক্ষে 20টি পার্টিশন প্রয়োজন। যদি কম পার্টিশন থাকে, তাহলে আপনি এমন ভোক্তাদের সাথে থাকবেন যাদের কাজ করার মতো কিছুই নেই, যেমনটি একচেটিয়া ভোক্তাদের আলোচনায় আগে বর্ণিত হয়েছে।

চিত্র 3-6। একই ভোক্তা গ্রুপের দুইজন ভোক্তা বিভিন্ন পার্টিশন থেকে পড়ে

JMS সারি বজায় রাখার জন্য প্রয়োজনীয় বার্তা বিতরণের তুলনায় এই স্কিমটি কাফকা ব্রোকারের জটিলতাকে অনেকাংশে কমিয়ে দেয়। এখানে আপনাকে নিম্নলিখিত পয়েন্টগুলি সম্পর্কে চিন্তা করার দরকার নেই:

• রাউন্ড-রবিন বরাদ্দ, প্রিফেচ বাফারের বর্তমান ক্ষমতা বা পূর্ববর্তী বার্তাগুলি (জেএমএস বার্তা গোষ্ঠীগুলির জন্য) এর উপর ভিত্তি করে কোন ভোক্তার পরবর্তী বার্তা গ্রহণ করা উচিত।
• কোন বার্তাগুলি কোন গ্রাহকদের কাছে পাঠানো হয় এবং ব্যর্থতার ক্ষেত্রে সেগুলি পুনরায় বিতরণ করা উচিত কিনা।

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

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

বার্তা পাঠানো হচ্ছে

কোন পার্টিশনে বার্তা পাঠাতে হবে তা ঠিক করার দায়িত্ব সেই বার্তার প্রযোজকের। এটি যে পদ্ধতির দ্বারা করা হয় তা বোঝার জন্য, প্রথমে আমরা আসলে কী পাঠাচ্ছি তা বিবেচনা করতে হবে।

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

অধ্যায় 2-এ, আমরা অনলাইন বেটিং পরিস্থিতি নিয়ে আলোচনা করেছি যেখানে সংশ্লিষ্ট ইভেন্টগুলি একক ভোক্তার দ্বারা প্রক্রিয়াকরণ করা প্রয়োজন:

1. ব্যবহারকারীর অ্যাকাউন্ট কনফিগার করা হয়.
2. অ্যাকাউন্টে টাকা জমা হয়।
3. একটি বাজি করা হয় যা অ্যাকাউন্ট থেকে টাকা তুলে নেয়।

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

এই ইন্টারফেস এই মত দেখায়:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

আপনার নিজস্ব বিভাজন কৌশল লেখা

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

যেহেতু স্বাক্ষরের মান পেলোডের উপর নির্ভর করে পরিবর্তিত হবে, পার্টিশনার ইন্টারফেসের ডিফল্ট হ্যাশিং কৌশল নির্ভরযোগ্যভাবে সম্পর্কিত বার্তাগুলিকে গ্রুপ করবে না। অতএব, আমাদের নিজস্ব কৌশল লিখতে হবে যা এই কী পার্স করবে এবং accountId মানকে বিভাজন করবে।

কাফকা স্টোরে বার্তাগুলির দুর্নীতি সনাক্ত করতে চেকসামগুলি অন্তর্ভুক্ত করে এবং এতে সুরক্ষা বৈশিষ্ট্যগুলির সম্পূর্ণ সেট রয়েছে। তা সত্ত্বেও, শিল্প-নির্দিষ্ট প্রয়োজনীয়তা, যেমন উপরের একটি, কখনও কখনও প্রদর্শিত হয়।

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

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

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

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

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

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

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

JMS ব্রোকারদেরও এই ধরনের প্রয়োজনীয়তা মোকাবেলা করতে হবে। মজার বিষয় হল, একই ভোক্তাদের কাছে সম্পর্কিত বার্তা পাঠানোর প্রক্রিয়া, JMS বার্তা গ্রুপের মাধ্যমে বাস্তবায়িত (স্টিকি লোড ব্যালেন্সিং (SLB) কৌশলের একটি ভিন্নতা), এছাড়াও প্রেরককে বার্তাগুলিকে সম্পর্কিত হিসাবে চিহ্নিত করতে হবে। JMS-এর ক্ষেত্রে, ব্রোকার অনেকের মধ্যে একজন ভোক্তার কাছে এই গ্রুপ সম্পর্কিত বার্তা পাঠানোর জন্য এবং ভোক্তা পড়ে গেলে গ্রুপের মালিকানা হস্তান্তর করার জন্য দায়ী।

প্রযোজক চুক্তি

বার্তা পাঠানোর সময় বিভাজন শুধুমাত্র বিবেচনা করার বিষয় নয়। চলুন জাভা API-তে প্রযোজক শ্রেণীর send() পদ্ধতিগুলি দেখে নেওয়া যাক:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

বার্তা পড়া সম্পর্কে আরো

বার্তা পড়ার অতিরিক্ত জটিলতা রয়েছে যা সম্পর্কে অনুমান করা দরকার। JMS API এর বিপরীতে, যা একটি বার্তার প্রতিক্রিয়ায় একটি বার্তা শ্রোতা চালাতে পারে, ভোক্তা কাফকা শুধুমাত্র ভোট। এর পদ্ধতিটি ঘনিষ্ঠভাবে দেখে নেওয়া যাক পোল()এই উদ্দেশ্যে ব্যবহৃত:

ConsumerRecords < K, V > poll(long timeout);

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

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

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

পূর্বে আলোচনা করা রিডিং মডেলে ফিরে, বার্তা প্রক্রিয়াকরণের তিনটি ধাপ রয়েছে:

1. পড়ার জন্য একটি বার্তা পুনরুদ্ধার করুন.
2. বার্তাটি প্রক্রিয়া করুন।
3. বার্তা নিশ্চিত করুন।

কাফকা গ্রাহক একটি কনফিগারেশন বিকল্পের সাথে আসে enable.auto.commit. এটি একটি ঘন ঘন ব্যবহৃত ডিফল্ট সেটিং, যেমনটি "স্বয়ংক্রিয়" শব্দ ধারণকারী সেটিংসের সাথে সাধারণ।

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

কাফকা 0.10-এ, ক্লায়েন্ট কোড পরিবর্তন করা হয়েছে যাতে কনফিগার করা ক্লায়েন্ট লাইব্রেরি দ্বারা প্রতিশ্রুতি পর্যায়ক্রমে ট্রিগার করা হয়। auto.commit.interval.ms. এই আচরণটি JMS AUTO_ACKNOWLEDGE এবং DUPS_OK_ACKNOWLEDGE মোডগুলির মধ্যে কোথাও রয়েছে৷ অটোকমিট ব্যবহার করার সময়, বার্তাগুলি আসলে প্রক্রিয়া করা হয়েছে কিনা তা নির্বিশেষে প্রতিশ্রুতিবদ্ধ হতে পারে - এটি একটি ধীর গ্রাহকের ক্ষেত্রে ঘটতে পারে। যদি একজন ভোক্তা স্থগিত করে, তাহলে পরবর্তী ভোক্তাদের দ্বারা বার্তাগুলি আনা হবে, প্রতিশ্রুতিবদ্ধ অবস্থান থেকে শুরু করে, যার ফলে একটি মিস বার্তা হতে পারে। এই ক্ষেত্রে, কাফকা বার্তাগুলি হারাননি, পড়ার কোডটি কেবল সেগুলি প্রক্রিয়া করেনি।

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

পৃষ্ঠা 21-এ "রিডিং মেসেজ ফ্রম এ কিউ"-এ আলোচনা করা হয়েছে, যখন ব্যর্থতার মোডগুলিকে বিবেচনায় নেওয়া হয় তখন মেসেজিং সিস্টেমে একটি বার্তা এককালীন ডেলিভারি করার মতো কিছু নেই৷

কাফকাতে, একটি অফসেট (অফসেট) কমিট (কমিট) করার দুটি উপায় রয়েছে: স্বয়ংক্রিয়ভাবে এবং ম্যানুয়ালি। উভয় ক্ষেত্রেই, বার্তাগুলি একাধিকবার প্রক্রিয়া করা যেতে পারে যদি বার্তাটি প্রক্রিয়া করা হয় তবে প্রতিশ্রুতির আগে ব্যর্থ হয়। আপনি বার্তাটি প্রক্রিয়া না করাও বেছে নিতে পারেন যদি প্রতিশ্রুতিটি ব্যাকগ্রাউন্ডে ঘটে থাকে এবং আপনার কোডটি প্রক্রিয়া করার আগে সম্পূর্ণ হয়ে যায় (সম্ভবত কাফকা 0.9 এবং তার আগে)।

আপনি প্যারামিটার সেট করে কাফকা ভোক্তা API-এ ম্যানুয়াল অফসেট কমিট প্রক্রিয়া নিয়ন্ত্রণ করতে পারেন enable.auto.commit নিম্নলিখিত পদ্ধতিগুলির মধ্যে একটিকে মিথ্যা এবং স্পষ্টভাবে কল করার জন্য:

void commitSync();
void commitAsync();

আপনি যদি "অন্তত একবার" বার্তাটি প্রক্রিয়া করতে চান তবে আপনাকে অবশ্যই এর সাথে ম্যানুয়ালি অফসেট করতে হবে৷ কমিট সিঙ্ক()বার্তাগুলি প্রক্রিয়াকরণের সাথে সাথে এই কমান্ডটি কার্যকর করার মাধ্যমে।

এই পদ্ধতিগুলি প্রক্রিয়া করার আগে বার্তাগুলিকে স্বীকার করার অনুমতি দেয় না, তবে তারা লেনদেনের চেহারা দেওয়ার সময় সম্ভাব্য প্রক্রিয়াকরণ বিলম্ব দূর করতে কিছুই করে না। কাফকার কোনো লেনদেন নেই। ক্লায়েন্টের নিম্নলিখিতগুলি করার ক্ষমতা নেই:

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

আমরা যদি লেনদেনের উপর নির্ভর করতে না পারি, তাহলে আমরা কীভাবে প্রথাগত মেসেজিং সিস্টেমের দ্বারা প্রদত্ত শব্দের কাছাকাছি শব্দার্থ প্রদান করতে পারি?

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

পদ্ধতি সন্ধান () পদ্ধতি ব্যবহার করা যেতে পারে
অফসেটফরটাইমস(মানচিত্র টাইমস্ট্যাম্পসার্চ) অতীতের কিছু নির্দিষ্ট বিন্দুতে একটি রাজ্যে রিওয়াইন্ড করা।

অন্তর্নিহিতভাবে, এই পদ্ধতিটি ব্যবহার করার অর্থ হল যে এটি খুব সম্ভবত যে কিছু বার্তাগুলি আগে প্রক্রিয়া করা হয়েছিল সেগুলি আবার পড়া এবং প্রক্রিয়া করা হবে৷ এটি এড়াতে, আমরা পূর্বে দেখা বার্তাগুলির ট্র্যাক রাখতে এবং সদৃশগুলি বাদ দিতে অধ্যায় 4 এ বর্ণিত অদম্য পড়া ব্যবহার করতে পারি।

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

ব্যক্তিগত পর্যবেক্ষণ দেখায় যে বার্তাগুলির তীব্রতা বৃদ্ধির সাথে সাথে প্রতিটি পৃথক বার্তার মান হ্রাস পায়। একটি সমষ্টিগত আকারে দেখা হলে বড় বার্তাগুলি মূল্যবান হতে থাকে।

উচ্চ প্রাপ্যতা

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

একটি কাফকা ক্লাস্টার বিভিন্ন সার্ভারে চলমান একাধিক ব্রোকার উদাহরণ নিয়ে গঠিত। কাফকাকে সাধারণ স্বতন্ত্র হার্ডওয়্যারে চালানোর জন্য ডিজাইন করা হয়েছে, যেখানে প্রতিটি নোডের নিজস্ব ডেডিকেটেড স্টোরেজ রয়েছে। নেটওয়ার্ক সংযুক্ত স্টোরেজ (SAN) ব্যবহার করার পরামর্শ দেওয়া হয় না কারণ একাধিক কম্পিউট নোড সময়ের জন্য প্রতিযোগিতা করতে পারে।Ыe স্টোরেজ ব্যবধান এবং দ্বন্দ্ব তৈরি.

কাফকা হল সবসময় পদ্ধতি. অনেক বড় কাফকা ব্যবহারকারীরা কখনই তাদের ক্লাস্টার বন্ধ করে না এবং সফ্টওয়্যারটি সর্বদা একটি ক্রমিক পুনঃসূচনা করে আপডেট হয়। দালালদের মধ্যে বার্তা এবং মিথস্ক্রিয়াগুলির জন্য পূর্ববর্তী সংস্করণের সাথে সামঞ্জস্যের গ্যারান্টি দিয়ে এটি অর্জন করা হয়।

একটি সার্ভার ক্লাস্টারের সাথে সংযুক্ত ব্রোকাররা চিড়িয়াখানা, যা একটি কনফিগারেশন ডেটা রেজিস্ট্রি হিসাবে কাজ করে এবং প্রতিটি ব্রোকারের ভূমিকা সমন্বয় করতে ব্যবহৃত হয়। ZooKeeper নিজেই একটি বিতরণ করা সিস্টেম যা তথ্যের প্রতিলিপি স্থাপনের মাধ্যমে উচ্চ প্রাপ্যতা প্রদান করে কোরাম.

বেস ক্ষেত্রে, নিম্নলিখিত বৈশিষ্ট্য সহ একটি কাফকা ক্লাস্টারে একটি বিষয় তৈরি করা হয়েছে:

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

সমন্বয়ের জন্য ZooKeepers ব্যবহার করে, কাফকা ক্লাস্টারের দালালদের মধ্যে ন্যায্যভাবে নতুন পার্টিশন বিতরণ করার চেষ্টা করেন। এটি একটি একক উদাহরণ দ্বারা করা হয় যা একটি কন্ট্রোলার হিসাবে কাজ করে।

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

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

প্রযোজক কনফিগারেশনের অংশ হল পরামিতি acks, যা নির্ধারণ করে যে অ্যাপ্লিকেশন থ্রেডটি পাঠানো চালিয়ে যাওয়ার আগে কতগুলি প্রতিলিপিকে একটি বার্তার প্রাপ্তি স্বীকার করতে হবে (স্বীকার করতে হবে: 0, 1, বা সমস্ত)৷ যদি সেট করা হয় সব, তারপর যখন একটি বার্তা প্রাপ্ত হয়, নেতা প্রযোজকের কাছে নিশ্চিতকরণ (স্বীকৃতি) পাওয়ার সাথে সাথে বিষয় সেটিং দ্বারা সংজ্ঞায়িত বেশ কয়েকটি ইঙ্গিত (নিজের সহ) থেকে রেকর্ডের নিশ্চিতকরণ (স্বীকৃতি) প্রাপ্তির সাথে সাথে একটি নিশ্চিতকরণ পাঠাবেন। min.insync.replicas (ডিফল্ট 1)। যদি বার্তাটি সফলভাবে প্রতিলিপি করা না যায়, তাহলে প্রযোজক একটি অ্যাপ্লিকেশন ব্যতিক্রম নিক্ষেপ করবেন (NotEnoughReplicas বা NotEnoughReplicasAfterAppend).

একটি সাধারণ কনফিগারেশন 3 এর একটি প্রতিলিপি ফ্যাক্টর (1 নেতা, 2 প্রতি পার্টিশনে XNUMX অনুসারী) এবং পরামিতি সহ একটি বিষয় তৈরি করে min.insync.replicas 2-এ সেট করা হয়েছে। এই ক্ষেত্রে, ক্লাস্টারটি টপিক পার্টিশন পরিচালনাকারী ব্রোকারদের একজনকে ক্লায়েন্ট অ্যাপ্লিকেশনগুলিকে প্রভাবিত না করে নিচে যেতে দেবে।

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

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

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

একটি কাফকা ব্রোকারের তুলনায় একটি কাফকা ক্লাস্টারে অনেক ভালো পারফরম্যান্স সম্ভব, কারণ টপিক পার্টিশনগুলি অনেকগুলি পৃথক মেশিনে স্কেল করতে পারে।

ফলাফল

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

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

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

চলবে…

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

কাফকা কি আপনার প্রতিষ্ঠানে ব্যবহৃত হয়?

• হাঁ

• না

• আগে ব্যবহার হতো, এখন নেই

• আমরা ব্যবহার করার পরিকল্পনা করছি

38 জন ব্যবহারকারী ভোট দিয়েছেন। 8 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com