Redis ব্যবহার করে বিতরণ লকিং

হে হাবর!

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

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

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

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

বাস্তবায়ন

অ্যালগরিদমের বর্ণনায় যাওয়ার আগে, আমরা রেডিমেড বাস্তবায়নের জন্য বেশ কয়েকটি লিঙ্ক প্রদান করি। তারা রেফারেন্স জন্য ব্যবহার করা যেতে পারে.

• রেডলক-আরবি (রুবির জন্য বাস্তবায়ন)। এছাড়াও আছে কাঁটা রেডলক-আরবি, যা বিতরণের সহজতার জন্য একটি প্যাকেজ (মণি) যোগ করে, এবং শুধুমাত্র তার জন্য নয়।
• Redlock-py (পাইথন বাস্তবায়ন)।
• Aioredlock (অ্যাসিনসিও পাইথনের জন্য বাস্তবায়ন)।
• রেডলক-পিএইচপি (PHP এর জন্য বাস্তবায়ন)।
• PHPRedisMutex (PHP এর জন্য অন্য বাস্তবায়ন)
• cheprasov/php-redis-lock (লকের জন্য পিএইচপি লাইব্রেরি)
• রেডসিঙ্ক (গো জন্য বাস্তবায়ন)।
• রিডিসন (জাভার জন্য বাস্তবায়ন)।
• Redis::DistLock (পার্লের জন্য বাস্তবায়ন)।
• রেডলক-সিপিপি (C++ এর জন্য বাস্তবায়ন)।
• রেডলক-সিএস (C#/.NET এর জন্য বাস্তবায়ন)।
• RedLock.net (C#/.NET এর জন্য বাস্তবায়ন)। অ্যাসিঙ্ক এবং লক এক্সটেনশনের জন্য সমর্থন সহ।
• স্কারলেট লক (কনফিগারযোগ্য ডেটা স্টোর সহ C# .NET এর জন্য বাস্তবায়ন)
• রেডলক 4 নেট (C# .NET এর জন্য বাস্তবায়ন)
• node-redlock (নোডজেএসের জন্য বাস্তবায়ন)। লক প্রসারিত করার জন্য সমর্থন অন্তর্ভুক্ত।

নিরাপত্তা এবং প্রাপ্যতা গ্যারান্টি

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

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

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

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

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

স্পষ্টতই, এই জাতীয় মডেলে একটি রেসের অবস্থা ঘটে:

1. ক্লায়েন্ট A মাস্টারের উপর একটি লক অর্জন করে।
2. মূল এন্ট্রি স্লেভে স্থানান্তর করার আগে মাস্টার ব্যর্থ হয়।
3. অনুসারী নেতা পদে উন্নীত হয়।
4. ক্লায়েন্ট B একই সম্পদে একটি লক অর্জন করে যা A ইতিমধ্যে লক করেছে। নিরাপত্তা লঙ্ঘন!

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

একটি একক উদাহরণ দিয়ে সঠিক বাস্তবায়ন

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

একটি লক অর্জন করতে, এটি করুন:

SET resource_name my_random_value NX PX 30000

30000 মিলিসেকেন্ডের মেয়াদ (PX বিকল্প) সহ এই কমান্ডটি কেবলমাত্র একটি কী ইনস্টল করে যদি এটি ইতিমধ্যে বিদ্যমান না থাকে (NX বিকল্প)। কী সেট করা হয়েছে "myrandomvalue" এই মানটি অবশ্যই সমস্ত ক্লায়েন্ট এবং সমস্ত লক অনুরোধ জুড়ে অনন্য হতে হবে৷
মূলত, একটি এলোমেলো মান লকটিকে নিরাপদে ছেড়ে দিতে ব্যবহৃত হয়, একটি স্ক্রিপ্টের সাথে Redis-কে বলা হয়: শুধুমাত্র চাবিটি সরিয়ে ফেলুন যদি এটি বিদ্যমান থাকে এবং এতে সংরক্ষিত মানটি ঠিক যা প্রত্যাশিত ছিল। নিম্নলিখিত লুয়া স্ক্রিপ্ট ব্যবহার করে এটি অর্জন করা হয়:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

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

এই র্যান্ডম স্ট্রিং কি হওয়া উচিত? আমি অনুমান করছি এটি /dev/urandom থেকে 20 বাইট হওয়া উচিত, তবে আপনি আপনার উদ্দেশ্যে স্ট্রিংটিকে যথেষ্ট অনন্য করার জন্য কম ব্যয়বহুল উপায় খুঁজে পেতে পারেন। উদাহরণস্বরূপ, /dev/urandom এর সাথে RC4 বীজ করা এবং তারপর এটি থেকে একটি ছদ্ম-এলোমেলো স্ট্রিম তৈরি করা ভাল হবে। একটি সহজ সমাধান মাইক্রোসেকেন্ড রেজোলিউশন এবং ক্লায়েন্ট আইডিতে ইউনিক্স সময়ের সমন্বয় জড়িত; এটি ততটা নিরাপদ নয়, তবে এটি সম্ভবত বেশিরভাগ প্রসঙ্গেই কাজ করে।

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

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

রেডলক অ্যালগরিদম

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

একটি লক অর্জন করতে, ক্লায়েন্ট নিম্নলিখিত ক্রিয়াকলাপগুলি সম্পাদন করে:

1. মিলিসেকেন্ডে বর্তমান সময় পায়।
2. সব ক্ষেত্রেই একই কী নাম এবং এলোমেলো মান ব্যবহার করে সব N দৃষ্টান্তে লক পাওয়ার চেষ্টা করে। পর্যায় 2-এ, যখন ক্লায়েন্ট প্রতি-দৃষ্টান্তের ভিত্তিতে একটি লক সেট আপ করে, ক্লায়েন্ট এটি অর্জন করতে একটি বিলম্ব ব্যবহার করে যা লকটি স্বয়ংক্রিয়ভাবে প্রকাশিত হওয়ার সময়ের তুলনায় যথেষ্ট কম। উদাহরণস্বরূপ, যদি ব্লকের সময়কাল 10 সেকেন্ড হয়, তাহলে বিলম্ব ~5-50 মিলিসেকেন্ডের মধ্যে হতে পারে। এটি এমন পরিস্থিতি দূর করে যেখানে ক্লায়েন্ট একটি ব্যর্থ রেডিস নোডে পৌঁছানোর চেষ্টা করে দীর্ঘ সময়ের জন্য অবরুদ্ধ থাকতে পারে: যদি উদাহরণটি অনুপলব্ধ হয়, তবে আমরা যত তাড়াতাড়ি সম্ভব অন্য একটি উদাহরণের সাথে সংযোগ করার চেষ্টা করি।
3. একটি লক নিতে, ক্লায়েন্ট গণনা করে কত সময় অতিবাহিত হয়েছে; এটি করার জন্য, এটি টাইমস্ট্যাম্পের প্রকৃত মান থেকে বিয়োগ করে যা ধাপ 1 এ প্রাপ্ত হয়েছিল। যদি এবং শুধুমাত্র যদি ক্লায়েন্ট বেশিরভাগ ক্ষেত্রে (কমপক্ষে 3) লকটি পেতে সক্ষম হয় এবং এতে মোট সময় লেগেছিল লক প্রাপ্ত, লক সময়কালের চেয়ে কম, লকটি প্রাপ্ত হয়েছে বলে মনে করা হয়।
4. যদি একটি লক অধিগ্রহণ করা হয়, তাহলে লকের সময়কালটিকে মূল লক সময়কাল হিসাবে ধরা হয় ধাপ 3 এ গণনা করা অতিবাহিত সময়।
5. যদি ক্লায়েন্ট কোনো কারণে লক পেতে ব্যর্থ হয় (হয় এটি N/2+1 দৃষ্টান্তগুলি লক করতে অক্ষম ছিল, বা লকের সময়কাল নেতিবাচক ছিল), তাহলে এটি সমস্ত দৃষ্টান্তগুলি আনলক করার চেষ্টা করবে (এমনকি যেগুলি ভেবেছিল যে এটি ব্লক করতে পারবে না) )

অ্যালগরিদম কি অ্যাসিঙ্ক্রোনাস?

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

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

নিম্নলিখিত আকর্ষণীয় নিবন্ধটি এমন সিস্টেমগুলি সম্পর্কে আরও বলে যেগুলির জন্য সময়ের ব্যবধানের সমন্বয় প্রয়োজন: ইজারা: বিতরণ করা ফাইল ক্যাশে সামঞ্জস্যের জন্য একটি দক্ষ ত্রুটি-সহনশীল প্রক্রিয়া.

ব্যর্থতার উপর পুনরায় চেষ্টা করুন

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

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

তালা ছেড়ে দাও

একটি লক রিলিজ করা একটি সাধারণ অপারেশন যার জন্য ক্লায়েন্ট সফলভাবে একটি নির্দিষ্ট দৃষ্টান্ত লক করেছে কিনা তা বিবেচনা না করেই সমস্ত দৃষ্টান্ত আনলক করা প্রয়োজন৷

নিরাপত্তা বিবেচনা

অ্যালগরিদম নিরাপদ? আসুন কল্পনা করার চেষ্টা করি বিভিন্ন পরিস্থিতিতে কী ঘটে।

শুরু করার জন্য, ধরা যাক যে ক্লায়েন্ট বেশিরভাগ ক্ষেত্রে একটি লক পেতে সক্ষম হয়েছিল। প্রতিটি উদাহরণে সকলের জন্য একই জীবনকাল সহ একটি কী থাকবে। যাইহোক, এই কীগুলির প্রতিটি আলাদা সময়ে ইনস্টল করা হয়েছিল, তাই সেগুলি বিভিন্ন সময়ে মেয়াদ শেষ হবে। তবে, যদি প্রথম কীটি এমন সময়ে ইনস্টল করা হয় যেটি T1 (প্রথম সার্ভারের সাথে যোগাযোগ করার আগে আমরা যে সময়টি বেছে নিই) এর চেয়ে খারাপ নয় এবং শেষ কীটি এমন সময়ে ইনস্টল করা হয়েছিল যেটি T2 এর চেয়ে খারাপ নয় (যে সময়ে প্রতিক্রিয়াটি প্রাপ্ত হয়েছিল) শেষ সার্ভার থেকে), তাহলে আমরা নিশ্চিত যে সেটের প্রথম কী যেটির মেয়াদ শেষ হবে তা অন্তত বেঁচে থাকবে MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. অন্যান্য সমস্ত কীগুলির মেয়াদ পরে শেষ হবে, তাই আমরা নিশ্চিত হতে পারি যে সমস্ত কী একই সাথে অন্তত এই সময়ের জন্য বৈধ হবে।

বেশির ভাগ কী বৈধ থাকার সময়, অন্য ক্লায়েন্ট লকটি অর্জন করতে সক্ষম হবে না, যেহেতু N/2+1 কী ইতিমধ্যেই বিদ্যমান থাকলে N/2+1 SET NX অপারেশন সফল হতে পারে না। অতএব, একবার একটি লক অধিগ্রহণ করা হলে, একই মুহূর্তে এটি পুনরায় অর্জন করা অসম্ভব (এটি পারস্পরিক বর্জন সম্পত্তি লঙ্ঘন করবে)।
যাইহোক, আমরা নিশ্চিত করতে চাই যে একাধিক ক্লায়েন্ট একই সময়ে একটি লক অর্জন করার চেষ্টা করছে তারা একই সময়ে সফল হতে পারে না।

যদি ক্লায়েন্ট বেশিরভাগ দৃষ্টান্তগুলিকে সর্বাধিক লক সময়কালের প্রায় বা তার বেশি সময়ের জন্য লক করে থাকে, তবে এটি লকটিকে অবৈধ বলে বিবেচনা করবে এবং উদাহরণগুলি আনলক করবে। অতএব, আমাদের শুধুমাত্র সেই ক্ষেত্রেই বিবেচনা করতে হবে যেখানে ক্লায়েন্ট মেয়াদ শেষ হওয়ার তারিখের চেয়ে কম সময়ে বেশিরভাগ দৃষ্টান্ত ব্লক করতে পেরেছে। এমতাবস্থায় উপরোক্ত যুক্তি প্রসঙ্গে ড MIN_VALIDITY কোন ক্লায়েন্ট লক পুনরায় অর্জন করতে সক্ষম হবে না. অতএব, অনেক ক্লায়েন্ট একই সময়ে N/2+1 দৃষ্টান্ত লক করতে সক্ষম হবে (যা পর্যায় 2 এর শেষে শেষ হয়) শুধুমাত্র তখনই যখন সংখ্যাগরিষ্ঠ লক করার সময়টি TTL সময়ের চেয়ে বেশি হয়, যা লকটিকে অবৈধ করে।

আপনি কি নিরাপত্তার একটি আনুষ্ঠানিক প্রমাণ প্রদান করতে পারেন, বিদ্যমান অনুরূপ অ্যালগরিদমগুলি নির্দেশ করতে পারেন, বা উপরে একটি বাগ খুঁজে পেতে পারেন?

অ্যাক্সেসযোগ্যতা বিবেচনা

সিস্টেমের প্রাপ্যতা তিনটি প্রধান বৈশিষ্ট্যের উপর নির্ভর করে:

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

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

নীতিগতভাবে, অসীম সংলগ্ন নেটওয়ার্ক সেগমেন্ট দেওয়া হলে, একটি সিস্টেম অসীম সময়ের জন্য অনুপলব্ধ থাকতে পারে।

কর্মক্ষমতা, ব্যর্থতা এবং fsync

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

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

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

আপনি যদি ডেটা এহেড (AOF) সক্ষম করেন তবে পরিস্থিতির কিছুটা উন্নতি হবে। উদাহরণস্বরূপ, আপনি SHUTDOWN কমান্ড পাঠিয়ে এবং এটি পুনরায় চালু করে একটি সার্ভার প্রচার করতে পারেন। যেহেতু Redis-এ মেয়াদোত্তীর্ণ ক্রিয়াকলাপগুলি শব্দার্থগতভাবে এমনভাবে প্রয়োগ করা হয় যে সার্ভার বন্ধ থাকা সত্ত্বেও সময় প্রবাহিত হয়, আমাদের সমস্ত প্রয়োজনীয়তা ঠিক আছে। যতক্ষণ না একটি স্বাভাবিক শাটডাউন নিশ্চিত করা হয় ততক্ষণ এটি স্বাভাবিক। বিদ্যুৎ বিভ্রাটের ক্ষেত্রে কী করবেন? যদি রেডিস ডিফল্টরূপে কনফিগার করা থাকে, প্রতি সেকেন্ডে ডিস্কে fsync সিঙ্ক্রোনাইজ করে, তাহলে এটা সম্ভব যে পুনরায় চালু করার পরে আমাদের কী থাকবে না। তাত্ত্বিকভাবে, আমরা যদি কোনো দৃষ্টান্ত পুনরায় চালু করার সময় লক নিরাপত্তার নিশ্চয়তা দিতে চাই, তাহলে আমাদের সক্ষম করা উচিত fsync=always দীর্ঘমেয়াদী ডেটা স্টোরেজের জন্য সেটিংসে। এটি CP সিস্টেমের স্তরে কার্যক্ষমতা সম্পূর্ণভাবে ধ্বংস করবে যা ঐতিহ্যগতভাবে নিরাপদভাবে বিতরণ করা লকগুলি প্রয়োগ করতে ব্যবহৃত হয়।

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

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

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

আমরা অ্যালগরিদমের প্রাপ্যতা বাড়াই: আমরা ব্লকিং প্রসারিত করি

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

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

সত্য, প্রযুক্তিগতভাবে অ্যালগরিদম পরিবর্তন হয় না, তাই লকগুলি অর্জনের জন্য বারবার প্রচেষ্টার সর্বাধিক সংখ্যা সীমিত হতে হবে, অন্যথায় অ্যাক্সেসযোগ্যতার বৈশিষ্ট্যগুলি লঙ্ঘন করা হবে৷

উত্স: www.habr.com