Distributed lock: কীভাবে বানাবেন ও কেন কঠিন

কয়েকটি server যখন একটি resource ভাগ করে, তখন মাঝে মাঝে mutual exclusion লাগে: একবারে একজনই কাজ করবে, যেমন একটি worker payout চালাবে বা একটি process cache entry refresh করবে। Distributed lock মেশিন জুড়ে সেটি দেয়।

Redis-এর মূল রেসিপি

নিতে: SET lock:payout <unique-id> NX PX 30000

• NX: key না থাকলেই সেট করো, তাই শুধু একজন জেতে।
• PX 30000: ৩০ সেকেন্ড পর মেয়াদ শেষ, যাতে ভেঙে পড়া holder সবাইকে চিরকাল আটকাতে না পারে।
• <unique-id>: holder-কে চেনানো random মান।

ছাড়তে: key-র মান এখনও আপনার id থাকলেই মুছুন, ছোট Lua script-এ atomically। নইলে আপনার মেয়াদ শেষের পর অন্য কারও নেওয়া lock মুছে ফেলতে পারেন।

কেন যতটা মনে হয় তার চেয়ে কঠিন

• Expiry বনাম লম্বা কাজ। Lock-এর সময়ের চেয়ে কাজ বেশি লাগলে আপনি ভাবছেন lock আপনার, কিন্তু মেয়াদ শেষ, আর দ্বিতীয় worker ঢুকে পড়ে। কাজের সময় lock নবায়ন করুন বা critical section ছোট রাখুন।
• Pause। Process থেমে যেতে পারে (garbage collection, ধীর disk, VM pause), lock-এর মেয়াদ শেষের পর জেগে তবুও লিখে ফেলে।
• Failover। Lock replica-তে যাওয়ার আগে Redis primary মরলে নতুন primary তা জানে না।
• Clock ও network ধারণা। Distributed সময় অনির্ভরযোগ্য।

Redis Redlock প্রস্তাব করেছিল (কয়েকটি স্বাধীন Redis node-এ locking)। Distributed system গবেষকরা বলেছেন, সঠিকতা সত্যিই lock-এর ওপর নির্ভর করলে এটি নিরাপদ নয়, আর এর লেখক দ্বিমত করেছেন। বাস্তব সিদ্ধান্ত: Redis lock কার্যক্ষমতার (ডুপ্লিকেট কাজ এড়ানো) জন্য ব্যবহার করুন, সঠিকতার জন্য নয়।

নিরাপদ ডিজাইন: fencing token

প্রতিটি lock প্রদানে একটি বাড়তে থাকা সংখ্যা যায়। সুরক্ষিত resource (database, storage) সর্বশেষ দেখা সংখ্যার চেয়ে পুরোনো সংখ্যাযুক্ত write প্রত্যাখ্যান করে, তাই পুরোনো holder ক্ষতি করতে পারে না। এর জন্য token যাচাই করে এমন store লাগে।

Lock-এর বিকল্প

• Database-এ unique constraint বা conditional update (UPDATE ... WHERE version = ?)।
• Idempotency key, যাতে পুনরাবৃত্ত কাজ ক্ষতিহীন হয়।
• Queue যেখানে প্রতিটি key একজন consumer সামলায়।
• etcd বা ZooKeeper-এর lock, যা consensus-নির্ভর এবং শক্ত গ্যারান্টি দেয়।

মূল কথা: Lock কম ব্যবহার করুন, সবসময় expiry ও অনন্য owner মান দিন, আর যা ঠিক হতেই হবে তার পেছনে fencing token বা database constraint রাখুন।

---

System Design সিরিজ, পর্ব ২ (building block): 10 নম্বর (মোট 14)। আগের লেখা: Leader election: distributed সিস্টেম কীভাবে একজন নেতা বাছে.