দোষ সহনশীলতা এবং উচ্চ প্রাপ্যতা বড় বিষয়, তাই আমরা RabbitMQ এবং Kafka-কে আলাদা নিবন্ধ দেব। এই নিবন্ধটি RabbitMQ সম্পর্কে এবং পরেরটি Kafka বনাম RabbitMQ সম্পর্কে। নিবন্ধটি দীর্ঘ, তাই নিজেকে আরামদায়ক করুন।

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

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

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

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

একক নোড স্থিতিস্থাপকতা আদিম

টেকসই সারি/রাউটিং

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

নোড পুনরায় চালু হলে উদ্বায়ী সারি এবং রাউটিং সরানো হয়।

টেকসই বার্তা

একটি সারি টেকসই হওয়ার অর্থ এই নয় যে এর সমস্ত বার্তা একটি নোড পুনরায় চালু হলে বেঁচে থাকবে। শুধুমাত্র প্রকাশক দ্বারা সেট করা বার্তা টেকসই (অস্থির)। ক্রমাগত বার্তাগুলি ব্রোকারের উপর অতিরিক্ত বোঝা চাপায়, কিন্তু যদি বার্তার ক্ষতি অগ্রহণযোগ্য হয়, তবে অন্য কোন বিকল্প নেই।

ভাত। 1. স্থিতিশীলতা ম্যাট্রিক্স

সারি মিররিং সহ ক্লাস্টারিং

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

সারি মিররিং:

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

ভাত। 2. সারিতে মিররিং

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

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (একটি মাস্টার এবং একটি আয়না)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

প্রকাশক নিশ্চিতকরণ

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

ব্যর্থতার সারি

যখন একটি ব্রোকার বন্ধ হয়ে যায় বা ক্র্যাশ হয়, তখন সেই নোডের সমস্ত সারির নেতারা (মাস্টার) এর সাথে পড়ে যায়। ক্লাস্টার তারপর প্রতিটি মাস্টারের প্রাচীনতম আয়না বেছে নেয় এবং এটিকে নতুন মাস্টার হিসাবে প্রচার করে।

ভাত। 3. একাধিক মিররড সারি এবং তাদের নীতি

ব্রোকার 3 নেমে যায়। নোট করুন যে ব্রোকার 2-এ সারির সি-এর আয়নাটি মাস্টারে উন্নীত হয়েছে। এছাড়াও নোট করুন যে ব্রোকার 1-এ সারি C-এর জন্য একটি নতুন মিরর তৈরি করা হয়েছে। RabbitMQ সর্বদা আপনার নীতিতে উল্লেখিত প্রতিলিপি ফ্যাক্টর বজায় রাখার চেষ্টা করে।

ভাত। 4. ব্রোকার 3 বন্ধ হয়ে যায়, যার ফলে সারি C ব্যর্থ হয়

পরবর্তী ব্রোকার 1 ডাউন! আমাদের মাত্র একজন দালাল বাকি আছে। সারির বি এর আয়নাটি মাস্টারে উন্নীত হয়।

Рис। 5

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

এই ক্ষেত্রে, ব্রোকার 1-এর ক্ষতি সম্পূর্ণ হয়েছে, যেমন ডেটা হারানো হয়েছিল, তাই নন-মিররড কিউ বি সম্পূর্ণভাবে হারিয়ে গেছে।

ভাত। 6. ব্রোকার 1 পরিষেবাতে ফিরে আসে

ব্রোকার 3 অনলাইনে ফিরে এসেছে, তাই সারি A এবং B তাদের HA নীতিগুলি সন্তুষ্ট করার জন্য তাদের আয়না ফিরে পায়। কিন্তু এখন সব মাস্টার সারি একই নোডে আছে! এটি নিখুঁত নয়, নোডগুলির মধ্যে একটি অভিন্ন বন্টন থাকা ভাল। দুর্ভাগ্যবশত, মাস্টারদের ভারসাম্য বজায় রাখার জন্য কোন নির্দিষ্ট বিকল্প নেই। আমরা পরে এই সমস্যায় ফিরে আসব, কারণ আমাদের প্রথমে কিউ সিঙ্ক্রোনাইজেশন বিবেচনা করতে হবে।

ভাত। 7. ব্রোকার 3 পরিষেবাতে ফিরে আসে। এক নোডে সব মাস্টার সারি!

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

সিঙ্ক্রোনাইজেশন

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

এই সিঙ্ক্রোনাইজেশন স্বয়ংক্রিয় বা ম্যানুয়াল এবং একটি সারিবদ্ধ নীতি দ্বারা নিয়ন্ত্রিত হয়। একটি উদাহরণ বিবেচনা করুন।

আমাদের দুটি মিররড সারি আছে। সারি A স্বয়ংক্রিয়ভাবে সিঙ্ক্রোনাইজ হয়, যখন সারি B ম্যানুয়ালি সিঙ্ক্রোনাইজ হয়। উভয় সারিতে দশটি বার্তা রয়েছে।

ভাত। 8. বিভিন্ন সময় মোড সহ দুটি সারি

এখন আমরা ব্রোকার 3 হারাচ্ছি।

ভাত। 9. দালাল 3 নেমে গেছে

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

ভাত। 10. সারির A-এর নতুন আয়না বিদ্যমান সমস্ত বার্তা গ্রহণ করে, কিন্তু সারির B-এর নতুন আয়না পায় না

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

ভাত। 11. বার্তার ক্ষতি ছাড়াই ব্রোকার 1 দ্বারা সারি A কে ফিরিয়ে আনা হয়েছে

উভয় সারি প্রতিটি আরও দশটি বার্তা গ্রহণ করে। ব্রোকার 1 এখন ক্র্যাশ হয়েছে৷ কিউ A কোনো বার্তার ক্ষতি ছাড়াই আয়নার কাছে ব্যর্থ হয়৷ তবে, কিউ বি সমস্যা হচ্ছে। এই মুহুর্তে, আমরা প্রাপ্যতা বা ধারাবাহিকতা অপ্টিমাইজ করতে পারি।

আমরা প্রাপ্যতা অপ্টিমাইজ করতে চাই, তারপর নীতি ha-promote-on-failure মধ্যে ইনস্টল করা উচিত সর্বদা. এটি ডিফল্ট মান, তাই আপনি কেবল নীতিটি নির্দিষ্ট করতে পারবেন না। এই ধরনের ক্ষেত্রে, কার্যত, আমরা সিঙ্কের বাইরের আয়নায় ব্যর্থতার অনুমতি দিই। এর ফলে বার্তাগুলি হারিয়ে যাবে, কিন্তু সারিটি পাঠযোগ্য এবং লেখার যোগ্য থাকবে।

ভাত। 12. সারি A ব্রোকার 3 এ বার্তা হারানো ছাড়াই ফিরিয়ে আনা হয়েছে। কিউ B দশটি বার্তা হারিয়ে ব্রোকার 3-এ ফিরে আসে

আমরাও ইন্সটল করতে পারি ha-promote-on-failure অর্থে when-synced. এই ক্ষেত্রে, মিররে ফিরে যাওয়ার পরিবর্তে, ব্রোকার 1 তার ডেটা নিয়ে অনলাইনে ফিরে আসা পর্যন্ত সারি অপেক্ষা করবে। এটি ফিরে আসার পরে, ডেটা ক্ষতি ছাড়াই ব্রোকার 1-এ মূল সারি ফিরে এসেছে। তথ্য নিরাপত্তার জন্য প্রাপ্যতা বলি দেওয়া হয়। কিন্তু এটি একটি ঝুঁকিপূর্ণ মোড, যা এমনকি সম্পূর্ণ ডেটা হারাতে পারে, যা আমরা শীঘ্রই বিবেচনা করব।

ভাত। 13. ব্রোকার 1 হারানোর পরে সারি B অনুপলব্ধ থাকে৷

আপনি জিজ্ঞাসা করতে পারেন, "স্বয়ংক্রিয় সিঙ্ক্রোনাইজেশন ব্যবহার না করা কি ভাল?" উত্তর হল যে সিঙ্ক্রোনাইজেশন একটি ব্লকিং অপারেশন। সিঙ্ক্রোনাইজেশনের সময়, প্রধান সারিতে কোনো পঠন বা লেখার ক্রিয়াকলাপ সম্পাদন করা যাবে না!

একটি উদাহরণ বিবেচনা করুন। এখন আমাদের অনেক লম্বা সারি। কিভাবে তারা যেমন একটি আকার বৃদ্ধি করতে পারেন? বিভিন্ন কারণে:

• সারি সক্রিয়ভাবে ব্যবহার করা হয় না
• এগুলি উচ্চ-গতির সারি, এবং এই মুহূর্তে ভোক্তারা ধীরে ধীরে চলছে৷
• এগুলি উচ্চ-গতির সারি, একটি ব্যর্থতা হয়েছে এবং ভোক্তারা ধরছেন

ভাত। 14. বিভিন্ন সময় মোড সহ দুটি বড় সারি

ব্রোকার 3 এখন ক্র্যাশ।

ভাত। 15. ব্রোকার 3 ক্র্যাশ করে প্রতিটি সারিতে একজন মাস্টার এবং মিরর রেখে যায়

ব্রোকার 3 অনলাইনে ফিরে আসে এবং নতুন আয়না তৈরি হয়। মাস্টার সারি A নতুন মিররে বিদ্যমান বার্তাগুলিকে প্রতিলিপি করা শুরু করে এবং এই সময়ের মধ্যে সারিটি অনুপলব্ধ থাকে৷ ডেটা প্রতিলিপি করতে দুই ঘণ্টা সময় লাগে, ফলে এই সারির জন্য দুই ঘণ্টার ডাউনটাইম!

যাইহোক, সারি বি পুরো সময় জুড়ে উপলব্ধ থাকে। তিনি অ্যাক্সেসযোগ্যতার জন্য কিছু অপ্রয়োজনীয়তা ত্যাগ করেছেন।

ভাত। 16. সিঙ্ক্রোনাইজেশনের সময় সারি অনুপলব্ধ থাকে

দুই ঘন্টা পরে, কিউ Aও উপলব্ধ হয়ে যায় এবং আবার পড়া এবং লেখা গ্রহণ করা শুরু করতে পারে।

আপডেট

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

• always= আনসিঙ্ক্রোনাইজড মিররগুলিতে ব্যর্থতা সক্ষম
• when-synced= শুধুমাত্র একটি সিঙ্ক্রোনাইজড মিররে সরান, অন্যথায় সারিটি অপঠনযোগ্য এবং লেখার অযোগ্য হয়ে যায়। দালাল ফিরে আসার সাথে সাথে সারিটি পরিষেবাতে ফিরে আসে

এক বা অন্য উপায়, বড় সারি সহ, আপনাকে ডেটা হারানো এবং অনুপলব্ধতার মধ্যে বেছে নিতে হবে।

যখন উপলব্ধতা ডেটা নিরাপত্তা উন্নত করে

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

এখানে আপনাকে নিম্নলিখিতগুলি বিবেচনা করতে হবে:

• প্রকাশক কি কেবল একটি ত্রুটি ফিরিয়ে দিতে পারে এবং আপস্ট্রিম পরিষেবা বা ব্যবহারকারীকে পরে আবার চেষ্টা করতে পারে?
• প্রকাশক কি পরে আবার চেষ্টা করার জন্য স্থানীয়ভাবে বা ডাটাবেসে বার্তাটি সংরক্ষণ করতে পারেন?

যদি প্রকাশক শুধুমাত্র বার্তাটি ড্রপ করতে সক্ষম হয়, তবে প্রকৃতপক্ষে, অ্যাক্সেসযোগ্যতা উন্নত করা ডেটা সুরক্ষাও উন্নত করে।

সুতরাং, একটি ভারসাম্য চাওয়া আবশ্যক, এবং সিদ্ধান্ত নির্দিষ্ট পরিস্থিতির উপর নির্ভর করে।

ha-promote-on-failure=when-sync-এর সাথে সমস্যা

ধারণা ha-promote-on-failure= যখন-সিঙ্ক করা হয় আমরা একটি অসিঙ্ক্রোনাইজড মিররে স্যুইচ করা প্রতিরোধ করি এবং এইভাবে ডেটা ক্ষতি এড়াতে পারি। সারিটি অপঠনযোগ্য বা লেখার অযোগ্য থেকে যায়। পরিবর্তে, আমরা অক্ষত ডেটা সহ পতিত ব্রোকারকে ফিরিয়ে আনার চেষ্টা করছি যাতে এটি ডেটা ক্ষতি ছাড়াই মাস্টার হিসাবে পুনরায় শুরু করতে পারে।

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

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

অতএব, ম্যানুয়াল সিঙ্ক্রোনাইজেশন (এবং সিঙ্ক্রোনাইজ করতে ব্যর্থতা) সঙ্গে সমন্বয় ha-promote-on-failure=when-syncedআমার মতে বেশ ঝুঁকিপূর্ণ। ডক্স বলে যে এই বিকল্পটি ডেটা সুরক্ষার জন্য বিদ্যমান, তবে এটি একটি দ্বি-ধারী ছুরি।

মাস্টার রিব্যালেন্সিং

প্রতিশ্রুতি অনুসারে, আমরা এক বা একাধিক নোডে সমস্ত মাস্টারের জমা হওয়ার সমস্যায় ফিরে আসি। এমনকি ক্লাস্টারের একটি ঘূর্ণায়মান আপডেটের ফলে এটি ঘটতে পারে। একটি তিন-নোড ক্লাস্টারে, সমস্ত মাস্টার সারি এক বা দুটি নোডে জমা হবে।

ভারসাম্যপূর্ণ মাস্টার দুটি কারণে সমস্যাযুক্ত হতে পারে:

• ভারসাম্য বজায় রাখার জন্য কোনও ভাল সরঞ্জাম নেই
• সারি সিঙ্ক্রোনাইজেশন

ভারসাম্য বজায় রাখার জন্য একটি তৃতীয় পক্ষ আছে প্লাগ লাগানো, যা সরকারীভাবে সমর্থিত নয়। RabbitMQ ম্যানুয়াল তৃতীয় পক্ষের প্লাগইন সম্পর্কে বলেছেন: "প্লাগইনটি কিছু অতিরিক্ত কনফিগারেশন এবং রিপোর্টিং টুল প্রদান করে, কিন্তু RabbitMQ টিম দ্বারা সমর্থিত বা পরীক্ষিত নয়৷ আপনার নিজের ঝুঁকিতে ব্যবহার করুন."

HA নীতির মাধ্যমে মূল সারিতে সরানোর আরেকটি কৌশল রয়েছে। ম্যানুয়াল উল্লেখ করা হয়েছে লিপি এই জন্য এটি এই মত কাজ করে:

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

নেতিবাচক দিক হল এই পদ্ধতিটি কাজ নাও করতে পারে যদি আপনার বড় সারি বা কঠোর অপ্রয়োজনীয় প্রয়োজনীয়তা থাকে।

এখন দেখা যাক কিভাবে RabbitMQ ক্লাস্টারগুলো নেটওয়ার্ক পার্টিশনের সাথে কাজ করে।

সংযোগ বিঘ্নিত

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

RabbitMQ এর সাথে আমাদের দুটি প্রধান বিকল্প রয়েছে:

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

কিন্তু যৌক্তিক বিচ্ছেদ কি? নেটওয়ার্ক লিঙ্কগুলি হারিয়ে যাওয়ার কারণে ক্লাস্টার দুটি ভাগে বিভক্ত হলে এটি হয়। প্রতিটি দিকে, আয়নাগুলিকে মাস্টার হিসাবে উন্নীত করা হয়, যাতে শেষ পর্যন্ত প্রতি সারিতে বেশ কয়েকটি মাস্টার থাকে।

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

যদি প্রকাশকরা উভয় মাস্টারের কাছে ডেটা পাঠায়, তাহলে আমাদের কাছে সারির দুটি ভিন্ন ভিন্ন কপি থাকবে।

RabbitMQ এর বিভিন্ন মোড উপলব্ধতা বা ধারাবাহিকতা প্রদান করে।

উপেক্ষা মোড (ডিফল্ট)

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

ভাত। 18. তিনজন প্রকাশক তিনজন দালালের সাথে যুক্ত। অভ্যন্তরীণভাবে, ক্লাস্টারটি ব্রোকার 2-এর প্রধান সারিতে সমস্ত অনুরোধকে রুট করে।

এখন আমরা ব্রোকার 3 হারাচ্ছি। তিনি দেখেন যে অন্যান্য দালালরা পড়ে গেছে এবং তার আয়নাটি মাস্টারের কাছে নিয়ে গেছে। এভাবেই যৌক্তিক বিচ্ছেদ ঘটে।

ভাত। 19. লজিক্যাল ডিভিশন (বিভক্ত-মস্তিষ্ক)। রেকর্ড দুটি প্রধান সারিতে যায়, এবং দুটি কপি বেরিয়ে যায়।

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

ভাত। 20. অ্যাডমিনিস্ট্রেটর ব্রোকার 3 নিষ্ক্রিয় করে।

ভাত। 21. অ্যাডমিনিস্ট্রেটর ব্রোকার 3 শুরু করে এবং এটি ক্লাস্টারে যোগ দেয়, সেখানে থাকা সমস্ত বার্তা হারিয়ে ফেলে।

সংযোগ বিচ্ছিন্ন হওয়ার সময় এবং এটি পুনরুদ্ধারের পরে, ক্লাস্টার এবং এই সারি পড়া এবং লেখার জন্য উপলব্ধ ছিল।

অটোহেল মোড

উপেক্ষা মোডের অনুরূপ কাজ করে, বিভক্ত এবং পুনঃসংযোগের পরে ক্লাস্টার নিজেই স্বয়ংক্রিয়ভাবে হারানো দিকটি বেছে নেয়। হারানো দিকটি খালি ক্লাস্টারে ফিরে আসে এবং সারিটি কেবলমাত্র সেই দিকে পাঠানো সমস্ত বার্তা হারায়।

মাইনর মোড পজ করুন

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

ভাত। 22. তিনজন প্রকাশক তিনজন দালালের সাথে যুক্ত। অভ্যন্তরীণভাবে, ক্লাস্টারটি ব্রোকার 2-এর প্রধান সারিতে সমস্ত অনুরোধকে রুট করে।

ব্রোকার 1 এবং 2 তারপর ব্রোকার 3 থেকে আলাদা। এর মিররকে মাস্টার হিসাবে উন্নীত করার পরিবর্তে, ব্রোকার 3 বিরতি দেয় এবং অনুপলব্ধ হয়ে যায়।

ভাত। 23. ব্রোকার 3 স্থগিত করে, সমস্ত ক্লায়েন্টকে সংযোগ বিচ্ছিন্ন করে এবং সংযোগের অনুরোধ প্রত্যাখ্যান করে।

যত তাড়াতাড়ি সংযোগ পুনরুদ্ধার করা হয়, এটি ক্লাস্টারে ফিরে আসে।

আসুন আরেকটি উদাহরণ দেখি যেখানে প্রধান সারিটি ব্রোকার 3 এ রয়েছে।

ভাত। 24. ব্রোকার 3 এ প্রধান সারি।

তারপর সংযোগের একই ক্ষতি ঘটে। ব্রোকার 3 বিরতি দেয় কারণ এটি ছোট দিকে। অন্য দিকে, নোডগুলি দেখতে পায় যে ব্রোকার 3 বন্ধ হয়ে গেছে, তাই ব্রোকার 1 এবং 2 থেকে পুরোনো মিররটিকে মাস্টার হিসাবে উন্নীত করা হয়েছে।

ভাত। 25. ব্রোকার 2 এ স্যুইচ করা যখন ব্রোকার 3 পাওয়া যায় না।

সংযোগ পুনরুদ্ধার করা হলে, ব্রোকার 3 ক্লাস্টারে যোগদান করবে।

ভাত। 26. ক্লাস্টার স্বাভাবিক অপারেশনে ফিরে এসেছে।

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

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

গ্রাহক সংযোগ নিশ্চিত করা

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

আমাদের বিকল্প:

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

তথ্যও

RabbitMQ ক্লাস্টারিংয়ের সুবিধা এবং অসুবিধা রয়েছে। সবচেয়ে গুরুতর অসুবিধা হল:

• একটি ক্লাস্টারে যোগদান করার সময়, নোডগুলি তাদের ডেটা বাতিল করে;
• সিঙ্ক্রোনাইজেশন ব্লক করার ফলে সারি অনুপলব্ধ হয়ে যায়।

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

• অবিশ্বস্ত নেটওয়ার্ক।
• অবিশ্বস্ত স্টোরেজ।
• অনেক লম্বা লাইন।

উচ্চ প্রাপ্যতার জন্য সেটিংস হিসাবে, এইগুলি বিবেচনা করুন:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (বা autoheal)
• টেকসই বার্তা
• নিশ্চিত করুন যে ক্লায়েন্টরা সক্রিয় নোডের সাথে সংযোগ স্থাপন করে যখন কিছু নোড নিচে যায়

ধারাবাহিকতার জন্য (ডেটা নিরাপত্তা), নিম্নলিখিত সেটিংস বিবেচনা করুন:

• ভোক্তার পক্ষ থেকে প্রকাশক নিশ্চিত করে এবং ম্যানুয়াল স্বীকৃতি দেয়
• ha-promote-on-failure=when-syncedযদি প্রকাশকরা পরে আবার চেষ্টা করতে পারেন এবং যদি আপনার খুব শক্তিশালী স্টোরেজ থাকে! অন্যথায় লাগান =always.
• ha-sync-mode=automatic (কিন্তু বড় নিষ্ক্রিয় সারিগুলির জন্য ম্যানুয়াল মোডের প্রয়োজন হতে পারে; এছাড়াও, অনুপলব্ধতার কারণে বার্তাগুলি হারিয়ে যাবে কিনা তা বিবেচনা করুন)
• সংখ্যালঘু মোড পজ করুন
• টেকসই বার্তা

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

যদি আমি অন্য কিছু মিস করে থাকি, দয়া করে আমাকে জানান।

আমারও দেখুন পোস্টযেখানে আমি এই নিবন্ধে বর্ণিত কিছু বার্তা ক্ষতির পরিস্থিতি পরীক্ষা করার জন্য ডকার এবং ব্লকেডের সাথে একটি RabbitMQ ক্লাস্টার পোগ্রোমিং করছি।

সিরিজের আগের নিবন্ধগুলি:
নং 1 - habr.com/ru/company/itsumma/blog/416629
নং 2 - habr.com/ru/company/itsumma/blog/418389
নং 3 - habr.com/ru/company/itsumma/blog/437446

উত্স: www.habr.com