Distributed Lock: lease ও fencing token

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

• Lock ownership এবং lease expiry বুঝুন
• Stale worker-এর ঝুঁকি চেনুন
• Fencing token resource-এ enforce করুন

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

এক export worker Redis lock নিয়ে file লিখছে। Process অনেকক্ষণ pause হলো; lock expire করে দ্বিতীয় worker নতুন export লিখল। প্রথম worker জেগে উঠে পুরোনো file overwrite করল। একই সময়ে দুই valid lease না থাকলেও পুরোনো কাজ পরে এসে ক্ষতি করেছে।

সহজ করে বুঝি

Distributed lock shared resource-এর কাজ এক owner-এ সীমিত করে। Lease নির্দিষ্ট সময়ের ownership; client pause হলেও মেয়াদ ফুরায়। Fencing token প্রতিটি নতুন ownership-এ বাড়তে থাকা সংখ্যা। Protected resource শেষ গ্রহণ করা token রাখে এবং ছোট বা সমান stale command reject করে, protocol অনুযায়ী।

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

গুদামের চাবি ফেরত না এলেও দিনের শেষে নতুন অনুমতিপত্র দেওয়া হয়। পুরোনো চাবি হাতে থাকলে সমস্যা থাকে; দরোয়ান যদি বড় serial-এর অনুমতিপত্র দেখার পর ছোট serial বাতিল করে, পুরোনো মালিক ঢুকতে পারেন না। দরোয়ানই এখানে protected storage।

নকশাটি দেখুন

sequenceDiagram
 participant A as Worker A
 participant L as Lease Service
 participant B as Worker B
 participant S as Storage
 A->>L: Acquire token 41
 B->>L: After expiry token 42
 B->>S: Write token 42 accepted
 A->>S: Late write token 41 rejected

প্রথম owner 41 পায়, pause-এর সময় lease হারায়। নতুন owner 42 দিয়ে resource update করে। পুরোনো worker জেগে 41 পাঠালে storage reject করে। Client নিজের lock আছে মনে করছে কি না, তার চেয়ে resource-এর atomic token check বেশি গুরুত্বপূর্ণ।

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

Laravel Cache lock duplicate কাজ কমানোর জন্য উপকারী; নিজে fencing token দেয় না। নিচের database update fragment-এ trusted monotonic token allocator আগে আছে ধরে নিন। resources table-এ last_fence numeric column এবং একই resource row ব্যবহার করতে হবে।

use Illuminate\Support\Facades\DB;

$changed = DB::table('resources')
    ->where('id', $resourceId)
    ->where('last_fence', '<', $fencingToken)
    ->update([
        'last_fence' => $fencingToken,
        'export_path' => $immutableExportPath,
        'updated_at' => now(),
    ]);

if ($changed !== 1) {
    throw new RuntimeException('Stale ownership rejected.');
}
// Write immutable files first; publish only the fenced pointer.
// Token generation and storage consistency remain infrastructure concerns.

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

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

Lease crashed owner-এর পর অগ্রগতি দেয়, কিন্তু expiry বাছা কঠিন। Fencing stale side effect ঠেকাতে পারে, তবে resource protocol বদলাতে হয়। Email provider token না মানলে শুধু Redis lock দিয়ে exactly-once email বলা যাবে না।

সাধারণ ভুল

• Lock TTL বাড়ালেই সব pause নিরাপদ ভাবা।
• Owner না মিলিয়ে অন্যের lock release করা।
• Token বানিয়ে resource-এ atomic check না করা।

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

Token sequence-এর correctness coordinator failover-এর উপর নির্ভর করে। Clock timestamp fencing-এর substitute নয়। একই lease-এ একাধিক write দরকার হলে operation sequence ও token comparison policy স্পষ্ট করতে হবে; এখানে প্রতি token একটি publish দেখানো হয়েছে।

Worker A lock নেওয়ার পরে থামান। B token নিয়ে publish করুক, তারপর A চালু করুন। A-এর update affected-row zero হওয়া চাই। File overwrite না করে immutable path ও fenced pointer রাখলে rejected worker-এর file garbage collection-এ মুছতে পারবেন।

মনে রাখুন

• Lease মেয়াদ শেষ হওয়া মানে process শেষ নয়।
• Resource-এ stale owner reject করুন।
• Cache lock ও fencing আলাদা ব্যবস্থা।

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

Report generation-এ immutable object ও database pointer ব্যবহার করে diagram আঁকুন। কোন step retry-safe এবং কোন orphan file পরে মুছবেন লিখুন।

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

1. TTL থাকলে duplicate সম্ভব?

হ্যাঁ। Worker pause বা দীর্ঘ কাজের সময় lease expire হলে নতুন worker শুরু করতে পারে।

2. Fencing কোথায়?

যে resource side effect গ্রহণ করে সেখানে atomic validation চাই; caller-এর condition একা race ঠেকায় না।

3. Timestamp token হবে?

Clock skew বা rollback-এ monotonic ordering ভাঙতে পারে; trusted sequencer দরকার।

4. Cache lock কী কাজে?

সাধারণ duplicate computation কমাতে; irreversible effect-এর একমাত্র correctness boundary হিসেবে নয়।

5. সব provider মানবে?

না। External API fencing না মানলে idempotency বা reconciliation-এর মতো contract দরকার।

আরও পড়ুন

• Redis distributed lock safety
• Laravel atomic locks