স্ট্যান্ডার্ড অপ্রয়োজনীয় রেডিস সমাধান হল সেন্টিনেল ফেইলওভার পরিচালনা করে মাস্টার/স্লেভ রেপ্লিকেশন চালানো। এটি হয় ক) ক্লায়েন্ট সমর্থন এবং বর্তমান মাস্টার আবিষ্কার করতে সেন্টিনেলের ব্যবহার বা খ) রেডিস পডের সামনে একটি টিসিপি প্রক্সি যা সেন্টিনেল দ্বারা মাস্টারকে নির্দেশ করার জন্য পরিচালিত হবে বলে আশা করা হচ্ছে। প্রথমটি হল রেডিস সেন্টিনেলকে ডিজাইন করা উপায় এবং পরবর্তীটি একটি ক্রমবর্ধমান প্রবণতা – এবং অবজেক্ট রকেট রেডিস যেভাবে কনফিগার করা হয়েছে৷
Redis-এ কমান্ডে ব্যর্থতার প্রভাব
Redis অপারেশনের বিশাল সংখ্যাগরিষ্ঠের জন্য এটি প্রত্যাশিত হিসাবে কাজ করে। ফেইলওভারে ক্লায়েন্ট কোডটি সংযোগ ব্যর্থ হয়েছে তা সনাক্ত করবে বলে আশা করা হয় এবং হয় ক) বর্তমান মাস্টারটি সন্ধান করুন এবং পুনরায় সংযোগ করুন বা খ) উপরে উল্লিখিত পরিস্থিতিগুলির উপর ভিত্তি করে পুনরায় সংযোগ করার চেষ্টা করুন৷ প্রক্সি ভিত্তিক দৃশ্যটিও একটি রেডিস সার্ভার রিস্টার্টের অনুরূপ তাই এটি এমন ক্ষেত্রেও প্রযোজ্য যেখানে আপনার একটি একক উদাহরণ রেডিস আছে যা পুনরায় চালু করা যেতে পারে৷
তবে অল্প কিছু রেডিস কমান্ড দীর্ঘমেয়াদী ব্লকিং বা অ-পারমাণবিক। PUBSUB সাবস্ক্রাইব এবং সাবস্ক্রাইব কমান্ডগুলি নন-এটমিক যে কমান্ডটি প্রদত্ত চ্যানেল(গুলি) এ পাঠানো কোনও বার্তা পাঠানোর অনুরোধটি নিবন্ধিত করবে, তবে প্রকৃত ডেটা অনেক পরে আসতে পারে - যেমন। এটি প্রকাশিত হওয়ার পর। BL* কমান্ডগুলি দীর্ঘমেয়াদী এবং সাবস্ক্রাইব কমান্ডের মতো দুটি ফেজ কমান্ড এগুলি ব্লক করবে এবং অপসারণের তালিকায় একটি আইটেম উপলব্ধ না হওয়া পর্যন্ত ফিরে আসবে না৷
এই কমান্ডগুলির মধ্যে একটি মূল সাধারণতা হল যে সেগুলি জারি করা হয় এবং সার্ভারে একটি ফর্ম নিবন্ধন করা হয়, তবে ডেটা পরে আসতে পারে। কমান্ড ইস্যু করা এবং সার্ভারের মধ্যে ডেটা আছে যা ফেইলওভারের সাথে উত্তর দিতে পারে এবং পুনরায় চালু হতে পারে। রিস্টার্ট বা ফেইলওভারের ক্ষেত্রে "রেজিস্ট্রেশন" আর সার্ভারে থাকে না। এটি আমাদের এই পরিস্থিতিতে নিয়ে আসে যে এই পরিস্থিতিতে এই কমান্ডগুলির বিষয়ে কী ঘটবে৷
৷এই বিশদ বিবরণগুলি দেখার আগে আরও একটি দিক উত্থাপন করতে হবে কারণ এটি পরীক্ষার সময় কার্যকর হবে এবং ফলাফলের উপর নাটকীয় প্রভাব ফেলবে এবং ব্যর্থতার পরিস্থিতিগুলির জন্য কীভাবে কোড করতে হবে। আসলে দুই ধরনের ফেইলওভার আছে। আমাদের মধ্যে বেশিরভাগই বিবেচনা করে ব্যর্থতা রয়েছে - মাস্টারের ক্ষতি। এই ধরনের ফেইলওভারে মাস্টার অ-প্রতিক্রিয়াশীল। আমি এটিকে "ট্রিগার করা ব্যর্থতা" হিসাবে উল্লেখ করি। দ্বিতীয় শ্রেণীর ব্যর্থতাকে আমি "শুরু করা ব্যর্থতা" হিসাবে উল্লেখ করি।
ইনিশিয়েটেড ফেইলওভার সংঘটিত হয় যখন একজন প্রশাসক সেন্টিনেলের কাছে সেন্টিনেল ফেইলওভার কমান্ড পাঠায় যা তারপরে পডটিকে পুনরায় কনফিগার করে, একটি মাস্টারকে প্রচার করে তারপর মূল মাস্টারকে অবনমিত করে। উপরিভাগে এই দুটি দৃশ্যকল্প একই বলে মনে হয়। Redis কমান্ডের বিশাল সংখ্যাগরিষ্ঠ ক্ষেত্রে তাদের অভিন্নভাবে আচরণ করা যেতে পারে। যাইহোক, আমাদের লং-ব্লক কমান্ডের ক্ষেত্রে তাদের নিজেদের প্রেক্ষাপটে বুঝতে হবে।
এই দুটি ফেইলওভার ক্লাসের মধ্যে মূল কার্যকরী পার্থক্যকারী হল ঘটনাগুলির ক্রম। যখন একটি ট্রিগার করা ব্যর্থতা ঘটে তখন এটি হয় কারণ মাস্টার সাড়া দিচ্ছেন না। এই ক্ষেত্রে কোন তথ্য যোগ বা পরিবর্তন করা হচ্ছে না, এবং মাস্টারের উপর কোন বার্তা প্রকাশিত হয়নি। একটি ইনিশিয়েটেড ফেইলওভারে একটি খুব সংক্ষিপ্ত উইন্ডো থাকে যেখানে দুটি মাস্টার থাকে৷
৷এখানে আলোচনা করা কৌশল এবং পরিস্থিতিগুলি সাধারণভাবে বর্ণনা করা হবে এবং পাইথন রেডিস লাইব্রেরি "redis-py" ব্যবহার করে প্রদর্শন করা হবে, তবে যেকোনো ক্লায়েন্ট লাইব্রেরিতে প্রযোজ্য হবে। ব্যাকগ্রাউন্ড হাতে রেখে, আসুন এখন দেখি এটি কীভাবে লং-ব্লক কমান্ডের ব্যবহারকে প্রভাবিত করে। প্রথমে PUBSUB-এর দিকে নজর দেওয়া যাক।
পাবসাব
৷Redis PUBSUB তিনটি কমান্ড নিয়ে গঠিত:পাবলিশ, সাবস্ক্রাইব এবং সাবস্ক্রাইব। প্রথম কমান্ডটি একটি বার্তা পাঠাতে ব্যবহৃত হয় যেখানে পরবর্তী দুটি PUBLISH কমান্ডের মাধ্যমে প্রকাশিত বার্তাগুলির জন্য নিবন্ধন এবং গ্রহণ করতে ব্যবহৃত হয়। প্রথমে, আসুন আমরা পরীক্ষা করি যে একটি পাবলিশ কমান্ডে কী ঘটে।
আপনি যখন প্রকাশ করবেন তখন এটি প্রদত্ত চ্যানেলে বার্তাটি অবিলম্বে প্রকাশ করবে এবং প্রাপ্ত ক্লায়েন্টের সংখ্যা ফেরত দেবে। কোন উপায়ে একটি ব্যর্থতার দৃশ্য এটি প্রাসঙ্গিকতা নিয়ে আসে? ব্যর্থতার ক্ষেত্রে বিবেচনা করুন। TCP সংযোগ চলে যাওয়ায় ক্লায়েন্টকে পুনরায় সংযোগ করতে হবে। একটি প্রক্সির সাথে কথা বললে এটি সরাসরি পুনরায় সংযোগ করবে এবং একটি ভিন্ন সার্ভার পাবে৷ সেন্টিনেল আবিষ্কার করলে এটি একটু বেশি সময় নেবে এবং এখনও একটি ভিন্ন সার্ভারের সাথে সংযোগ স্থাপন করবে। যেখানে ইস্যুটি রয়েছে তা হল সময়ের মধ্যে। কোনো গ্রাহকের আগে প্রকাশক নতুন সার্ভারের সাথে সংযোগ করলে, বার্তাটি চলে গেছে - হারিয়ে গেছে। কিন্তু তা কি হতে পারে? এটা বোঝার জন্য আমরা সাবস্ক্রাইব কমান্ডের দিকে তাকাই।
যখন আপনার কোড একটি সাবস্ক্রাইব কমান্ড ইস্যু করে তখন সার্ভারটি এটির ইন-মেমরি ডেটা স্ট্রাকচারে নিবন্ধন করে যে নির্দিষ্ট সংযোগটি সদস্যতা নেওয়া চ্যানেল(গুলি) এ বার্তা পেতে হবে। এই তথ্য দাসদের প্রচার করা হয় না. এইভাবে যখন একটি ব্যর্থতা ঘটবে এবং ক্লায়েন্ট পুনরায় সংযোগ করবে তখন সাবস্ক্রাইব কমান্ডটি পুনরায় জারি করতে হবে। অন্যথায় নতুন সার্ভার জানে না যে নির্দিষ্ট সংযোগের জন্য নির্দিষ্ট বার্তা পেতে হবে। এখন আমাদের কাছে একজন গ্রাহকের প্রকাশকের পরে নতুন মাস্টারের সাথে পুনরায় সংযোগ করার স্পষ্ট সম্ভাবনা রয়েছে। বার্তা হারানোর শর্ত এখন বিদ্যমান। তাহলে কীভাবে এটি কমানো বা প্রতিরোধ করা যায়? কিছু অপশন আছে।
প্রথমে প্রকাশক এই সত্যটি লাভ করতে পারে যে প্রকাশক প্রাপ্ত ক্লায়েন্টের সংখ্যা ফেরত দেয়। যদি শূন্য ক্লায়েন্ট এটি গ্রহণ করে তবে প্রকাশক পুনরায় চেষ্টা করতে পারে। সিস্টেমের জন্য যেখানে এটি একটি স্থির গ্রাহক সংখ্যা বা যেখানে "অন্তত একজন গ্রাহক" যথেষ্ট এটি বার্তা ক্ষতি প্রতিরোধ করবে। যে সিস্টেমগুলি এই মানদণ্ড পূরণ করে না, তাদের জন্য আরেকটি বিকল্প আছে, যদি কম শক্তিশালী হয়।
দ্বিতীয় বিকল্প হল পুনরায় সংযোগ করা উইন্ডোগুলি নিয়ন্ত্রণ করা। এখানে সাধারণ নিয়ম হল প্রকাশকের বিলম্ব গ্রাহকদের বিলম্বের চেয়ে কমপক্ষে তিনগুণ হতে হবে। এটি বার্তা প্রকাশের আগে গ্রাহকদের পুনরায় সংযোগ করার জন্য কমপক্ষে তিনটি সুযোগ প্রদান করবে। যতক্ষণ গ্রাহকরা প্রথমে অনলাইনে থাকবেন, ততক্ষণ বার্তাগুলি ইথারে যাবে না। যাইহোক, এটি নিয়ন্ত্রণ না করার চেয়ে আরও শক্তিশালী হলেও এখনও বার্তা হারানোর সম্ভাবনা রয়েছে।
এই রেসের অবস্থা প্রশমিত করার জন্য আমি যে তৃতীয় বিকল্পটি উপস্থাপন করব তা হল একটি লক মেকানিজম তৈরি করা। এটি অবশ্যই সবচেয়ে জটিল রুট কারণ এটির জন্য একটি মেকানিজম তৈরি করা বা নিয়োগ করা প্রয়োজন যা ক্লায়েন্ট সংযোগ না হওয়া পর্যন্ত প্রকাশকদের প্রকাশ করতে বাধা দেয়। মৌলিক প্রক্রিয়া হল শেয়ার করা অবস্থানের কিছু রূপ (যেমন Zookeeper, একটি ডাটাবেস, কনসাল, ইত্যাদির মাধ্যমে) যেখানে গ্রাহকরা নিবন্ধন করে যে তারা গ্রহণ করার জন্য প্রস্তুত এবং গ্রাহকরা বার্তা প্রকাশ করার আগে বৈধ এবং প্রস্তুত গ্রাহকদের জন্য পরীক্ষা করে। আরও বিজ্ঞাপন জটিলতার জন্য গ্রাহকরা যখন TCP সংযোগ হারিয়ে ফেলেন তখন তাদের এই পদ্ধতিতে নিজেকে "আনসেট" করতে হবে।
এটা বলা দরকার যে এই সবই একটি ট্রিগার করা ব্যর্থতার জন্য। এটি কাজ করবে কারণ মাস্টার অ-প্রতিক্রিয়াশীল তাই কোন বার্তা এটিতে যায় না। আরম্ভ করা ব্যর্থতার দৃশ্যে মাস্টার বার্তা গ্রহণ করা চালিয়ে যাবে যতক্ষণ না এটি আর মাস্টার না হয় বা সংযোগ বিচ্ছিন্ন না হয়। উপরের পদ্ধতিগুলির মধ্যে কোনটিই এই দৃশ্যটিকে সঠিকভাবে এবং সম্পূর্ণরূপে ধরতে পারবে না৷
৷ইনিশিয়েটেড ফেইলওভারের ক্ষেত্রে (যেটি যেমন সিস্টেম রক্ষণাবেক্ষণের সময় ঘটতে পারে) আপনার সর্বোত্তম বাট্রেসিং ইফেক্ট হল প্রথম এবং দ্বিতীয় উভয় বিকল্পকে কাজে লাগান এবং স্বীকার করুন যে বার্তার ক্ষতি হতে পারে। কতটা বার্তা ক্ষতি সম্পূর্ণরূপে আপনার প্রকাশের সময়সূচীর উপর নির্ভর করে। আপনি যদি প্রতি কয়েক মিনিটে গড়ে একটি বার্তা প্রকাশ করেন তবে আপনার জন্য ক্ষতির উইন্ডোর মুখোমুখি হওয়ার একটি সামান্য সুযোগ রয়েছে। প্রকাশনার ব্যবধান যত বড় হবে ঝুঁকি তত কম। বিপরীতভাবে আপনি যদি প্রতি সেকেন্ডে শত শত বা হাজার হাজার বার্তা প্রকাশ করেন তবে আপনি অবশ্যই কিছু হারাবেন। পরিচালিত প্রক্সি দৃশ্যের জন্য এটি আপনার প্রক্সিতে কত দ্রুত ব্যর্থতা সম্পূর্ণ হয় তার উপর নির্ভর করবে। অবজেক্টরকেটের রেডিস প্ল্যাটফর্মের জন্য এই উইন্ডোটি 1.5 সেকেন্ড পর্যন্ত।
এইভাবে ব্যবধানে একটি পদ্ধতি, যা সীমাতে ব্যর্থ হয়, তা হল গ্রাহকদের আপনার প্রকাশনার ব্যবধানে 1/3d এর ব্যবধানে পুনরায় সংযোগ করার চেষ্টা করা। এইভাবে আপনি যদি প্রতি মিনিটে একবার একটি বার্তা প্রকাশ করেন, তাহলে আপনার গ্রাহকদের প্রতি 20 সেকেন্ডে এবং আপনার প্রকাশককে প্রতি বা দুই মিনিটে পুনরায় সংযোগ করার জন্য কোড/কনফিগার করুন। প্রকাশনার ব্যবধান যখন 3 সেকেন্ডের কাছাকাছি চলে আসে তখন এটি একটি ব্যর্থতা পুনরায় সংযোগ প্রক্রিয়া (লুকআপ, টিসিপি হ্যান্ডশেক, AUTH, সাবস্ক্রাইব ইত্যাদি) হিসাবে অর্জন করা আরও কঠিন হয়ে পড়ে।
BLPOP এবং বন্ধুরা
এটি আমাদের এই প্রশ্নে নিয়ে আসে যে এই অবস্থার অধীনে ব্লকিং তালিকা কমান্ডগুলি কীভাবে কাজ করে। এখানে খবর প্রকাশের চেয়ে ভালো। এই ক্ষেত্রে আমরা ডেটা স্ট্রাকচার পরিবর্তন করছি যা প্রতিলিপি করা হয়। তদ্ব্যতীত, যেহেতু এগুলি ডেটা স্ট্রাকচারে পরিবর্তন করা হয়েছে, আবার সংযোগের আদেশের কারণে হারিয়ে যাওয়া বার্তাগুলির ঝুঁকির জন্য আমাদের কাছে একই স্তর নেই। যদি প্রযোজক গ্রাহকের আগে পুনরায় সংযোগ করেন তবে প্রত্যাশিত আচরণে কোন পরিবর্তন হবে না। প্রযোজক আইটেমটিকে তালিকায় পুশ করবেন (বা POP এবং PUSH) এবং একবার ভোক্তা সংযোগ করলে ডেটা সেখানে থাকবে। একটি ব্যতিক্রম সহ।
একটি সূচিত ব্যর্থতার ক্ষেত্রে আমাদের অবশ্যই সংক্ষিপ্ত মাল্টিপল-মাস্টার সমস্যাটি বিবেচনা করতে হবে। কয়েক মুহুর্তের জন্য, মিলিসেকেন্ডের ক্রমানুসারে, একটি সূচিত ব্যর্থতার সময় মূল মাস্টার এখনও ডেটা পরিবর্তনগুলি গ্রহণ করবে এবং যেহেতু একজন স্লেভ ইতিমধ্যেই এই পরিবর্তনগুলিকে আয়ত্ত করার জন্য উন্নীত করা হয়েছে সেগুলি প্রতিলিপি হবে না। মনে রাখবেন এই উইন্ডোটি খুবই ছোট। পরীক্ষায় এটি একক সংখ্যা মিলিসেকেন্ডের ক্রম, কিন্তু এটি আছে। প্রকাশনার মতো এটি মূলত একটি কোণার অবস্থা যেখানে আপনার মতপার্থক্য, উদাহরণস্বরূপ, বাসি মাস্টারকে একটি POP কমান্ড জারি করা বিরল যদিও অনুমেয় পরিস্থিতিতে বৃদ্ধি পায় যখন আপনার প্রযোজক এবং ভোক্তাদের তালিকা পরিবর্তন কমান্ড তৈরির হার প্রতি সেকেন্ডে হাজারে পৌঁছে। পি>
উদাহরণস্বরূপ, BRPOPLPUSH করা একজন শ্রমিকের ক্ষেত্রে, ফলাফলটি এমন হবে যে যে আইটেমটি সরানো হচ্ছে সেটি ফেইলওভারের পরে তার আসল অবস্থানে "ফিরে" থাকবে। একটি BLPOP এর ক্ষেত্রে ফলাফল মূলত একই হবে। ফেইলওভার সম্পূর্ণ হওয়ার পরে আইটেমটি পুনরায় সারিবদ্ধ বলে মনে হবে। আপনার আইটেমগুলি যদি অদম্য কাজ হয় তবে এটি কোনও সমস্যা হবে না। অক্ষমতাহীন চাকরির ক্ষেত্রে এটির জন্য আপনাকে কতটা প্রতিরক্ষামূলক কোডিং করতে হবে তা হল একটি কাজ চালানোর প্রভাব বা আইটেম দুবার প্রক্রিয়াকরণের প্রভাব নির্ধারণ করার ফলে আপনি কত ঘন ঘন পরিবর্তন করছেন এবং এটির সম্মুখীন হওয়ার সম্ভাবনা রয়েছে। অবস্থা. এটিও উল্লেখ করা উচিত যে যেহেতু এটি শুধুমাত্র একটি সূচিত ব্যর্থতার ঘটনা ঘটবে এটি কার্যকরী নিয়ন্ত্রণে থাকা উচিত এবং আমি উপদেশ দেব যে যখনই সম্ভব রক্ষণাবেক্ষণ এমন একটি সময়ে করা উচিত যখন আপনার সিস্টেমগুলি তাদের সর্বনিম্ন ব্যবহার কমাতে বা এমনকি এই সম্ভাবনা দূর করুন।
ট্রিগার করা ব্যর্থতার জন্য ডেটা হারানোর কোন প্রত্যাশা নেই। একটি ট্রিগারড ফেইলওভার ঘটে যখন মাস্টার প্রতিক্রিয়াহীন হয়, এইভাবে মাস্টারের সাথে কোন পরিবর্তন করা হয় না। যাইহোক, এই প্রতিটি পরিস্থিতির মতোই প্রকৃত TCP পুনরায় সংযোগ পরিচালনা করার বিষয়টি রয়েছে যা যেকোনো ব্যর্থতার দৃশ্যে বাধ্যতামূলক৷
ক্লায়েন্ট পুনঃসংযোগ
হয় ব্যর্থতার দৃশ্যের অধীনে, ট্রিগার বা সূচনা, ক্লায়েন্টকে সনাক্ত করতে হবে এবং পুনরায় সংযোগ করতে হবে - হয় সেন্টিনেল সন্ধানের পরে বা একই ঠিকানায় একটি সংক্ষিপ্ত উইন্ডোর পরে। অবজেক্ট রকেট রেডিসের ক্ষেত্রে যা একটি পরিচালিত প্রক্সি স্তর ব্যবহার করে ক্লায়েন্ট সহজভাবে পুনরায় সংযোগ করবে। প্রকৃত ব্যর্থতা প্রক্রিয়াটি সম্পূর্ণ হতে দুই সেকেন্ড পর্যন্ত সময় নিতে পারে। এইভাবে ক্লায়েন্ট কোড এই জন্য অ্যাকাউন্ট করা উচিত. আদর্শভাবে নেটওয়ার্ক ব্লিপগুলি পরিচালনা করার জন্য একটি অবিলম্বে পুনরায় চেষ্টা করা উচিত যেখানে একটি সংযোগ সহজভাবে রুট বরাবর কোথাও ফেলে দেওয়া হয়। যাইহোক, সার্ভার রিস্টার্টের মতো ক্ষেত্রে (যেমনটি হয় স্বতন্ত্র রেডিস রিস্টার্ট বা প্রক্সি রিস্টার্টে হয়) এর জন্য অ্যাকাউন্টে পুনঃপ্রচেষ্টা সহ একটি ব্যাক অ্যালগরিদম সহ হওয়া উচিত।
পুনঃসংযোগের পর যেকোনো গ্রাহককে পুনরায় সদস্যতা নিতে হবে কারণ অনুরোধ চ্যানেলের মধ্যে লিঙ্ক এবং নতুন TCP সংযোগ স্থাপন করতে হবে। যেহেতু Redis-এর PUBSUB চ্যানেলগুলি তৈরি করা হয় যখন কোনও গ্রাহক বা প্রকাশক সেগুলি অ্যাক্সেস করার চেষ্টা করে, তাই চ্যানেলটিকে "পুনরায় তৈরি করার" প্রয়োজন নেই৷
এটি কিভাবে এটি করতে হয় তা আমাদের নিয়ে আসে। উত্তরটি ব্যবহার করা ক্লায়েন্ট লাইব্রেরির উপর অত্যন্ত নির্ভরশীল এবং এটি কীভাবে সংযোগ বিচ্ছিন্ন করে। একটি আদর্শ পরিস্থিতিতে সংযোগটি স্বয়ংক্রিয়ভাবে পুনরায় চেষ্টা করার জন্য কনফিগারযোগ্য হবে এবং সীমানা পূরণ হলে চূড়ান্ত ব্যর্থতা ফিরে আসবে। এখনও পর্যন্ত আমি কয়েকটি লাইব্রেরি পরীক্ষা করেছি যে তারা কীভাবে এটি পরিচালনা করে এবং এটি নাটকীয়ভাবে পরিবর্তিত হয়। এখানে আমি একটি সাধারণ আলোচনা করব:redis-py.
প্রথম বিট ভাল খবর হল যে সংযোগ ড্রপ হয়ে গেলে redis-py পুনরায় চেষ্টা করতে দেখা যায়। দুর্ভাগ্যবশত এটি অবিলম্বে পুনরায় চেষ্টা করে, এবং এইভাবে একটি ব্যর্থতার সময় সংযোগটি নির্ভরযোগ্যভাবে পুনরুদ্ধার করা খুব দ্রুত। আরও এটি কনফিগার করার কোন উপায় নেই বলে মনে হচ্ছে। ফলস্বরূপ আপনার কোডটি অবশ্যই ব্যর্থ পুনঃসংযোগ প্রচেষ্টাকে ধরতে/শনাক্ত করতে হবে এবং পুনরায় সংযোগটি নিজেই পরিচালনা করতে হবে।
প্রথমে আমাদের কিছু স্ট্যান্ডার্ড redis-py প্রকাশ এবং গ্রাহক কোড ব্লক পরীক্ষা করা যাক:
### Publisher example code
r.publish(channel,message)
### Subscriber example code
p = r.pubsub()
p.subscribe(channel)
for item in p.listen():
# do stuff with message (item)এই মোটামুটি সোজা. যাইহোক, যখন গ্রাহকের জন্য লুপ করার সময় অবিলম্বে পুনরায় চেষ্টা করা ব্যর্থ হয় তখন আপনি একটি redis.ConnectionError ব্যতিক্রম থ্রো পাবেন। চতুর বিট হল এটি p.listen() লাইনে আইটেমের জন্য "ভিতরে" ঘটে। এইভাবে এটিকে সঠিকভাবে ধরতে আপনাকে অবশ্যই বিবৃতির জন্য সম্পূর্ণটি একটি চেষ্টায়/ব্লক ব্যতীত মুড়ে দিতে হবে। এটি সর্বোত্তমভাবে সমস্যাযুক্ত এবং অপ্রয়োজনীয় কোড জটিলতার দিকে নিয়ে যায়।
এর পরিবর্তে একটি বিকল্প রুট হল নিম্নলিখিতগুলি করা৷
৷### Publisher example code
p = r.pubsub()
p.subscribe(channel)
while True:
try:
message = p.get_message()
except redis.ConnectionError:
# Do reconnection attempts here such as sleeping and retrying
p = r.pubsub()
p.subscribe(channel)
if message:
# do something with the message
time.sleep(0.001) # be nice to the system :)এই পদ্ধতির সাহায্যে আমরা সরাসরি get_message() কল করি যা আমাদের সেই সময়ে ব্যতিক্রমটি ধরতে এবং 'p' অবজেক্টের সংযোগ পুনরায় স্থাপন করতে দেয়। ঘুমানোর সময়, যদি আদৌ, আপনার কোডের প্রয়োজনীয়তার উপর নির্ভর করে। অবশ্যই যদি আপনার গ্রাহক একটি নির্দিষ্ট সংখ্যক বার্তা পরিচালনা করার আশা করে এবং একটি ফর-লুপ আরও ভাল কাজ করে তবে এটি এখনও কাজ করবে। প্রকাশকদের জন্য কোডটি সহজ কারণ এটি সাধারণত একটি পুনরাবৃত্তিকারীতে চালানো হয় না৷
৷### Publisher example code
while True:
try:
rcvd = r.publish(channel,message)
if rcvd >0:
break
except redis.ConnectionError:
# handle reconnect attemptsএই পদ্ধতির সাহায্যে আপনার নিয়ন্ত্রণ আছে কিনা, কখন, কত ঘন ঘন পুনঃপ্রচেষ্টা করতে হবে। এটি সঠিকভাবে ব্যর্থতার ঘটনাকে স্বচ্ছভাবে পরিচালনা করার জন্য গুরুত্বপূর্ণ। মনে রাখবেন যে কোডটি সরাসরি সেন্টিনেল ব্যবহার করলে বা প্রশ্নে থাকা রেডিস সার্ভারটি পুনরায় চালু করলেও এটি একই জিনিস হবে। তাই সত্যিই সমস্ত প্রকাশনা কোড এই মৌলিক প্রক্রিয়া অনুসরণ করা উচিত.
BLPOP-এর মতো ব্লকিং লিস্ট কমান্ডের জন্য, ক্লায়েন্ট পুনঃসংযোগের ক্রম কঠোরভাবে গুরুত্বপূর্ণ নয় কারণ ডেটা বজায় থাকে। কমান্ড এক্সিকিউশনের ফলে "redis.ConnectionError" ব্যতিক্রম নিক্ষেপ করা হলে সংযোগটি পুনঃস্থাপন করার জন্য উপরে বর্ণিত পদ্ধতির চেষ্টা/ব্যতীত প্রয়োজন হবে।
redis-py-এর জন্য বিশেষ করে ObjectRocket Redis প্ল্যাটফর্মের বিরুদ্ধে এই কৌশলগুলি ব্যবহার করে 3 সেকেন্ডের একটি পুনঃপ্রচেষ্টা উইন্ডোর সাথে এটি নিশ্চিত করবে যে ট্রিগার করা ফেইলওভারের জন্য কোনও ডেটা ক্ষতির প্রত্যাশা নেই এবং একটি সূচিত ব্যর্থতার সময় নন-স্টপ প্রকাশকদের জন্য সম্ভাব্য বার্তা ক্ষতির প্রায় 1.5 সেকেন্ড যেমন উদাহরণের উল্লম্ব আকার পরিবর্তনের সময়।
যদিও কোডের উদাহরণগুলি redis-py-এর জন্য নির্দিষ্ট ছিল, মৌলিক কৌশলগুলি যে কোনও ক্লায়েন্ট কোডের সাথে ব্যবহার করা উচিত যা সার্ভার পুনরায় সংযোগগুলি পরিচালনা করতে হবে এবং PUBSUB কমান্ড বা ব্লকিং তালিকা অপারেশনগুলি ব্যবহার করে। এই জ্ঞানের সাথে সজ্জিত আপনি এখন একটি উচ্চ উপলব্ধ রেডিস পড ব্যবহার করতে এই কৌশলগুলি প্রয়োগ করতে পারেন এবং জানেন যে আপনার অ্যাপ্লিকেশনটি আপনার অপস টিমকে মাঝরাতে না জাগিয়ে ব্যর্থতাগুলি পরিচালনা করতে পারে৷
