Coordination — distributed lock, lease আর fencing token

১ · কেন coordination — একজনই, একবারই, একই তথ্য

একটি কাল্পনিক ride-sharing অ্যাপের কথা ভাবুন। প্রতি রাতে চালকদের দিনের আয় হিসাব করে তাঁদের wallet-এ টাকা পাঠানোর একটি job চলে। একটি মেশিন বিকল হলেও যাতে টাকা যায়, তাই তিনটি মেশিনে তিনটি scheduler. এখন উল্টো বিপদ: তিনজনই job ছাড়লে প্রত্যেক চালক তিনগুণ টাকা পাবেন। দরকার ঠিক একজন কাজটি করবে, আর সে মরলে আরেকজন দায়িত্ব নেবে। পর্ব ৩৭ — Background job, scheduler আর workflow engine-এ এই সমস্যা প্রথম দেখেছিলেন; এই পর্বে তার পূর্ণ তত্ত্ব।

এ ধরনের সমঝোতাকে বলে coordination: কয়েকটি স্বাধীন মেশিনকে একটি বিষয়ে একমত রাখা। চারটি চাহিদা বারবার আসে:

• একজন নেতা: একটি scheduler, একটি database-এর primary (পর্ব ২২ — Replication), একটি partition-এর মালিক। এর নাম leader election.
• একটি সম্পদে একজনের অধিকার: একটি ফাইল একজনই লিখবে, একটি বাইরের API-কে একসাথে একজনই ডাকবে। এটি mutual exclusion, আর অনেক মেশিন জুড়ে তার যন্ত্র distributed lock.
• সবার কাছে একই config: কোন feature চালু, কোন shard কোন সার্ভারে (পর্ব ২৩ — Partitioning আর sharding) — বদল হলে সবাইকে জানানো।
• কে কোথায় আছে: কোন সার্ভিসের কোন instance এখন জীবিত, কোন ঠিকানায় — service discovery. এর পূর্ণ নকশা পর্ব ৪৭ — Monolith বনাম microservices-এ; কে বেঁচে আছে তা জানার কৌশল পর্ব ৪৪ — Membership আর failure detection-এ।

একটি মেশিনে সহজ, অনেক মেশিনে কঠিন — কেন

একটি মেশিনের ভেতরে lock পুরোনো, পরিচিত জিনিস: CPU-র atomic instruction দিয়ে বানানো mutex (OS কোর্সের Atomic instruction আর spinlock আর Mutex আর semaphore পর্ব), আর একে অপরের lock-এর অপেক্ষায় আটকে যাওয়ার বিপদ deadlock (Deadlock পর্ব)। সেখানে তিনটি সুবিধা আছে, যা অনেক মেশিনে নেই:

1. একটি shared memory: lock-এর অবস্থা এক জায়গায়, সবাই একই মান দেখে। অনেক মেশিনে অবস্থাটি network-এর ওপাশে, আর বার্তা দেরিতে আসে, হারায়।
2. মৃত্যুর নিশ্চিত খবর: একটি process মরলে OS জানে, তার lock ছেড়ে দিতে পারে। অনেক মেশিনে উত্তর না এলে বোঝার উপায় নেই — মেশিন মৃত, ধীর, না network কাটা (পর্ব ৩৮ — Distributed system-এর কঠিন সত্য)।
3. একটি ঘড়ি: “৫ সেকেন্ড পরে” সবার কাছে একই। অনেক মেশিনে প্রত্যেকের ঘড়ি একটু আলাদা গতিতে চলে, আর কখনো লাফ দেয় (পর্ব ৩৯ — সময় আর ক্রম)।

এই তিনটি অভাবই পুরো পর্বের সব জটিলতার উৎস।

প্রথম প্রশ্ন: lock-টি কীসের জন্য — efficiency না correctness?

Martin Kleppmann ২০১৬ সালের একটি প্রকাশ্য লেখায় (“How to do distributed locking”) একটি সহজ কিন্তু শক্তিশালী ভাগের কথা বলেন, যা আজ প্রায় সব আলোচনার শুরু:

উত্তর না জেনে lock বাছা মানে হয় অকারণে ভারী ব্যবস্থা, নয়তো অনিরাপদ হালকা ব্যবস্থা।

২ · Lock-এর মেয়াদ কেন — lease, TTL আর keep-alive

সবচেয়ে সরল distributed lock: database-এর একটি সারি locks(name, holder). A লিখল “nightly-payout-এর ধারক A”, কাজ শেষে মুছে দেবে। এখন A-র মেশিন কাজের মাঝে বন্ধ হয়ে গেল। সারিটি কে মুছবে? A আর নেই; অন্যরা জানে না A মৃত না ধীর। Lock চিরকাল ধরা থাকল, রাতের পেমেন্ট আর কখনো চলবে না — যতক্ষণ না কেউ হাতে মোছেন।

সমাধান: lock-কে চিরস্থায়ী না করে একটি মেয়াদ দেওয়া। এটিই lease — “এই অধিকার আগামী ১০ সেকেন্ডের জন্য এই client-এর” ধরনের প্রতিশ্রুতি। মেয়াদকে বলে TTL. ধারক বেঁচে থাকলে মেয়াদ ফুরানোর আগেই নবায়ন করে — keep-alive বা heartbeat; মরে গেলে নবায়ন থামে, lease নিজে ফুরায়, আর অন্য কেউ lock নিতে পারে। কেউ কাউকে “মৃত” ঘোষণা করে না — শুধু সময় পেরোয়।

Lease-এর তিনটি নিয়ম

1. নবায়ন মেয়াদের অনেক আগে: প্রচলিত অভ্যাস প্রতি TTL/৩-এ একবার, যাতে একটি-দুটি নবায়ন হারালেও lease না ফুরায়।
2. ধারক নিজেকে আগেভাগে থামায়: সে মেয়াদ গোনে অনুরোধ পাঠানোর আগের মুহূর্ত থেকে, সেবা গোনে অনুমতি দেওয়ার মুহূর্ত থেকে; তাই ধারকের হিসাবে lease আগে শেষ হয় — নিরাপদ দিকে ভুল (অংশ ৮)।
3. মেয়াদ শেষে কাজ থামানো: নবায়ন ব্যর্থ হলে বা মেয়াদ ফুরালে ধারক lock-এর অধীন সব কাজ বন্ধ করবে।

তৃতীয় নিয়মটি শুনতে সহজ, কিন্তু এর ফাঁকেই এই পর্বের সবচেয়ে বড় বিপদ লুকানো: ধারক যদি এমনভাবে থেমে যায় যে সে নিজেই জানে না সময় পেরিয়েছে? সেই প্রশ্নে অংশ ৬-এ ফিরব। তার আগে দেখি lease কে দেয়।

৩ · Coordination service — ZooKeeper, etcd আর Chubby

Lock-এর অবস্থা যে মেশিনে থাকে, সেটি বিকল হলে সব lock-ও বিকল — নতুন একটি single point of failure. তাই lock-এর তথ্য কয়েকটি মেশিনে কপি করতে হয়, এমনভাবে যে কপিগুলো কখনো দুটি ভিন্ন উত্তর দেবে না। এটিই consensus-এর কাজ: সাধারণত ৩ বা ৫টি node, যার বেশিরভাগ (quorum) সচল থাকলে সিদ্ধান্ত চলে। ৩টিতে একটি, ৫টিতে দুটি node বিকল হলেও সেবা চলে। Raft কীভাবে leader বাছে আর log মেলায়, তা পর্ব ৪২ — Consensus-এ; এখানে আমরা সেই যন্ত্রের ওপর বানানো সেবা দেখব — coordination service.

এই সেবাগুলোর লেখা linearizable (পর্ব ৪০ — CAP, PACELC আর consistency model): একটি লেখা সফল হলে পরের সবাই সেটি দেখবে, যেন একটিই কপি। Lock-এর জন্য এটি অপরিহার্য — দুজন একসাথে “lock খালি” দেখলে সব শেষ। তিনটি প্রভাবশালী নকশা:

পাঁচটি মূল ধারণা

নাম আলাদা, কিন্তু তিনটি সিস্টেমের ধারণাগুলো প্রায় এক। ZooKeeper-এর ভাষায় শুরু করি, তারপর etcd-এর সমতুল্য।

• Znode আর key: ZooKeeper-এর ডেটা ফাইল সিস্টেমের মতো একটি গাছ — /lock/payout; প্রতিটি ঘর একটি znode, তাতে অল্প ডেটা (ডিফল্ট সর্বোচ্চ প্রায় ১ MB — সংস্করণভেদে যাচাই করুন)। etcd-এ সমতল key space, prefix দিয়ে একসাথে পড়া যায়।
• Session আর ephemeral node: প্রতিটি ZooKeeper client-এর একটি session, যা client নিয়মিত heartbeat দিয়ে জীবিত রাখে। Session-এর মেয়াদ (session timeout) পেরোলে সেই client-এর বানানো সব ephemeral node সেবা নিজেই মুছে দেয়। অর্থাৎ ephemeral node হলো lease-এ বাঁধা তথ্য। etcd-এ একই কাজ করে lease: LeaseGrant দিয়ে TTL-সহ একটি lease, key-কে তার সাথে জোড়া, আর LeaseKeepAlive দিয়ে নবায়ন; lease ফুরালে জোড়া সব key মুছে যায়।
• Sequential node: ZooKeeper-এ “sequential” পতাকা দিয়ে node বানালে নামের শেষে সেবা একটি বাড়তে থাকা ১০ অঙ্কের নম্বর বসায় — lock-0000000007. এই নম্বর বলে কে আগে এসেছে। etcd-এ প্রতিটি key-এর create_revision একই কাজ করে।
• Watch: client বলতে পারে “এই node বদলালে বা মুছলে আমাকে জানানো হোক”। ZooKeeper-এর ক্লাসিক watch একবারের — একবার জানিয়ে শেষ, আবার চাইতে হয় (৩.৬ সংস্করণ থেকে স্থায়ী watch-ও আছে বলে documentation-এ বলা)। etcd-এ watch একটি চলমান stream, আর নির্দিষ্ট revision থেকে শুরু করা যায়, তাই মাঝের বদল হারায় না।
• শর্তসহ লেখা: ZooKeeper-এ setData(path, data, version) শুধু তখনই সফল, যখন node-এর version এখনো সেটি। etcd-এ পূর্ণ transaction: If(compare) Then(ops) Else(ops), যেখানে compare হতে পারে একটি key-এর mod_revision, create_revision, version বা মান — একটি compare-and-set.

কী রাখবেন, কী রাখবেন না

প্রতিটি লেখা leader হয়ে বেশিরভাগ node-এ টেকসইভাবে লেখা হয়, তাই লেখার গতি সীমিত। এই সেবা ছোট, অতি গুরুত্বপূর্ণ তথ্যের জন্য — কে leader, কোন lock কার, কোন partition কোথায়, কোন config চালু; ব্যবহারকারীর ডেটা বা সেকেন্ডে লাখো লেখা এখানে নয়। Kafka বহু বছর ZooKeeper-এ metadata রাখত, কিন্তু ২০২৫ সালের ৪.০ সংস্করণ থেকে নিজের Raft-ভিত্তিক KRaft ব্যবহার করে (লেখার সময়ের তথ্য)।

নিচের ছবিটি এই পর্বের মানচিত্র: ওপরে দুটি client, মাঝে তিন node-এর coordination service, নিচে সেই storage যাকে lock রক্ষা করে — আর storage নিজেই token যাচাই করছে।

৪ · Lock-এর দুটি রেসিপি — ephemeral-sequential সারি আর lease + revision

রেসিপি ১ · ZooKeeper-এর lock সারি

ZooKeeper-এর documentation-এর “Recipes” অংশে lock-এর একটি প্রচলিত পদ্ধতি আছে। ভাবুন ব্যাংকের কাউন্টারে টোকেন-যন্ত্র: প্রত্যেকে একটি ক্রমিক টোকেন নেন, সবচেয়ে ছোট টোকেন যাঁর হাতে, তিনি কাউন্টারে। ধাপগুলো:

1. /lock-এর নিচে ephemeral আর sequential একটি node বানানো — যেমন /lock/lock-0000000003. Ephemeral, যাতে client মরলে node নিজে মোছে; sequential, যাতে আগমনের ক্রম থাকে।
2. /lock-এর সব child পড়া (watch ছাড়া)।
3. নিজের নম্বর সবচেয়ে ছোট হলে lock আপনার।
4. নইলে ঠিক আগের নম্বরের node-টির ওপর watch রাখা — শুধু সেটির।
5. Watch বাজলে সরাসরি lock ধরে নেওয়া নয় — আবার ধাপ ২. কারণ আগের জন হয়তো lock-ধারী ছিলেন না, অপেক্ষার মধ্যেই মরে গিয়েছিলেন।

ছাড়ার সময় ধারক নিজের node মোছেন; মরে গেলে session-এর মেয়াদ শেষে সেবা মুছে দেয়। দুই ক্ষেত্রেই পরের জনের watch বাজে।

কেন শুধু আগের জনকে? সবাই /lock-এর child-তালিকায় watch রাখলে প্রতিটি মোছায় অপেক্ষারত সবাই জাগবে, অথচ lock পাবে একজন। এটি thundering herd — ZooKeeper-এর documentation-এ “herd effect”. N জন client-এর পুরো সারি শেষ হতে মোট জাগানো (N−১) + (N−২) + … + ১ = N(N−১)/২, আর রেসিপিতে মাত্র N−১. নিচের simulator-এ পাঁচজন client, seed স্থির; মাঝের একজন অপেক্ষার সময়ে মরে যায়।

// ZooKeeper-style lock queue: ephemeral-sequential nodes, each waiter watches only its predecessor.
function mulberry32(a) {
  return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const rnd = mulberry32(43), arrive = ["C1", "C2", "C3", "C4", "C5"];
for (let i = arrive.length - 1; i > 0; i--) {            // seeded arrival order
  const j = Math.floor(rnd() * (i + 1)); [arrive[i], arrive[j]] = [arrive[j], arrive[i]];
}
const q = arrive.map((c, i) => ({ c, name: "lock-" + String(i).padStart(10, "0") }));
const show = () => q.forEach((n, i) => console.log("  " + n.c + " " + n.name + "  " +
  (i === 0 ? "HOLDS the lock" : "watches " + q[i - 1].name)));
console.log("children of /lock (sorted):"); show();
let recipe = 0, naive = 0;
function remove(i, why) {                              // a node is deleted (release or session expiry)
  const gone = q.splice(i, 1)[0];
  naive += q.length;                                   // naive: everyone watching /lock wakes up
  console.log(`\n${gone.c} ${why}: ${gone.name} deleted`);
  if (i < q.length) {                                  // recipe: only the next node's watch fires
    recipe++;
    console.log(`  notify ${q[i].c} only -> re-reads children -> ` +
      (i === 0 ? "it is lowest: HOLDS the lock" : "not lowest: now watches " + q[i - 1].name));
  }
}
remove(2, "session expired while waiting");            // a waiter in the middle crashes
while (q.length) remove(0, "releases");
const tri = n => n * (n - 1) / 2;
console.log(`\nnotifications for these 5 clients: recipe ${recipe}, naive (all watch /lock children) ${naive}`);
for (const n of [100, 1000]) console.log(`${n} clients, no crash: recipe ${n - 1}, naive ${tri(n)}`);

children of /lock (sorted):
  C3 lock-0000000000  HOLDS the lock
  C1 lock-0000000001  watches lock-0000000000
  C4 lock-0000000002  watches lock-0000000001
  C2 lock-0000000003  watches lock-0000000002
  C5 lock-0000000004  watches lock-0000000003

C4 session expired while waiting: lock-0000000002 deleted
  notify C2 only -> re-reads children -> not lowest: now watches lock-0000000001

C3 releases: lock-0000000000 deleted
  notify C1 only -> re-reads children -> it is lowest: HOLDS the lock

C1 releases: lock-0000000001 deleted
  notify C2 only -> re-reads children -> it is lowest: HOLDS the lock

C2 releases: lock-0000000003 deleted
  notify C5 only -> re-reads children -> it is lowest: HOLDS the lock

C5 releases: lock-0000000004 deleted

notifications for these 5 clients: recipe 4, naive (all watch /lock children) 10
100 clients, no crash: recipe 99, naive 4950
1000 clients, no crash: recipe 999, naive 499500

রেসিপি ২ · etcd-ধাঁচের lease + revision

etcd-এর Go client-এর concurrency package-এ একটি lock আছে, যার ধাঁচ একই, শুধু ভাষা আলাদা। Ephemeral-এর জায়গায় lease, sequential নম্বরের জায়গায় create_revision:

lease = LeaseGrant(ttl = 10s)                 // keep it alive every ~3 s
my    = "/lock/payout/" + lease.id
Txn( If:   CreateRevision(my) == 0            // my key does not exist yet
     Then: Put(my, "worker-A", lease)
     Else: Get(my) )
rev   = CreateRevision(my)                     // e.g. 9071: a global, ever-growing number
loop:
  older = keys under "/lock/payout/" with CreateRevision < rev
  if older is empty: I HOLD THE LOCK; fencing token = rev
  else: Watch(the one with the largest CreateRevision < rev) until it is deleted
release: Delete(my)  or  LeaseRevoke(lease)   // crash: the lease expires by itself

এখানেও প্রত্যেকে শুধু ঠিক আগের key দেখে — herd নেই। আর একটি বাড়তি উপহার: create_revision পুরো store-এ একটিই বাড়তে থাকা নম্বর, তাই পরের ধারকের নম্বর সবসময় বড়। অংশ ৬-এ দেখবেন, এই নম্বরটিই fencing token হিসেবে কাজে লাগে। etcd-এর command-line টুল etcdctl lock আর ZooKeeper-এর Curator library-র মতো সহায়ক এই রেসিপিগুলো তৈরি অবস্থায় দেয়; নিজে বানানোর আগে সেগুলো দেখুন।

৫ · Leader election — একই রেসিপি, অন্য নাম

Leader election আসলে একটি দীর্ঘ সময় ধরে রাখা lock, যার ধারক নিজের পরিচয় সবাইকে জানায়। ZooKeeper-এ প্রত্যেক প্রার্থী /election-এর নিচে ephemeral-sequential node বানায়; সবচেয়ে ছোট নম্বর leader, আর নিজের node-এ ঠিকানা লেখে। বাকিরা ঠিক আগের node দেখে — অংশ ৪-এর শিকল। etcd-এর concurrency package-এ এর নাম Election (Campaign, Proclaim, Resign, Observe). Kubernetes-এর controller-গুলো একই কাজ করে coordination.k8s.io-এর Lease object দিয়ে, যা শেষে etcd-এ লেখা হয়; লেখার সময়ে kube-controller-manager-এর ডিফল্ট lease প্রায় ১৫ সেকেন্ড (সংস্করণভেদে যাচাই করুন)।

সুস্থ অবস্থায় সব সরল। কঠিন অংশ হলো leader আর ensemble-এর মাঝের network কেটে যাওয়া। তখন দুই পক্ষ দুটি আলাদা ঘড়িতে দুটি আলাদা সিদ্ধান্ত নেয় — ensemble ঠিক করে session শেষ কি না, leader ঠিক করে নিজেকে থামাবে কি না। নিচের stepper-এ তিনটি scheduler, session timeout ৬ সেকেন্ড।

৬ · আসল বিপদ — থেমে থাকা ধারক আর fencing token

এ পর্যন্ত ধরে নিয়েছি, ধারক নিজের lease-এর হিসাব রাখতে পারে। কিন্তু একটি process কোনো সতর্কতা ছাড়াই কয়েক সেকেন্ড, এমনকি কয়েক মিনিট থেমে যেতে পারে — পর্ব ৩৮-এ এর নাম process pause:

• Garbage collection: “stop-the-world” ধাপে সব thread থামে; বড় heap-এ কয়েক সেকেন্ড পর্যন্ত।
• Virtual machine-এর বিরতি, swap আর ধীর disk: hypervisor VM থামাতে পারে, page আনতে বা I/O-তে process আটকে থাকে।
• Network-এ দেরি: process থামেনি, কিন্তু লেখার packet পৌঁছাল lease শেষ হওয়ার পরে — ফল একই।

স্বাভাবিক প্রতিক্রিয়া: “লেখার ঠিক আগে যাচাই করব lock এখনো আমার কি না।” কাজ হয় না, কারণ বিরতি যাচাই আর লেখার মাঝেও আসতে পারে:

if lease.stillMine():          // true at t = 9.9 s
    # ---- GC pause of 6 s happens exactly here ----
    storage.write(newValue)    // arrives at t = 15.9 s; lease ended at t = 10 s

যাচাই আর কাজের মাঝের এই ফাঁক একটি race condition; আর ধারক নিজের ভেতর থেকে কখনো এটি বন্ধ করতে পারবে না, কারণ থেমে থাকার সময় সে নিজে কিছুই চালাতে পারে না। নিচের simulator-এ একটি দোকানের স্টক ১০টি। A ১টি বিক্রি করবে, B ২টি; সঠিক শেষ ফল ৭. Lease ১০ সেকেন্ড; A lock নিয়ে স্টক পড়েই GC-তে থামে, t = ২ থেকে ১৫ পর্যন্ত। প্রথমবার storage কিছুই যাচাই করে না, দ্বিতীয়বার fencing token যাচাই করে।

// Lease lock without and with fencing tokens. A pauses past its lease; B takes the lock.
function run(fencing, bWriteAt) {
  const TTL = 10, lock = { until: 0, token: 32 };     // lease 10 s; last token given was 32
  const store = { stock: 10, maxToken: 0 };           // the storage: 10 items in stock
  const out = [], mine = {};
  const acquire = (c, t) => {                         // lock service: free or lease expired?
    if (t < lock.until) return false;
    lock.until = t + TTL; mine[c] = ++lock.token;
    out.push(`t=${t}  ${c} gets lock, token ${mine[c]}, lease until t=${lock.until}`); return true;
  };
  const read = (c, t) => { mine[c + "read"] = store.stock; out.push(`t=${t}  ${c} reads stock=${store.stock}`); };
  const write = (c, t, sell) => {                     // storage checks the token (if fencing)
    const v = mine[c + "read"] - sell, tok = mine[c];
    if (fencing && tok < store.maxToken) {
      out.push(`t=${t}  ${c} writes stock=${v} with token ${tok} -> REJECTED (seen ${store.maxToken})`);
      return false;
    }
    store.stock = v; store.maxToken = Math.max(store.maxToken, tok);
    out.push(`t=${t}  ${c} writes stock=${v} with token ${tok} -> ok`); return true;
  };
  const ev = [[0, () => acquire("A", 0)], [1, () => { read("A", 1); out.push("      A: GC pause from t=2 to t=15"); }],
    [11, () => acquire("B", 11)], [12, () => read("B", 12)],
    [bWriteAt, () => { write("B", bWriteAt, 2); lock.until = 0; out.push(`t=${bWriteAt}  B releases`); }],
    [15, () => { if (!write("A", 15, 1)) { acquire("A", 16); read("A", 16); write("A", 17, 1); } }]];
  ev.sort((x, y) => x[0] - y[0]).forEach(e => e[1]());
  console.log((fencing ? "WITH fencing" : "NO fencing") + ` (B writes at t=${bWriteAt})`);
  console.log(out.join("\n") + `\nfinal stock=${store.stock} (correct: 10 - 1 - 2 = 7)\n`);
}
run(false, 13);
run(true, 13);

NO fencing (B writes at t=13)
t=0  A gets lock, token 33, lease until t=10
t=1  A reads stock=10
      A: GC pause from t=2 to t=15
t=11  B gets lock, token 34, lease until t=21
t=12  B reads stock=10
t=13  B writes stock=8 with token 34 -> ok
t=13  B releases
t=15  A writes stock=9 with token 33 -> ok
final stock=9 (correct: 10 - 1 - 2 = 7)

WITH fencing (B writes at t=13)
t=0  A gets lock, token 33, lease until t=10
t=1  A reads stock=10
      A: GC pause from t=2 to t=15
t=11  B gets lock, token 34, lease until t=21
t=12  B reads stock=10
t=13  B writes stock=8 with token 34 -> ok
t=13  B releases
t=15  A writes stock=9 with token 33 -> REJECTED (seen 34)
t=16  A gets lock, token 35, lease until t=26
t=16  A reads stock=8
t=17  A writes stock=7 with token 35 -> ok
final stock=7 (correct: 10 - 1 - 2 = 7)

নিচের stepper-এ একই ঘটনা ধীরে ধীরে, সংখ্যাগুলো simulator-এর সাথে মেলানো। Token ৩৩ আর ৩৪ নম্বর দুটি Kleppmann-এর ২০১৬ সালের লেখার বিখ্যাত ছবির মতো রাখা হয়েছে।

Fencing token-এর তিনটি শর্ত

1. একঘেয়েভাবে বাড়ে: পরের ধারকের নম্বর সবসময় বড় — ZooKeeper-এ sequential নম্বর বা zxid, etcd-এ create_revision, Raft-এ term, Chubby-তে “sequencer”. এলোমেলো UUID-তে “বড়-ছোট” নেই।
2. Storage নিজে যাচাই করে: সর্বোচ্চ দেখা token মনে রাখা আর যাচাই-লেখা একসাথে, পারমাণবিকভাবে। Database-এ এটি একটি শর্তসহ update: UPDATE … SET stock = 8, fence = 34 WHERE id = 1 AND fence <= 34.
3. Storage token আগে দেখে: নতুন ধারকের লেখার আগেই পুরোনোজনের লেখা পৌঁছালে storage তখনো ৩৪ দেখেনি — ৩৩ গৃহীত হবে। তাই নতুন ধারক শুরুতেই token নিবন্ধন করে (অনুশীলন ৩)।

৭ · Redis-এ lock — SET NX PX, আর Redlock বিতর্ক

বাস্তবে সবচেয়ে প্রচলিত distributed lock সম্ভবত একটি Redis instance-এর ওপর। Redis-এর documentation-এ বর্ণিত এক-instance ধাঁচটি পর্ব ২৯ — Eviction আর invalidation-এর single-flight lock-এ দেখেছিলেন:

# take: set only if absent (NX), expire after 5000 ms (PX); the value is a random token of the caller
SET lock:report a-71 NX PX 5000      # -> OK for one caller, (nil) for everyone else
# release: delete only if the value is still mine -- check and delete in one Lua script
#   if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end

SET NX PX একটি পারমাণবিক কমান্ডে দুটি কাজ করে: key না থাকলে বসানো, আর মেয়াদ দেওয়া — তাই lock আর lease একসাথে। পুরোনো ধাঁচে আলাদা SETNX আর EXPIRE দুটি কমান্ড ছিল; মাঝে crash হলে মেয়াদহীন lock থেকে যেত। ছাড়ার নিয়মটি কেন এত জরুরি, নিচের stepper-এ দেখুন — একটি রিপোর্ট job, lock-এর মেয়াদ ৫ সেকেন্ড, কিন্তু এক রাতে কাজে লাগল ৭ সেকেন্ড।

এক instance-এর আরেকটি সীমা — failover

একটি Redis instance বিকল হলে lock-ও বিকল। Replica রাখলে নতুন সমস্যা: Redis-এর replication ডিফল্টে asynchronous, তাই A-এর lock primary-তে লেখা হলো কিন্তু replica-তে পৌঁছানোর আগেই primary মরল, replica primary হলো — সেখানে lock-টি নেই, B সহজেই পেল। Redis-এর documentation নিজেই এই ঝুঁকির কথা বলে। Cache-এর failover-এ কী হারায়, তার পূর্ণ আলোচনা পর্ব ৩০ — Distributed cache-এ।

Redlock — আর তাকে ঘিরে বিতর্ক

এই সমস্যার জন্য Redis-এর স্রষ্টা Salvatore Sanfilippo (antirez) Redlock প্রস্তাব করেন, যা Redis-এর documentation-এ বর্ণিত: ধরা যাক পাঁচটি সম্পূর্ণ স্বাধীন Redis master (একে অপরের replica নয়)। Client একই key আর এলোমেলো মান দিয়ে পাঁচটিতেই SET NX PX চেষ্টা করে; অন্তত তিনটিতে (majority) সফল হলে আর লাগা সময় মেয়াদের চেয়ে অনেক কম হলে lock তার, বৈধ সময় = মেয়াদ − লাগা সময় − ঘড়ির ছাড়। ব্যর্থ হলে সবগুলো থেকে ছাড়ে।

২০১৬ সালের ফেব্রুয়ারিতে এ নিয়ে একটি প্রকাশ্য, শিক্ষণীয় বিতর্ক হয়। দুটি লেখাই অনলাইনে আছে; নিচে দুই পক্ষের মূল যুক্তি যতটা নিরপেক্ষভাবে সম্ভব:

লক্ষ করুন, দুই পক্ষ একটি জায়গায় একমত: lease-ভিত্তিক কোনো lock নিজে থেমে থাকা ধারককে থামাতে পারে না। মতভেদ মূলত সময়ের অনুমান বাস্তবে কতটা টেকে, আর Redlock এক instance-এর চেয়ে কতটা বাড়তি নিরাপত্তা দেয় — তা নিয়ে। প্রায় সবার মানা ব্যবহারিক শিক্ষা: efficiency lock-এ একটি Redis যথেষ্ট; correctness-এ consensus-চালিত সেবা আর fencing token, অথবা lock ছাড়া নকশা (অংশ ৯)। দুটি লেখা পড়ে নিজে বিচার করুন।

৮ · Lease কত লম্বা — TTL-এর trade-off আর ঘড়ির অনুমান

Lease-এর মেয়াদ একটি টানাটানি। ছোট TTL-এ ধারক মরলে দ্রুত আরেকজন দায়িত্ব নেয়; কিন্তু ছোট একটি বিরতি বা হারানো packet-এও lease ফুরায়, যদিও ধারক সুস্থ — এর নাম false expiry, আর প্রতিটি false expiry মানে অকারণ leader বদল বা দুজন ধারকের ঝুঁকি। বড় TTL-এ উল্টো: false expiry কম, কিন্তু মৃত ধারকের জন্য সবাই দীর্ঘ অপেক্ষা করে। ধরা যাক নবায়ন হয় প্রতি R = TTL/৩-এ, আর শেষ নবায়নের s সেকেন্ড পরে কিছু ঘটে (০ ≤ s < R):

নিচের simulator-এ ধারকের ১০,০০০টি বিরতি — বেশিরভাগ আধা সেকেন্ডের কম, কিছু ১–৫ সেকেন্ড, অল্প কয়েকটি ৫–৩০ সেকেন্ড (মিশ্রণটি ধরে নেওয়া, আপনার সিস্টেমে মেপে বসান) — আর ১,০০০টি crash; দখলের সময় ০.৩ সেকেন্ড ধরা হয়েছে। তিনটি TTL তুলনা করা হলো: ২, ১০ আর ৩০ সেকেন্ড।

// Lease TTL trade-off: recovery time after a holder crash vs false expiries caused by pauses.
function mulberry32(a) {
  return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; };
}
const rnd = mulberry32(4343);
const ACQ = 0.3;                        // a waiter needs ~0.3 s to see the expiry and take the lock (assumed)
function pauseLen() {                   // assumed mix of stalls: GC, VM steal, slow disk, lost packets
  const r = rnd();
  if (r < 0.95) return rnd() * 0.5;     // 95%: under half a second
  if (r < 0.995) return 1 + rnd() * 4;  // 4.5%: 1-5 s
  return 5 + rnd() * 25;                // 0.5%: 5-30 s
}
// 10,000 stalls of the holder; each starts at a random point inside its renewal interval
const stalls = Array.from({ length: 10000 }, () => ({ len: pauseLen(), phase: rnd() }));
const crashes = Array.from({ length: 1000 }, () => rnd());   // 1,000 crashes, random phase
console.log("TTL   renew   avg recovery   worst recovery   false expiries / 10k stalls");
for (const TTL of [2, 10, 30]) {
  const R = TTL / 3;                    // keep-alive every TTL/3
  // lease left when the stall starts = TTL - (time since last renewal)
  const falseExp = stalls.filter(s => s.len > TTL - s.phase * R).length;
  const rec = crashes.map(f => TTL - f * R + ACQ);  // lease runs out, then a waiter takes over
  const avg = rec.reduce((a, b) => a + b, 0) / rec.length, worst = Math.max(...rec);
  console.log(String(TTL).padStart(3) + "s" + R.toFixed(2).padStart(7) + "s" +
    avg.toFixed(1).padStart(12) + " s" + worst.toFixed(1).padStart(15) + " s" +
    String(falseExp).padStart(17));
}
const holders = 10000;                  // keep-alive load for 10,000 lease holders
for (const TTL of [2, 10, 30]) console.log(`TTL ${TTL}s: ${holders} holders send ${Math.round(holders / (TTL / 3))} keep-alives/s`);

TTL   renew   avg recovery   worst recovery   false expiries / 10k stalls
  2s   0.67s         2.0 s            2.3 s              408
 10s   3.33s         8.6 s           10.3 s               30
 30s  10.00s        25.3 s           30.3 s                7
TTL 2s: 10000 holders send 15000 keep-alives/s
TTL 10s: 10000 holders send 3000 keep-alives/s
TTL 30s: 10000 holders send 1000 keep-alives/s

ঘড়ির অনুমান

Lease দুটি আলাদা ঘড়িতে মাপা হয় — সেবার আর ধারকের। নিরাপত্তার জন্য ঘড়িগুলোকে একই সময় দেখাতে হয় না, কিন্তু কাছাকাছি গতিতে চলতে হয়। গতির পার্থক্য সর্বোচ্চ ρ (যেমন ০.১%) হলে ধারক নিজের হিসাবে lease শেষ ধরে TTL × (১ − ρ) − margin-এ। পর্ব ৩৯-এ দেখেছেন clock drift কেন হয়। ব্যবহারিক নিয়ম:

• মেয়াদ গুনুন monotonic clock দিয়ে (Linux-এ CLOCK_MONOTONIC), wall-clock দিয়ে নয় — NTP wall-clock-কে লাফ দেওয়াতে পারে, monotonic ঘড়ি পেছায় না।
• TTL রাখুন মাপা p99.9 বিরতি আর round trip-এর কয়েক গুণ; ZooKeeper-এ session timeout ডিফল্টে সাধারণত tickTime-এর ২ থেকে ২০ গুণের মধ্যে (documentation-এ যাচাই করুন)।
• Chubby-র paper-এর lock-delay: ধারক ব্যর্থ হয়ে lock খালি হলে কিছুক্ষণ (paper অনুযায়ী সর্বোচ্চ এক মিনিট) অন্য কেউ সেটি পায় না, যাতে পুরোনো ধারকের দেরির বার্তা আগে শেষ হয় — fencing না বোঝে এমন সার্ভারের জন্য কাজ-চালানো সমাধান।

৯ · Lock ছাড়াই — CAS, idempotency, single-writer আর queue

নিরাপদ distributed lock-এ লাগে consensus-চালিত সেবা, lease, fencing token আর যাচাই করা storage. শেষ উপাদানটি — storage-এর শর্তসহ লেখা — নিজেই অনেক সমস্যা মেটায়। তাই আগের প্রশ্ন: lock কি আসলেই লাগে? চারটি বিকল্প প্রায়ই সরল আর নিরাপদ:

১০ · AI-এর যুগে — distributed lock-এর নকশা যাচাই

“দুটি সার্ভার একই job চালাচ্ছে, কী করব?” — AI প্রায়ই বলে: “Redis-এ SETNX দিয়ে distributed lock নিন।” দেখতে পরিষ্কার, কিন্তু এই পর্বের প্রায় সব ফাঁদ তাতে থাকতে পারে:

AI-এর lock নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Lock-টি efficiency না correctness — লিখে রেখেছি, আর lock ব্যর্থ হলে ক্ষতির পরিমাণ জানি
• Lock ছাড়া বিকল্প (CAS, UNIQUE, idempotency, single-writer, queue) আগে বিবেচনা করেছি
• প্রতিটি lock-এর মেয়াদ আছে; ছাড়া হয় মান মিলিয়ে; TTL, নবায়ন আর recovery-র হিসাব নিজে আবার করেছি
• Correctness-এ fencing token আছে, আর storage সেটি পারমাণবিকভাবে যাচাই করে; যে সেবা token বোঝে না, সেখানে idempotency key
• Failure-mode পর্যালোচনা: ধারকের বিরতি, network বিচ্ছিন্নতা, lock সেবার failover, ঘড়ির লাফ — প্রতিটিতে কী হয় লিখেছি
• পরীক্ষায় ধারককে কৃত্রিমভাবে থামিয়ে দুই ধারকের ক্ষেত্র নিজে তৈরি করে দেখেছি; product-এর মান documentation-এ মিলিয়েছি