Distributed system-এর কঠিন সত্য — partial failure, অনির্ভরযোগ্য network আর clock

১ · কেন অনেক যন্ত্র, আর তার দাম — মডিউল ৭-এর শুরু

আগের ছয়টি মডিউলে আমরা অনেক কৌশল ব্যবহার করেছি: replica, shard, queue, cache, outbox. প্রতিটিতে আমরা চুপচাপ কিছু জিনিস ধরে নিয়েছি — বার্তা শেষ পর্যন্ত পৌঁছাবে, ঘড়ি মোটামুটি ঠিক, আর কোনো node মরে গেলে আমরা তা বুঝতে পারব। এই মডিউলে সেই অনুমানগুলোই খুলে দেখব।

প্রথমে মূল প্রশ্ন: একটি যন্ত্রে সব চালালে এত ঝামেলা থাকে না, তবু আমরা অনেক যন্ত্রে যাই কেন? একটি distributed system মানে এমন কয়েকটি যন্ত্র (node), যারা শুধু network-এ বার্তা আদানপ্রদান করে একসাথে একটি কাজ করে, আর যাদের মধ্যে কোনো ভাগাভাগি করা memory বা একটি সাধারণ ঘড়ি নেই। এমন নকশার তিনটি বড় কারণ:

মডিউল ৭-এর পথ

এই পর্ব বাকি আটটি পর্বের ভিত্তি। প্রতিটি পর্ব এখানকার একটি “কঠিন সত্য”-র জবাব:

২ · আটটি ভুল ধারণা — fallacies of distributed computing

১৯৯০-এর দশকে Sun Microsystems-এর প্রকৌশলীরা নতুনদের বারবার করা ভুল অনুমানগুলোর একটি তালিকা করেন — fallacies of distributed computing. প্রচলিত বর্ণনা অনুযায়ী প্রথম সাতটি L Peter Deutsch ও সহকর্মীদের, অষ্টমটি পরে James Gosling-এর; উৎস নিয়ে বর্ণনায় কিছুটা ভিন্নতা আছে (ইতিহাস পর্ব ০১-এর ভাবনার প্রশ্নে)। প্রতিটি ভাঙলে কী ঘটে, আর জবাব কোথায়:

৩ · Partial failure — এক যন্ত্রে “সব বা কিছুই না”, অনেক যন্ত্রে “কিছু, আর অজানা”

আপনার ল্যাপটপে একটি প্রোগ্রাম চালালে সাধারণত দুটি ফলের একটি পাবেন: কাজ হয়, নয়তো পুরো প্রোগ্রাম বা পুরো কম্পিউটার থেমে যায়। গুরুতর hardware ত্রুটিতে operating system ভুল উত্তর না দিয়ে নিজেই থেমে যায় (kernel panic) — নকশাকারেরা ইচ্ছা করেই অর্ধেক-ঠিক অবস্থার চেয়ে পুরোপুরি থেমে যাওয়া বেছে নিয়েছেন।

অনেক যন্ত্রে এই আরাম নেই। একই মুহূর্তে একটি node চলছে, একটি মরে গেছে, একটি অস্বাভাবিক ধীর, আর একটির সাথে network-এর যোগাযোগ কাটা। একে বলে partial failure. সবচেয়ে কঠিন ব্যাপার হলো, এটি অনির্ণেয়: একটি অনুরোধ পাঠালে তিনটি ফল সম্ভব — সফল, ব্যর্থ, আর অজানা। তৃতীয়টিই distributed system-কে আলাদা করে।

নিচের stepper-এ ঠিক এই ঘটনাটি দেখুন। “পরে” চাপুন:

এর পেছনের নকশা-নীতি end-to-end argument (Saltzer, Reed ও Clark, ১৯৮৪): পুরো যাচাই হয় শুধু দুই প্রান্তের অ্যাপ্লিকেশনে; TCP-র মতো নিচের স্তর কাজটি সস্তা করে, প্রতিস্থাপন করে না (ভাবনার প্রশ্ন ০৫)।

৪ · অনির্ভরযোগ্য network — হারানো, দেরি, duplicate আর উল্টো ক্রম

ডেটা সেন্টার আর ইন্টারনেটের network হলো packet-switched: প্রতিটি বার্তা ছোট packet-এ ভাগ হয়ে switch আর router-এর queue পেরিয়ে যায়। এমন network কোনো প্রতিশ্রুতি দেয় না যে বার্তা কখন পৌঁছাবে, বা আদৌ পৌঁছাবে কি না। একে বলে asynchronous network. নিচের ছবিতে চার রকম গোলমাল আর দুটি node-এর ঘড়ি একসাথে দেখুন — পুরো পর্বের মানচিত্র এটিই:

কারণগুলো সাধারণ: ভিড়ে switch-এর buffer ভরে packet ফেলে দেয় (packet loss); queue, retransmission বা প্রাপকের GC দেরি বাড়ায়, আর দেরির কোনো ঊর্ধ্বসীমা নেই; timeout-এর পরে আবার পাঠালে প্রথম কপিটিও শেষে পৌঁছায় — duplicate; দুই পথ বা retry-তে ক্রম উল্টায় (out-of-order delivery). TCP একটি connection-এর ভেতরে এর অনেকটা সামলায় (Computer Networks-এর TCP reliability পর্বে), কিন্তু connection কেটে গেলে বা অ্যাপ নিজে retry করলে সেই নিশ্চয়তা থাকে না, আর দেরি সে দূর করে না।

ধীর নাকি মৃত — বাইরে থেকে বোঝার উপায় নেই

কখনো বাড়তি সংকেত মেলে: যন্ত্র চালু কিন্তু process মরে গেলে OS সাথে সাথে “connection refused” ফেরত দিতে পারে। কিন্তু পুরো যন্ত্র বন্ধ বা পথ কাটা হলে কোনো সংকেতই আসে না। তখন একমাত্র উপায় অপেক্ষা করা, আর একসময় timeout ঘোষণা করা। Timeout পেরোনো মানে “মৃত” নয়, মানে “এতক্ষণ অপেক্ষার পরেও খবর নেই, তাই মৃত বলে সন্দেহ করছি”। এই সন্দেহের কাজটি যে অংশ করে, তাকে বলে failure detector; নিয়মিত heartbeat দিয়ে বড় মাপে কীভাবে কাজ করে, তা পর্ব ৪৪-এ।

Timeout কত হবে? একটি simulator

ধরা যাক ২০,০০০টি RPC. দুই দিকেই ০.৫% বার্তা হারায়। স্বাভাবিক round trip গড়ে প্রায় ২০ ms, কিন্তু ৩% call-এ কোনো GC pause, queue বা retransmit বাড়তি ০.১ থেকে ১.৫ সেকেন্ড যোগ করে। Client শুধু দেখে reply এলো কি না। কয়েকটি timeout-এ দেখি, timeout-গুলোর কতটা আসলে “ধীর, কিন্তু সফল”:

// 20,000 RPCs over an unreliable network. The client sees only "reply" or "timeout".
function mulberry32(a) { return () => { a |= 0; 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(38), N = 20000;
const P_REQ_LOST = 0.005, P_REPLY_LOST = 0.005;   // assumed loss on each direction
const calls = [];
for (let i = 0; i < N; i++) {
  const reqLost = rnd() < P_REQ_LOST, replyLost = rnd() < P_REPLY_LOST;
  let rtt = 8 + -12 * Math.log(1 - rnd());          // normal round trip: ~8 ms + exponential, mean 20 ms
  if (rnd() < 0.03) rtt += 100 + rnd() * 1400;      // 3%: a GC pause, queue or retransmit adds 0.1-1.5 s
  calls.push({ reqLost, replyLost, rtt });
}
const dead = calls.filter(c => c.reqLost || c.replyLost).length;
console.log("calls " + N + ", replies that never come: " + dead + " (work done anyway in " +
  calls.filter(c => !c.reqLost && c.replyLost).length + " of them)");
console.log("timeout_ms  timeouts  really_lost  slow_but_ok  false_share  wait_to_detect_loss");
for (const T of [50, 100, 250, 500, 1000, 2000]) {
  let timeouts = 0, slowOk = 0;
  for (const c of calls) {
    const noReply = c.reqLost || c.replyLost;
    if (noReply || c.rtt > T) { timeouts++; if (!noReply) slowOk++; }
  }
  console.log(String(T).padStart(10) + String(timeouts).padStart(10) + String(dead).padStart(13) +
    String(slowOk).padStart(13) + ((100 * slowOk / timeouts).toFixed(1) + "%").padStart(13) +
    (T + " ms").padStart(21));
}

calls 20000, replies that never come: 217 (work done anyway in 106 of them)
timeout_ms  timeouts  really_lost  slow_but_ok  false_share  wait_to_detect_loss
        50      1385          217         1168        84.3%                50 ms
       100       814          217          597        73.3%               100 ms
       250       753          217          536        71.2%               250 ms
       500       658          217          441        67.0%               500 ms
      1000       450          217          233        51.8%              1000 ms
      2000       217          217            0         0.0%              2000 ms

তাহলে কীভাবে বাছবেন? কয়েকটি নিয়ম:

1. মেপে বাছুন, অনুমানে নয়: সুস্থ অবস্থার p99 বা p99.9-এর একটু ওপরে (পর্ব ০৪-এর tail latency). TCP-ও মাপা RTT থেকে নিজের timeout হিসাব করে।
2. পুরো অনুরোধের একটি deadline: ওপরে ২ s বাকি থাকলে নিচের call-এ ৫ s অপেক্ষার মানে নেই।
3. Retry সীমিত, ছড়ানো আর নিরাপদ: exponential backoff, jitter, শুধু idempotent কাজে — না হলে retry storm (পর্ব ১৮; resilience pattern পর্ব ৪৮-এ)।
4. অনুরোধ ছাড়া আর node বাদ দেওয়া আলাদা সিদ্ধান্ত: প্রথমটি সস্তা; failover ব্যয়বহুল, তাই তাতে কয়েকবারের ব্যর্থতা আর কয়েকজনের মত লাগে (পর্ব ৪৪)।

৫ · Network partition — যখন network দুই ভাগ

একটি network partition হলো এমন অবস্থা, যেখানে node-গুলো দুই বা বেশি দলে ভাগ হয়ে যায়: প্রতিটি দলের ভেতরে কথা চলে, দলের বাইরে নয়। সব node-ই চালু, তবু পুরো সিস্টেম আর একটি নয়। কারণ: switch নষ্ট, ভুল firewall নিয়ম, fiber কাটা, রাউটিংয়ের ভুল বা এত ভিড় যে heartbeat পৌঁছায় না।

“এগুলো তো কালেভদ্রে ঘটে” — এই ধারণা বাস্তব নয়। Peter Bailis আর Kyle Kingsbury-র “The Network is Reliable” (ACM Queue, ২০১৪) প্রবন্ধে বিভিন্ন প্রতিষ্ঠানের প্রকাশিত বিভ্রাটের বিবরণ জড়ো করে দেখানো হয়েছে, বড় সিস্টেমে partition নিয়মিত ঘটনা। নিচের stepper-এ পাঁচটি node-এর একটি cluster (replication-সহ, একজন leader) দুই ভাগ হলো: ২টি এক পাশে, ৩টি অন্য পাশে। নিয়ম: কোনো লেখা quorum অর্থাৎ ৫-এর মধ্যে অন্তত ৩ জনের কাছে পৌঁছালে তবেই commit.

বাস্তবের partition সবসময় পরিচ্ছন্ন নয় — কখনো একমুখী (A-র বার্তা B পায়, উল্টোটা নয়), কখনো আংশিক (A আর C দুজনেই B-কে পায়, নিজেদের নয়)। Majority নিয়ম আর term নম্বর এসবেও safety রাখে, যদিও অগ্রগতি কখন ফিরবে বলা কঠিন। Majority ছাড়া লেখা নিলে দুই পক্ষই লেখা নেয় — split-brain, যার পরিষ্কারের খরচ বিশাল (ভাবনার প্রশ্ন ০১)। কোন সিস্টেম partition-এ লেখা থামায় আর কোনটি দুই পাশে নিয়ে পরে মেলায়, তা পর্ব ৪০ আর পর্ব ৪১-এর বিষয়।

৬ · অনির্ভরযোগ্য ঘড়ি — drift, NTP আর wall-clock বনাম monotonic

প্রতিটি কম্পিউটারের ভেতরে একটি ছোট quartz crystal কাঁপে, আর সেই কম্পন গুনে ঘড়ি চলে। কিন্তু কোনো দুটি crystal হুবহু এক হারে কাঁপে না, আর তাপমাত্রা বদলালে হার বদলায়। ফলে ঘড়ি ধীরে ধীরে সঠিক সময় থেকে সরে যায় — একে বলে clock drift, মাপা হয় ppm-এ (parts per million, প্রতি ১০ লাখে কত)। ৫০ ppm মানে প্রতি সেকেন্ডে ৫০ মাইক্রোসেকেন্ড ভুল, দিনে প্রায় ৪.৩ সেকেন্ড। Google-এর Spanner গবেষণাপত্র (২০১২) প্রকাশিত বর্ণনায় সবচেয়ে খারাপ ক্ষেত্রে প্রায় ২০০ ppm drift ধরে নিয়েছিল — দিনে প্রায় ১৭ সেকেন্ড।

ঘড়ি ঠিক রাখতে যন্ত্রগুলো NTP (Network Time Protocol) দিয়ে সময়-সার্ভার থেকে সময় নেয়। কিন্তু NTP নিজেও network-এর ওপর চলে: যাওয়া আর ফেরার দেরি সমান না হলে হিসাবে ভুল ঢোকে। সাধারণত একই ডেটা সেন্টারে মিলিসেকেন্ডের নিচে, ইন্টারনেট পেরিয়ে কয়েক থেকে কয়েক দশ মিলিসেকেন্ডের পার্থক্য থেকে যায় (সেটআপভেদে অনেক আলাদা); ভুল config বা আটকে যাওয়া NTP-তে আরও বেশি। দুই যন্ত্রের এই পার্থক্যকে বলে skew. পার্থক্য বেশি হলে NTP এক লাফে ঘড়ি বদলে দিতে পারে — সামনে বা পেছনে। এর সাথে আছে leap second: পৃথিবীর ঘূর্ণনের সাথে মেলাতে মাঝে মাঝে এক সেকেন্ড যোগ করা হয়েছে, যা বহু সফটওয়্যারকে বিপদে ফেলেছে (ভাবনার প্রশ্ন ০২)।

দুই ধরনের ঘড়ি

নিচের stepper-এ দেখুন, wall-clock দিয়ে timeout মাপলে কী হয়। Timeout ১ সেকেন্ড:

৭ · Process pause — না জেনেই থেমে থাকা, আর একটি lease-এর বিপদ

এবার আরও অস্বস্তিকর একটি সত্য। আপনার কোডের দুটি পরপর লাইনের মাঝে process কয়েক সেকেন্ড — কখনো আরও বেশি — থেমে থাকতে পারে, আর জেগে উঠে সে টেরও পায় না। একে বলে process pause. কারণগুলো খুবই সাধারণ:

• Garbage collection: Java, Go-র মতো runtime-এ কিছু GC ধাপ সব thread থামায় (stop-the-world) — সাধারণত ms, খারাপ ক্ষেত্রে সেকেন্ড।
• Virtual machine থামানো: hypervisor VM-কে থামিয়ে অন্য যন্ত্রে সরাতে পারে (live migration; Operating Systems-এর virtual machine পর্বে)।
• OS আর যন্ত্র: swapping, ধীর disk-এর অপেক্ষা, signal দিয়ে থামানো, ল্যাপটপের ঢাকনা বন্ধ।

Distributed system-এ এটা বিপজ্জনক, কারণ থেমে থাকার সময়ে বাকি পৃথিবী এগিয়ে যায়। সবচেয়ে চেনা উদাহরণ lease: একটি সময়সীমাসহ অধিকার, যেমন “পরের ১০ সেকেন্ড শুধু আপনি এই ফাইলে লিখবেন”. নিচের stepper-এ দেখুন:

কত ঘন ঘন এমন হয়? নিচের simulator প্রথমে কয়েকটি নির্দিষ্ট pause-এ “দুই মালিকের” সময় হিসাব করে। তারপর ১ লাখ lease চক্র চালায়, একটি ধরে নেওয়া মিশ্রণে: বেশিরভাগ pause ৫০ ms-এর নিচে, ১% চক্রে ০.২–৩ s-এর GC pause, আর ০.০৫% চক্রে ৫–৪০ s-এর VM থামা। ধরা যাক B lease পেয়েই লেখে:

// A 10 s lease. Holder A checks "still mine?" at 8 s, then (maybe) pauses, then writes.
// The lock service gives the lease to B at 10 s. Overlap = time A writes while B also owns it.
function mulberry32(a) { return () => { a |= 0; 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 TTL = 10, CHECK = 8;                     // seconds; 2 s safety margin

function overlap(pause) { const writeAt = CHECK + pause; return Math.max(0, writeAt - TTL); }
console.log("pause_s  A_writes_at  B_owner_from  two_owners_for");
for (const p of [0.05, 1, 2, 3.5, 15, 40])
  console.log(String(p).padStart(7) + (CHECK + p).toFixed(2).padStart(13) + TTL.toFixed(2).padStart(14) +
    (overlap(p).toFixed(2) + " s").padStart(16));

// 100,000 lease cycles with an assumed pause mix: mostly tiny, sometimes GC, rarely a VM freeze.
const rnd = mulberry32(43); let bad = 0, worst = 0, rejected = 0, maxToken = 0;
for (let i = 0; i < 100000; i++) {
  const r = rnd(); let pause = rnd() * 0.05;                  // 0-50 ms scheduling noise
  if (r < 0.01) pause = 0.2 + rnd() * 2.8;                    // 1%: GC pause 0.2-3 s
  if (r < 0.0005) pause = 5 + rnd() * 35;                     // 0.05%: VM suspended 5-40 s
  const ov = overlap(pause), tokenA = 2 * i + 1, tokenB = 2 * i + 2;
  if (ov > 0) { bad++; worst = Math.max(worst, ov);
    maxToken = tokenB;                                        // B wrote first with the newer token
    if (tokenA < maxToken) rejected++; }                      // storage refuses A's stale token
  else maxToken = tokenA;
}
console.log("cycles 100000, two-owner cycles: " + bad + ", worst overlap: " + worst.toFixed(2) +
  " s, stale writes refused by fencing: " + rejected);

pause_s  A_writes_at  B_owner_from  two_owners_for
   0.05         8.05         10.00          0.00 s
      1         9.00         10.00          0.00 s
      2        10.00         10.00          0.00 s
    3.5        11.50         10.00          1.50 s
     15        23.00         10.00         13.00 s
     40        48.00         10.00         38.00 s
cycles 100000, two-owner cycles: 391, worst overlap: 37.07 s, stale writes refused by fencing: 391

৮ · System model — নকশার আগে নিয়মের খাতা

এত অনিশ্চয়তার মধ্যে কোনো algorithm “ঠিক” কি না, বলব কীভাবে? উত্তর: আগে লিখে নিতে হয় কোন কোন ব্যর্থতা ঘটতে পারে বলে ধরছি। এই লিখিত অনুমানের নাম system model. একটি algorithm তার model-এর ভেতরে প্রমাণসহ ঠিক; model-এর বাইরের ঘটনা ঘটলে কোনো প্রতিশ্রুতি নেই। Model-এর দুটি অক্ষ: সময় আর ব্যর্থতা।

Byzantine নামটি Lamport, Shostak ও Pease-এর “The Byzantine Generals Problem” (১৯৮২) থেকে। Crash হওয়া কর্মচারী অফিসে আসেন না — বোঝা যায়; Byzantine কর্মচারী এসে খাতায় ইচ্ছা করে ভুল লেখেন — অনেক কঠিন। f টি ব্যর্থতা সামলাতে crash model-এ ২f + ১টি node লাগে, Byzantine-এ ৩f + ১টি, বার্তাও অনেক বেশি। নিজের ডেটা সেন্টারে সব node একই মালিকের, তাই বেশিরভাগ সিস্টেম ধরে নেয় partial synchrony + crash-recovery, Byzantine নয় — সাথে checksum, TLS আর ইনপুট যাচাইয়ের মতো সীমিত সুরক্ষা (ভাবনার প্রশ্ন ০৪)।

৯ · Safety, liveness আর দুটি অসম্ভবতা — Two Generals আর FLP

একটি distributed algorithm-এর কাছে আমরা দুই ধরনের প্রতিশ্রুতি চাই। এই ভাগটি Leslie Lamport-এর ১৯৭৭ সালের একটি লেখা থেকে প্রচলিত, আর Alpern ও Schneider (১৯৮৫) গাণিতিকভাবে দেখান যে যেকোনো প্রতিশ্রুতিকে এই দুই ধরনের মিশ্রণ হিসেবে লেখা যায়:

নকশার সোনালি নিয়ম: safety সব পরিস্থিতিতে, partition বা pause চলাকালেও; liveness শর্তসাপেক্ষ হতে পারে — “network ভালো হলে এগোবে।” অংশ ৫-এর stepper-এ সংখ্যালঘু পক্ষ লেখা থামিয়ে liveness ছাড়ল, কিন্তু safety অটুট রইল।

Two Generals — হারাতে পারে এমন পথে নিশ্চিত ঐকমত্য নেই

Two Generals’ Problem-এর গল্প আর ইতিহাস পর্ব ০৮-এর ভাবনার প্রশ্নে আছে: দুই সেনাপতি A আর B, একসাথে আক্রমণ করলে জয়, একা করলে বিপর্যয়, আর বার্তাবাহক ধরা পড়তে পারে। বার্তা বাড়িয়ে লাভ হয় কি? প্রোটোকল k: বার্তাবাহক পালা করে যায় (A থেকে B, B থেকে A …) মোট k জন; কেউ ধরা পড়লে শিকল থামে। সেনাপতি আক্রমণ করেন কেবল যদি তাঁর প্রাপ্য প্রতিটি বার্তা পৌঁছায়। ধরা যাক প্রতিটি বার্তাবাহক ২০% সম্ভাবনায় ধরা পড়ে:

// Two generals: messengers alternate A->B, B->A, A->B ... ; each is captured with probability p.
// Rule: a general attacks only if every messenger addressed to him in the protocol arrived.
function mulberry32(a) { return () => { a |= 0; 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(2), P = 0.2, TRIALS = 100000;

function play(k, lostAt) {               // lostAt = index of the first captured messenger (k+1 = none)
  let gotA = 0, gotB = 0;                // messengers each general received
  for (let m = 1; m <= k && m < lostAt; m++) { if (m % 2) gotB++; else gotA++; }
  const needB = Math.ceil(k / 2), needA = Math.floor(k / 2);
  return [gotA === needA, gotB === needB];          // [A attacks?, B attacks?]
}
console.log("k  both_attack  neither  only_one(DISASTER)   run 'all arrive but the last'");
for (let k = 1; k <= 6; k++) {
  let both = 0, none = 0, one = 0;
  for (let t = 0; t < TRIALS; t++) {
    let lostAt = k + 1;
    for (let m = 1; m <= k; m++) if (rnd() < P) { lostAt = m; break; }
    const [a, b] = play(k, lostAt);
    if (a && b) both++; else if (!a && !b) none++; else one++;
  }
  const [la, lb] = play(k, k);
  console.log(k + String(both).padStart(13) + String(none).padStart(9) + String(one).padStart(20) +
    "   A " + (la ? "attacks" : "waits  ") + " / B " + (lb ? "attacks" : "waits"));
}

k  both_attack  neither  only_one(DISASTER)   run 'all arrive but the last'
1        79808        0               20192   A attacks / B waits
2        64046    20127               15827   A waits   / B attacks
3        51481    35845               12674   A attacks / B waits
4        40829    48903               10268   A waits   / B attacks
5        32889    58938                8173   A attacks / B waits
6        26135    67287                6578   A waits   / B attacks

বাস্তবের শিক্ষা: “দুই পক্ষ একই মুহূর্তে নিশ্চিত হবে” — এমন নকশা চাইবেন না। একজন সিদ্ধান্ত নিয়ে টেকসইভাবে লিখবে, অন্যজন একসময় জানবে, retry নিরাপদ হবে। পর্ব ২৫-এর two-phase commit ঠিক এভাবেই coordinator-এর লেখা সিদ্ধান্তকে সত্যের উৎস বানায়, আর পর্ব ৩৪-এর idempotency retry-কে নিরাপদ করে।

FLP — asynchronous model-এ একটি crash-ই যথেষ্ট

১৯৮৫ সালে Michael Fischer, Nancy Lynch আর Michael Paterson প্রমাণ করেন (FLP impossibility): পুরোপুরি asynchronous model-এ, যেখানে বার্তা হারায় না কিন্তু দেরির কোনো সীমা নেই, মাত্র একটি process-ও crash করতে পারলে কোনো deterministic algorithm নিশ্চয়তা দিতে পারে না যে সব ক্ষেত্রে consensus শেষ হবে। খেয়াল করুন, এখানে network Two Generals-এর চেয়েও ভালো — কোনো বার্তা হারায় না — তবু অসম্ভব।

অন্তর্দৃষ্টিটি অংশ ৪-এর পুরোনো সমস্যা: ধীর আর মৃত আলাদা করা যায় না। একটি process-এর মত না পেলে algorithm হয় অপেক্ষা করবে (সে মৃত হলে চিরকাল), নয়তো তাকে ছাড়াই এগোবে (সে শুধু ধীর হলে, তার দেরিতে আসা বার্তা সিদ্ধান্ত বদলে দিতে পারত)। প্রমাণ দেখায়, বার্তার সময় এমনভাবে সাজানো যায় যে algorithm চিরকাল “এখনো দুই দিকেই যেতে পারে” অবস্থায় থাকে। সূক্ষ্মতাটি গুরুত্বপূর্ণ: FLP বলে না consensus সাধারণত হয় না; বলে কিছু দুর্ভাগা সময়-বিন্যাসে liveness-এর নিশ্চয়তা নেই, safety রাখা সম্ভবই। তাই etcd বা ZooKeeper partial synchrony ধরে timeout আর এলোমেলো election timeout ব্যবহার করে; network খারাপ হলে থেমে থাকে, ভুল সিদ্ধান্ত নেয় না (পর্ব ৪২; ভাবনার প্রশ্ন ০৩)।

নকশায় এর মানে — সত্য থেকে কৌশল

১০ · AI-এর যুগে distributed systems-এর অনুমান যাচাই

AI-কে “একটি নির্ভরযোগ্য leader election বানিয়ে দাও” বললে প্রায়ই সুন্দর কোড আসে, যা চুপচাপ ধরে নেয় network নির্ভরযোগ্য আর ঘড়ি ঠিক — অর্থাৎ অংশ ২-এর ভুল ধারণাগুলো। চেনা ভুলগুলো:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• System model লিখেছি: সময়, ব্যর্থতা আর network-এর অনুমান
• প্রতিটি remote call-এর “অজানা” ফলের জন্য idempotency বা reconciliation-এর পথ আছে
• Timeout মাপা latency বণ্টন থেকে বেছেছি; retry সীমিত, backoff আর jitter-সহ
• Leader বা lock-এর সিদ্ধান্ত majority-ভিত্তিক; storage fencing token যাচাই করে
• সময়ের দৈর্ঘ্য monotonic clock-এ; ক্রম ঠিক করতে timestamp-এর ওপর অন্ধ ভরসা নেই
• হিসাব নিজে আবার করেছি, আর partition, pause ও clock-এর লাফ simulator বা পরীক্ষায় চালিয়েছি