Read ও Write Quorum: কত replica-এর সম্মতি চাই

এই পাঠে যা শিখবেন

• N R W সংখ্যার অর্থ বুঝুন
• Intersection-এর শর্ত হিসাব করুন
• Quorum-কে linearizability-এর সমান ভাববেন না

সমস্যা দিয়ে শুরু

এক product তিন replica-তে আছে। একটি write দুই copy-তে সফল, পরের read শুধু তৃতীয় copy থেকে এল। Client পুরোনো দাম দেখল। Team ঠিক করল read-এ একাধিক replica জিজ্ঞাসা করবে; কিন্তু কতটি এবং conflict কীভাবে বাছবে তা নির্ধারিত নেই।

সহজ করে বুঝি

N replica হলে W write acknowledgment এবং R read response লাগতে পারে। একই replica set-এ R + W > N হলে প্রতিটি read set অন্তত একটি write set member-এর সঙ্গে intersect করে। W > N/2 হলে দুই write set-ও intersect করে। এই arithmetic একা ordering, version comparison বা linearizability নিশ্চিত করে না।

পরিচিত একটি উপমা

তিন খাতার মধ্যে দুইটিতে নতুন দাম লিখে যেকোনো দুইটি খাতা দেখলে অন্তত একটিতে নতুন দাম পাবেন। তবে কোন খাতার দাম নতুন বোঝার নিয়ম চাই। শুধু দুইটি ভিন্ন সংখ্যা দেখে গড় নেওয়া সঠিক product price নয়।

নকশাটি দেখুন

flowchart TD
 W[Write W=2] --> A[Replica A v7]
 W --> B[Replica B v7]
 R[Read R=2] --> B
 R --> C[Replica C v6]
 B --> V[Compare versions]
 C --> V

Write A ও B-তে v7 রেখেছে। Read B ও C পেলে overlap হলো B। Version comparator v7 বেছে নিতে পারে। কিন্তু concurrent v7-like versions থাকলে timestamp দিয়ে সিদ্ধান্ত সব সময় যথেষ্ট নয়; storage protocol-এর ordering assumptions দেখতে হবে।

PHP ও Laravel-এ প্রয়োগ

PHP fragment quorum-এর set intersection বোঝার exercise; এটি distributed database client implementation নয়। Laravel application বাস্তবে driver ও database-supported consistency level ব্যবহার করবে। এখানে অসম্পূর্ণ response set-এ কোনো value ফেরানো হচ্ছে না।

$replicaCount = 3;
$requiredWrites = 2;
$requiredReads = 2;
$hasReadWriteIntersection =
    $requiredReads + $requiredWrites > $replicaCount;

$responses = [
    ['replica' => 'B', 'version' => 7, 'price_minor' => 12000],
    ['replica' => 'C', 'version' => 6, 'price_minor' => 11000],
];
abort_unless(count($responses) >= $requiredReads, 503);
usort($responses, fn ($a, $b) => $b['version'] <=> $a['version']);
$chosen = $responses[0];
// Safe version comparison requires the storage protocol's assumptions.

এটি PHP 8.3+ ও Laravel 12-এর শিক্ষামূলক fragment; সম্পূর্ণ application নয়। সংশ্লিষ্ট route-এ authentication ও resource authorization প্রয়োগ করতে হবে। নিচের অনুশীলনে failure ইচ্ছা করে তৈরি করুন; শুধু সফল response দেখে correctness ধরে নেবেন না।

সুবিধা, সীমাবদ্ধতা ও trade-off

বড় R read latency ও load বাড়ায়; বড় W write latency ও unavailable replica-এর প্রভাব বাড়ায়। ছোট acknowledgment set দ্রুত হতে পারে কিন্তু stale read বা durability risk বদলে যায়। Workload ratio ও failure tolerance অনুযায়ী policy পরীক্ষা করুন।

সাধারণ ভুল

• R + W > N দেখেই linearizability দাবি করা।
• Different replica sets বা sloppy quorum-এর ক্ষেত্রেও একই সরল proof বসানো।
• Highest wall-clock timestamp-কে সর্বদা সঠিক version ভাবা।

আরও একটু গভীরে

Dynamo-style quorum-এ concurrent writes, hinted handoff, read repair এবং anti-entropy থাকে। Fixed membership intersection আর বাস্তবে কোন node acknowledgment দিল আলাদা হতে পারে। Read repair convergence সাহায্য করে, কিন্তু financial invariant-এর বিকল্প নয়।

N=5 ধরে R=2 W=3 এবং R=3 W=3 তুলনা করুন। প্রথমটিতে disjoint sets সম্ভব; দ্বিতীয়টিতে overlap বাধ্যতামূলক। একটি slow replica যোগ করে latency বদল মাপুন। Arithmetic-এর বাইরে concurrent version resolution আলাদা test case রাখুন।

মনে রাখুন

• Quorum সংখ্যা ও membership দুটো দরকার।
• Intersection তথ্য পাওয়ার সুযোগ, পূর্ণ correctness নয়।
• Version semantics না জেনে merge নয়।

নিজে চেষ্টা করুন

পাঁচ replica-এর দুটি disjoint read/write set আঁকুন যেখানে R+W=5। তারপর একটি সংখ্যা বাড়িয়ে intersection কেন অবশ্যম্ভাবী হয় প্রমাণ করুন।

নিজের বোঝা যাচাই করুন

1. N কী?

নির্দিষ্ট data item-এর replica সংখ্যা; পুরো cluster-এর server সংখ্যা সব সময় নয়।

2. R+W>N কেন?

একই N সদস্যের set-এ read এবং write সম্পূর্ণ আলাদা থাকতে পারে না।

3. এতে linearizable হয়?

একাই নয়। Concurrent writes, membership এবং protocol ordering-এর নিয়মও লাগবে।

4. W বাড়ালে খরচ?

বেশি replica acknowledgment-এর অপেক্ষা ও availability-এর সীমা বাড়ে; durability semantics-ও যাচাই করতে হয়।

5. পুরোনো value পেলে?

Database-এর version/conflict protocol অনুযায়ী resolve করতে হয়; application অনুমানে timestamp বেছে নেবে না।

আরও পড়ুন

• Amazon Dynamo paper
• Apache Cassandra consistency