লেসলি ল্যাম্পোর্ট ও বিতরণকৃত সিস্টেম: সময়, ক্রম, সঠিকতা

কেন ল্যাম্পোর্ট আধুনিক বিতরণকৃত সিস্টেমে এখনও প্রাসঙ্গিক

লেসলি ল্যাম্পোর্ট এমন এক গবেষক যার "তাত্ত্বিক" কাজ প্রতিবারই বাস্তব সিস্টেমে বিলম্বহীনভাবে ফিরে আসে। যদি আপনি কখনও কোনও ডাটাবেস ক্লাস্টার, মেসেজ কিউ, ওয়ার্কফ্লো ইঞ্জিন বা এমন কিছু চালান যেটা রিকোশ করে এবং ফেলিওর টেকতে পারে, তাহলে আপনি সেই সমস্যাগুলোর মধ্যে বসবাস করেছেন যেগুলো ল্যাম্পোর্ট নাম দিয়েছেন এবং সমাধান করেছেন।

তার ধারণাগুলো টেকনোলজি-নির্দিষ্ট নয়—এসব সত্যটা বর্ণনা করে যা প্রতিবারই সামনে আসে যখন একাধিক মেশিন এক সিস্টেমের মতো আচরণ করার চেষ্টা করে: ঘড়িগুলো মিলেনা, নেটওয়ার্ক বিলম্বিত বা প্যাকেট হারায়, এবং ফেলিওরগুলো সাধারণ—অসাধারণ নয়।

তিনটি থিম যা আমরা সারাজুড়ে ব্যবহার করবো

সময়: বিতরণকৃত সিস্টেমে "এখন সময় কত?" একটি সরল প্রশ্ন নয়। ফিজিক্যাল ক্লক ড্রিফ্ট করে, এবং বিভিন্ন মেশিন আলাদা ক্রম দেখে।

ক্রম: যখন আপনি একক ঘড়ির উপর নির্ভর করতে পারেন না, তখন আপনাকে নির্ধারণ করতে হবে কোন ইভেন্টগুলো আগে হয়েছে—এবং কখন আপনাকে সবাইকে একই ক্রম মানতে বাধ্য করতে হবে।

সঠিকতা: "এটি সাধারণত কাজ করে" কোনো ডিজাইন নয়। ল্যাম্পোর্ট ক্ষেত্রকে স্পষ্ট সংজ্ঞায় (সেফটি বনাম লাইভনেস) এবং এমন স্পেসিফিকেশনে চাপ দিয়েছেন যেগুলো আপনি কেবল টেস্ট করে নয়, যুক্তি দিয়ে বোঝাতে পারেন।

কী আশা করবেন (কোনও ভারী গাণিতিকতা নেই)

আমরা কনসেপ্ট ও ইন্টারপ্রিটেশনে ফোকাস করব: সমস্যা, স্পষ্টভাবে চিন্তা করার জন্য ন্যূনতম সরঞ্জাম, এবং কিভাবে সেই সরঞ্জামগুলো বাস্তব ডিজাইনে ছাপ ফেলে।

মানচিত্রটা এইরকম:

• কেন কোনো শেয়ার্ড ক্লক না থাকলে ঘটনা-বিশ্বের একটি একক কাহিনী থাকে না
• কিভাবে কারণ-প্রভাব ("happened-before") লজিক্যাল ক্লক ও ল্যাম্পোর্ট টাইমস্ট্যাম্পকে আনে
• কখন পার্শ্বিক ক্রম যথেষ্ট নয় এবং কখন একটি একক টাইমলাইন দরকার
• কিভাবে সম্মতি ও Paxos একটি অর্ডারে সম্মত হওয়ার সঙ্গে সম্পর্কিত
• কেন স্টেট-মেশিন রেপ্লিকেশন কাজ করে যখন অর্ডার শেয়ার করা থাকে
• কিভাবে স্পষ্ট স্পেসিফিকেশন-এ সঠিকতা বলা যায়—এবং TLA+ মত মডেলিং টুলগুলো কীভাবে সাহায্য করে

মূল সমস্যা: শেয়ার্ড ক্লক নেই, একটি একক বাস্তবতা নেই

একটি সিস্টেম "বিতরণকৃত" যখন এটি একাধিক মেশিন দ্বারা গঠিত যা নেটওয়ার্কের মাধ্যমে এক কাজ সমন্বয় করে। সেটি সাধারণ মনে হলেও দুইটি কথা মেনে নিলে জিনিসগুলো জটিল হয়: মেশিনগুলো স্বাধীনভাবে ফেল হতে পারে (পার্শিয়াল ফেলিওর), এবং নেটওয়ার্ক বার্তা বিলম্বিত, হারিয়ে, নকল বা পুনরায় সাজাতে পারে।

একক কম্পিউটারে একটি প্রোগ্রামে সাধারণত আপনি সহজে বলতে পারেন "কি প্রথমে ঘটেছিল।" কিন্তু বিতরণকৃত সিস্টেমে বিভিন্ন মেশিন ভিন্নভাবে ইভেন্টের ক্রম দেখতে পারে—আর দুইটি দৃষ্টিভঙ্গি উভয়েই তাদের লোকাল দৃষ্টিকোণ থেকে সঠিক হতে পারে।

কেন আপনাকে একটি গ্লোবাল ক্লকের উপর ভরসা করা যায় না

সমন্বয়ের সমাধান হিসেবে সবকিছু টাইমস্ট্যাম্প করা লোভজনক, কিন্তু মেশিনগুলোর মধ্যে এমন কোনো একক ক্লক নেই যা আপনি নির্ভর করতে পারেন:

• প্রতিটি সার্ভারের হার্ডওয়্যার ক্লক আলাদা হিসেবে ড্রিফ্ট করে।
• ক্লক সিঙ্ক্রোনাইজেশন (যেমন NTP) বেস্ট-এফর্ট—গ্যারান্টি নয়।
• ভার্চুয়ালাইজেশন, CPU লোড বা পজিং টাইমকে কুড়াতে বা হঠাৎ লাফাতে পারে।

তাই একটি হোস্টে "ইভেন্ট A ঘটেছে 10:01:05.123 এ" আর অন্যে "10:01:05.120" তুলনা করা নির্ভরযোগ্য নয়।

কিভাবে বিলম্ব বাস্তবতাকে ঘুরিয়ে দেয়

নেটওয়ার্ক বিলম্ব আপনি যে দেখেছেন সেটাকে উল্টে দিতে পারে। একটি রাইট প্রথমে পাঠানো হতে পারে কিন্তু পরে পৌঁছায়। একটি রিট্রাই মূলটির পরে পৌঁছাতে পারে। দুইটি ডেটাসেন্টার একই অনুরোধকে বিপরীত ক্রমে প্রসেস করতে পারে।

এটি ডিবাগিংকে অনন্যভাবে বিভ্রান্তিকর করে: বিভিন্ন মেশিনের লগগুলো ভিন্ন কথা বলবে, এবং "টাইমস্ট্যাম্প অনুযায়ী সাজালে" এমন একটি কাহিনী তৈরী হতে পারে যা কখনোই বাস্তবে ঘটেনি।

বাস্তব ফলাফল

যখন আপনি এমন একক টাইমলাইন ধরে নেন যা নেই, আপনি বাস্তব ব্যর্থতা দেখেন:

• দ্বিগুণ প্রসেসিং (রিকোশ-এর পর পেমেন্ট দুটি চার্জ হয়ে যাওয়া)
• অসমঞ্জস্যতা (দুটি ব্যবহারকারী আলাদা করে ও শেষ আইটেমটি সফলভাবে দাবি করা)
• প্রতিশ্রুত ডেটার ওপরে পরে আসা আপডেট ওভাররাইট করে দেয় (প্রকৃত নতুন আপডেট হারিয়ে যায়)

ল্যাম্পোর্টের মূল অন্তদৃষ্টি এখান থেকেই শুরু: যদি আপনি সময় ভাগাভাগি করতে না পারেন, তবে আপনাকে ক্রম সম্পর্কে ভিন্নভাবে যুক্তি করতে হবে।

কারণ-প্রভাব এবং happened-before সম্পর্ক

বিতরণকৃত প্রোগ্রামগুলো ইভেন্ট-এর সমুদয়: প্রতিটি ইভেন্ট কোনো নির্দিষ্ট নোডে ঘটে (প্রক্রিয়া, সার্ভার, বা থ্রেড)। উদাহরণ: “রিকোয়েস্ট গ্রহণ করা”, “ডাটাবেজে লেখা”, বা “বার্তা পাঠানো।” একটি বার্তা নোডগুলোর মধ্যে সংযোগকারী: একটি ইভেন্ট হলো send, আর আরেকটি হলো receive।

ল্যাম্পোর্টের প্রধান ধারণা হলো যে নির্ভরযোগ্য শেয়ার্ড ক্লক না থাকলে সবচেয়ে নির্ভরযোগ্য জিনিস আপনি ট্র্যাক করতে পারেন সেটি হলো কৌসলিকতা—কোন ইভেন্টগুলো অন্য ইভেন্টগুলিকে প্রভাবিত করতে পারে।

happened-before সম্পর্ক (→)

ল্যাম্পোর্ট একটি সহজ নিয়ম সংজ্ঞায়িত করেছেন, যাকে বলা হয় happened-before, লিখিত A → B (ইভেন্ট A ইভেন্ট B-এর আগে ঘটেছে):

• একই প্রক্রিয়ায় ক্রম: যদি A এবং B একই মেশিন/প্রক্রিয়ায় ঘটে এবং A সেই প্রক্রিয়ায় প্রথমে ঘটে, তাহলে A → B।
• বার্তা ক্রম: যদি A হলো "বার্তা m পাঠানো" এবং B হলো "বার্তা m গ্রহণ করা", তবে A → B।
• ট্রান্সিটিভিটি: যদি A → B এবং B → C হয়, তবে A → C।

এই সম্পর্ক আপনাকে একটি পার্শিয়াল অর্ডার দেয়: এটি কিছু জোড়াকে ক্রমিক বলে, কিন্তু সব জোড়াই না।

বাস্তব গল্প: ব্যবহারকারী → রিকোয়েস্ট → DB → ক্যাশ

একজন ব্যবহারকারী "Buy" ক্লিক করে। সেই ক্লিক একটি API সার্ভারে অনুরোধ ট্রিগার করে (ইভেন্ট A)। সার্ভার ডাটাবেজে একটি অর্ডার সারি লেখে (ইভেন্ট B)। লেখাটি শেষ হলে সার্ভার একটি "order created" বার্তা প্রকাশ করে (ইভেন্ট C), ও একটি ক্যাশ সার্ভিস তা গ্রহণ করে ক্যাশ আপডেট করে (ইভেন্ট D)।

এখানে A → B → C → D। ঘড়ি বিভ্রান্ত হলেও বার্তা এবং প্রোগ্রামের কাঠামো বাস্তব কারণ-প্রভাব লিংক তৈরি করে।

"কনকারেন্ট" আসলে কী বোঝায়

দুইটি ইভেন্ট কনকারেন্ট যখন উভয়ের মধ্যে কোনও কারণগত পথ নেই: না (A → B) এবং না (B → A)। কনকারেন্সি মানে "একই সময়" নয়—এর মানে "কোন কারণগত পাথ তাদের সংযুক্ত করে না।" তাই দুইটি সার্ভিস আলাদা করে দাবি করতে পারে তারা "প্রথমে কাজ করেছে," এবং দুজনেই সঠিক হতে পারে যদি না আপনি একটি অর্ডিং নিয়ম যোগ করেন।

লজিক্যাল ক্লক: সহজ ভাষায় ল্যাম্পোর্ট টাইমস্ট্যাম্প

আপনি যদি কখনও একাধিক মেশিনের মধ্যে "কি আগে ঘটেছিল" পুনর্গঠন করার চেষ্টা করে থাকেন, আপনি মূল সমস্যার সম্মুখীন হয়েছেন: কম্পিউটারগুলো সাধারণত একই সিঙ্ক্রোনাইজড ক্লক শেয়ার করে না। ল্যাম্পোর্টের ওয়ার্কঅ্যারাউন্ড হল নিখুঁত সময়ের পেছনে না ছুটে, বরং ক্রম ট্র্যাক করা।

ধারণা: প্রতিটি ইভেন্টের সাথে একটি কাউন্টার

একটি ল্যাম্পোর্ট টাইমস্ট্যাম্প হচ্ছে প্রতিটি গুরুত্বপূর্ণ ইভেন্টে সংযুক্ত একটি সংখ্যা—একটি "ইভেন্ট কাউন্টার"—যা আপনাকে বলবে, "এই ইভেন্টটি সেই ইভেন্টটির আগে ঘটেছিল।" এটি দেয় এমন একটি সঙ্গত উপায় যা ওয়াল-ক্লক অনিশ্বস্ত হলেও ক্রম সম্পর্কে ধারনা দেয়।

দুইটি নিয়ম (এগুলো সত্যিই এটুকুই সরল)

1. স্থানীয়ভাবে ইনক্রিমেন্ট করুন: কোনো ইভেন্ট রেকর্ড করার আগে (যেমন "DB-এ লেখা", "রিকোয়েস্ট পাঠানো", "লগ এন্ট্রি অ্যাপেন্ড করা") আপনার লোকাল কাউন্টার বাড়ান।

2. গ্রহণের সময় max + 1 নিন: যখন আপনি এমন একটি বার্তা গ্রহণ করেন যেটার সাথে পাঠকের টাইমস্ট্যাম্প আছে, তখন আপনার কাউন্টার সেট করুন:

max(local_counter, received_counter) + 1

এরপর সেই মান দিয়ে রিসিভ ইভেন্টটিকে স্ট্যাম্প করুন।

এই নিয়মগুলো নিশ্চিত করে যে টাইমস্ট্যাম্পগুলো কারণকে সম্মান করে: যদি ইভেন্ট A ইভেন্ট B-কে প্রভাবিত করতে পারে (বার্তা প্রবাহের কারণে), তবে A-এর টাইমস্ট্যাম্প অবশ্যই B-এর থেকে ছোট হবে।

ল্যাম্পোর্ট টাইমস্ট্যাম্প কি বলতে পারে—and কি বলতে পারে না

এগুলো কারণ-ক্রম সম্পর্কে বলতে পারে:

• যদি TS(A) < TS(B), A হতেও পারে B-এর আগে ঘটেছে।
• যদি A B-কে কারণ-গতভাবে প্রভাবিত করে, তাহলে নিয়মত TS(A) < TS(B) হবে।

এগুলো বাস্তব সময় সম্পর্কে বলতে পারে না:

• একটি নিম্ন টাইমস্ট্যাম্প মানে সেকেন্ডে আগে ঘটেছে এমনটাও নয়।
• দুটি ইভেন্ট কনকারেন্ট হলেও মেসেজ প্যাটার্নের কারণে আলাদা টাইমস্ট্যাম্প পেতে পারে।

সুতরাং ল্যাম্পোর্ট টাইমস্ট্যাম্প অর্ডারিংয়ের জন্য দুর্দান্ত, ল্যাটেন্সি পরিমাপ বা "সময় কখন ছিল" উত্তর দেওয়ার জন্য নয়।

বাস্তব উদাহরণ: সার্ভিসগুলোর মধ্যে লগ এন্ট্রি অর্ডারিং

ধরা যাক সার্ভিস A সার্ভিস B-কে কল করে, এবং উভয়ই অডিট লগ লেখে। আপনি চাইবেন একক লোগ ভিউ যা কারণ-প্রভাবকে ধরে।

• সার্ভিস A তার কাউন্টার বাড়ায়, "payment শুরু" লগ করে, B-কে টাইমস্ট্যাম্প 42 পাঠায়।
• সার্ভিস B 42 সহ রিকোয়েস্ট পায়, তার কাউন্টার max(local, 42) + 1 করে, ধরুন 43, এবং "কার্ড যাচাই" লগ করে।
• B 44 সহ রেসপন্ড করে; A 44 পেয়ে 45 এ আপডেট করে এবং "payment সম্পন্ন" লগ করে।

এখন, যখন আপনি উভয় সার্ভিসের লগ একত্র করবেন, (lamport_timestamp, service_id) অনুযায়ী সাজালে আপনি একটি স্থির, ব্যাখ্যাযোগ্য টাইমলাইন পাবেন যা আসল প্রভাব-চেইনকে মেলে—অবহেলা করে ওয়াল-ক্লক ড্রিফট বা নেটওয়ার্ক বিলম্ব।

পার্শিয়াল অর্ডার থেকে টোটাল অর্ডার: কখন একটি একক টাইমলাইন দরকার

কারণ-ক্রম আপনাকে একটি পার্শিয়াল অর্ডার দেয়: কিছু ইভেন্ট স্পষ্টভাবে "পূর্বে" আছে, কিন্তু অনেক ইভেন্ট কেবল কনকারেন্ট। এটা বাগ নয়—এটি বিতরণকৃত বাস্তবতার স্বাভাবিক আকার।

পার্শিয়াল অর্ডার: অনেক প্রশ্নের জন্য যথেষ্ট

যদি আপনি ডিবাগ করছেন "কোনটা এতে প্রভাব ফেলতে পারে?" বা এমন নিয়ম জোর দিচ্ছেন যে "একটি রেসপন্স অবশ্যই তার রিকোয়েস্টের পরে আসবে," পার্শিয়াল অর্ডারই আপনি চান। আপনাকে কেবল happened-before এজগুলো সম্মান করতে হবে; বাকিগুলোকে স্বাধীন হিসেবে বিবেচনা করা যায়।

টোটাল অর্ডার: যখন সিস্টেমকে একটি গল্পই বেছে নিতে হবে

কিছু সিস্টেম "দুইটাই ঠিক" মানতে পারে না। তাদের একটি একক ক্রম দরকার—বিশেষত:

• একটি শেয়ার্ড অবজেক্টে রাইটস ("ব্যালান্স সেট করা", "প্রোফাইল আপডেট")
• এমন কমান্ড যা প্রত্যেক জায়গায় একইভাবে প্রয়োগ করা দরকার (স্টেট-মেশিন রেপ্লিকেশন)
• কনফ্লিক্ট রেজলিউশন যেখানে "লাস্ট রাইট উইনস" মানে প্রত্যেক নোডের জন্য একই জিনিস

বিনা-টোটাল অর্ডার থাকলে দুইটি রেপ্লিকা লোকালি সঠিক হলেও গ্লোবালি ভিন্ন হয়ে যাবে: এক জায়গায় A পরে B প্রয়োগ হতে পারে, অন্য জায়গায় B পরে A, আর ফলাফল আলাদা হবে।

কীভাবে আপনি একটি টাইমলাইন পান?

আপনি এমন একটি ব্যবস্থা যোগ করেন যা অর্ডার তৈরি করে:

• একটি সিকোয়েন্সার/লিডার যা প্রতিটি কমান্ডকে মনোটোনিক পজিশন দেয়।
• অথবা কনসেনসাস (যেমন Paxos-শৈলী) যাতে ক্লাস্টারটি পরবর্তী লগ এন্ট্রিতে সম্মত হয়, বিলম্ব ও ফেলিওর থাকা সত্ত্বেও।

যে ট্রেড-অফগুলো এড়ানো যায় না

একটি টোটাল অর্ডার শক্তিশালী, কিন্তু এর কিছু মূল্য আছে:

• ল্যাটেন্সি: কমিট করার আগে সমন্বয়ের জন্য অপেক্ষা করতে হতে পারে।
• থ্রুপুট: একক অর্ডার করা লগ একটি বটলনেক হতে পারে।
• ফেলিওর-অবস্থায় উপলব্ধতা: যদি আপনি পর্যাপ্ত নোডে পৌঁছাতে না পারেন সম্মত হওয়ার জন্য, তাহলে অগ্রগতি বন্ধ হতে পারে নিরাপত্তা রক্ষা করার জন্য।

ডিজাইন চয়েসটি সহজ: যখন সঠিকতার জন্য একটি শেয়ার্ড কাহিনী দরকার, আপনি এটাকে পেতে সমন্বয় খরচ দিবেন।

কনসেনসাস: বিলম্ব ও ফেলিওরের মধ্যে একমত হওয়া

কনসেনসাস হলো একাধিক মেশিনকে এক সিদ্ধান্তে—একটি মানে, এক লিডার, এক কনফিগারেশন—একমত করানোর সমস্যা, যদিও প্রতিটি মেশিন শুধু তার লোকাল ঘটনা এবং যে বার্তা পেয়েছে তা দেখে।

এর কথা সহজ শুনতে কিন্তু মনে রাখবেন কি একটা বিতরণকৃত সিস্টেম তা করতে পারে: বার্তা বিলম্বিত, নকল, পুনরায় সাজানো বা হারিয়ে যায়; মেশিন ক্র্যাশ ও রিস্টার্ট করে; এবং প্রায়ই আপনি পাবেন না "এই নোড অবশ্যই ডাউন"—কনসেনসাস হলো এমন অবস্থায় সম্মতি নিরাপদভাবে করা।

কেন সম্মতি জটিল

যদি দুইটি নোড অস্থায়ীভাবে কথা বলতে না পারে (নেটওয়ার্ক পার্টিশন), প্রতিটি সাইড আলাদাভাবে এগিয়ে যেতে চাইতে পারে। যদি দুই পাশে ভিন্ন ভ্যালু ঠিক হয়, আপনি স্প্লিট-ব্রেইনের সম্মুখীন হতে পারেন: দুই লিডার, দুই কনফিগারেশন, বা দুই প্রতিদ্বন্দ্বী ইতিহাস।

পার্টিশন না থাকলেও কেবল বিলম্বই সমস্যা করে। একটি প্রস্তাব সম্পর্কে নোডটি যখন শুনে, অন্য নোডগুলো ইতিমধ্যেই এগিয়ে যেতে পারে। শেয়ার্ড ক্লক নেই, তাই আপনি "প্রস্তাব A প্রস্তাব B-এর আগে ঘটেছে" নির্ভরযোগ্যভাবে বলতেই পারবেন না কেবল A-র টাইমস্ট্যাম্প দেখে।

বাস্তব সিস্টেমে কনসেনসাস কোথায় দেখা যায়

প্রতিদিন আপনি এটাকে "কনসেনসাস" বলবেন না, কিন্তু এটি সাধারণ সার্ভিসে উৎসর্গ হয়:

• লিডার নির্বাচন (এখন কে দায়িত্বে?)
• রেপ্লিকেটেড লগস (শেয়ারড ইতিহাসে পরবর্তী এন্ট্রি কী?)
• কনফিগারেশন পরিবর্তন (কোন নোডগুলো ভোট/কমিট করতে পারবে?)

প্রতিটি ক্ষেত্রে, সিস্টেমকে এমন এক ফলাফল দরকার যা সবাই সম্মিলিতভাবে সম্মত হতে পারে, বা অন্তত এমন একটি নিয়ম যাতে দুটি সংঘর্ষকারী ফলাফলই বৈধ নাহয়।

Paxos: ল্যাম্পোর্টের উত্তর

ল্যাম্পোর্টের Paxos হলো এই "নিরাপদ সম্মতি" সমস্যার মৌলিক সমাধান। মূল ধারণা কোনো জাদুকরী টাইমআউট বা পারফেক্ট লিডার নয়—এটি নিয়মগুলোর একটি সেট যা নিশ্চিত করে কেবল একটি মান টিই চয়ন করা যাবে, বার্তা দেরি করে বা নোড ফেল হলে ও।

Paxos সেফটি ("দুটি ভিন্ন মান কখনোই নির্বাচিত হবে না") এবং প্রগ্রেস ("অবশেষে কিছু নির্বাচিত হবে") আলাদা করে দেয়, যা এটাকে ব্যবহারিক করে তোলে: বাস্তব পারফরম্যান্সের জন্য টিউন করা যায় যখন মুল গ্যারান্টি অবিচল থাকে।

Paxos, যে মাথাব্যথা ছাড়া: মূল সেফটি ইন্টুইশন

Paxos-এর খ্যাতি পড়তে কষ্টকর, কিন্তু অনেকটা কারণ হলো "Paxos" একরকম এক বাক্যের অ্যালগরিদম নয়। এটা নিকট সম্পর্কিত প্যাটার্নের একটি পরিবার যা গ্রুপকে একমত করায়—বার্তা দেরি, নকল বা সাময়িক ফেলিওর থাকলেও।

কাস্ট: প্রপোজার, অ্যাক্সেপ্টর, এবং কোয়ারাম

একটি সহায়ক মানসিক মডেল হল "প্রস্তাব দেয়া" কে আলাদা করা এবং "যাকে যাচাই করে" কে আলাদা করা।

• প্রপোজার একটি মান চয়ন করাতে চায় (উদাহরণ: "পরবর্তী লগ এন্ট্রি X")।
• অ্যাক্সেপ্টর প্রস্তাবগুলোর উপর ভোট করে।
• কোয়ারাম হল "প্রচুর অ্যাক্সেপ্টর" যাতে অগ্রগতি সম্ভব—সাধারণত একটি সংখ্যাগরিষ্ঠতা।

একটি মৌলিক ধারণা: যে কোনো দুইটি সংখ্যাগরিষ্ঠতা ওভারল্যাপ করে। সেই ওভারল্যাপে সেফটি বাস করে।

সেফটির লক্ষ্য: দুইটি ভিন্ন মান কখনো নির্ধারণ নয়

Paxos সেফটি সহজভাবে বলা যায়: একবার সিস্টেম কোনো একটি মান সিদ্ধান্তে পৌঁছায়, তখন আর কখনো সেটির বিরুদ্ধে অন্য মান সিদ্ধান্তে পৌঁছানো যাবে না—কোনো স্প্লিট-ব্রেইন সিদ্ধান্ত নয়।

মূল ইন্টুইশন হল প্রস্তাবগুলো সংখ্যায়িত হয় (ব্যালট আইডি হিসেবে ভাবুন)। অ্যাক্সেপ্টররা পুরনো নম্বরের প্রস্তাবগুলো উপেক্ষা করার প্রতিশ্রুতি দেয় একবার তারা নতুন নম্বর দেখলে। এবং যখন একটি নতুন প্রপোজার নতুন নম্বর নিয়ে চেষ্টা করে, প্রথমে সে একটি কোয়ারামকে জিজ্ঞেস করে তারা আগে কী গ্রহণ করেছে।

কোয়ারাম ওভারল্যাপ থাকার কারণে, নতুন প্রপোজার অবশ্যই এমন একটি অ্যাক্সেপ্টর থেকে শুনবে যে "সর্বশেষে যে মানটি গৃহীত হয়েছে" তা মনে রাখে। নিয়ম হলো: যদি কোয়ারামের মধ্যে কেউ কিছু গ্রহণ করে থাকে, আপনাকে সেই মানই প্রস্তাব করতে হবে (অথবা তাদের মধ্যে সবচেয়ে নতুনটি)। ওই বাধাই দুইটি ভিন্ন মান নির্ধারিত হওয়া থামায়।

লাইভনেস, সংক্ষেপে

লাইভনেস মানে সিস্টেম অবশেষে কিছু সিদ্ধান্তে পৌঁছায় যদি যথাযথ পরিস্থিতি থাকে (উদাহরণ: একটি স্থিতিশীল লিডার উদয় হয় এবং নেটওয়ার্ক শেষমতো বার্তা পৌঁছে দেয়)। Paxos বিশৃঙ্খলায় দ্রুততার গ্যারান্টি দেয় না; এটি অস্পষ্টতায় সঠিকতা দেয়, এবং যখন বিষয়গুলো স্থিতিশীল হয় তখন অগ্রগতি ঘটবে।

স্টেট মেশিন রেপ্লিকেশন: শেয়ার্ড অর্ডারের মাধ্যমে সঠিকতা

স্টেট মেশিন রেপ্লিকেশন (SMR) হচ্ছে অনেক "হাই-অ্যাভেইলেবিলিটি" সিস্টেমের কাজের ঘাট: একক সার্ভার সিদ্ধান্ত নেওয়ার বদলে আপনি একাধিক রেপ্লিকাতে একই কমান্ড সিকোয়েন্স চালান।

রেপ্লিকেটেড লগ ধারণা

কেন্দ্রে থাকে একটি রেপ্লিকেটেড লগ: কমান্ডের একটি অর্ডার্ড তালিকা যেমন "put key=K value=V" বা "A থেকে B-তে $10 পাঠাও"। ক্লায়েন্টরা কমান্ড প্রতিটি রেপ্লিকা-কে আলাদা পাঠায় না; তারা গ্রুপকে সাবমিট করে, এবং সিস্টেম সেই কমান্ডগুলোর একই অর্ডার নিয়ে একমত হয়, তারপর প্রতি রেপ্লিকা লোকালি সেগুলো প্রয়োগ করে।

কেন অর্ডারিং আপনাকে সঠিকতা দেয়

যদি প্রতিটি রেপ্লিকা একই সূচনাবর্তী অবস্থা থেকে শুরু করে এবং একই কমান্ডগুলো একই ক্রমে এক্সিকিউট করে, তাহলে তারা একই অবস্থায় পৌঁছাবে। এটি মূল সেফটি ইন্টুইশন: আপনি বহু মেশিনকে টাইম দ্বারা সিঙ্ক করতে চেষ্টা করছেন না; আপনি নির্ধারিততা ও শেয়ার্ড অর্ডারের মাধ্যমে তাদের একই করে তুলছেন।

এ কারণেই কনসেনসাস (Paxos/Raft-স্টাইল প্রোটোকল) প্রায়ই SMR-র সঙ্গে জোড়া হয়: কনসেনসাস নির্ধারণ করে পরবর্তী লগ এন্ট্রি, আর SMR সেই সিদ্ধান্তকে রেপ্লিকাগুলোর মধ্যে একটি সঙ্গতিপূর্ণ অবস্থায় রূপান্তর করে।

বাস্তবে কোথায় দেখা যায়

• কনফিগারেশন ও লিডার-নির্বাচনের জন্য কোঅর্ডিনেশন সার্ভিস
• রেপ্লিকেটেড রাইট-অ্যাওয়ে লগ সহ ডাটাবেস
• এমন মেসেজ সিস্টেম যা কঠোর পার্টিশন অর্ডারিং দাবি করে

ইঞ্জিনিয়ারদের উপেক্ষা করতে না পারার বাস্তব উদ্বেগ

লগ অনন্তকাল বাড়ে যদি আপনি এটি ম্যানেজ না করেন:

• স্ন্যাপশট: সময়ে সময়ে বর্তমান অবস্থা ক্যাপচার করে নতুন নোডকে পুরো ইতিহাস পুনরায় চালানোর দরকার ছাড়াই ক্যাচ-আপ করানো।
• লগ কম্প্যাকশন: একটি স্ন্যাপশটে প্রতিফলিত এবং আর দরকারি না এমন পুরনো এন্ট্রিগুলো নিরাপদভাবে বাতিল করা।
• মেম্বারশিপ পরিবর্তন: রেপ্লিকা যোগ/বিয়োগও অর্ডার করা দরকার, নাহলে বিভিন্ন নোড কেউ গ্রুপে আছেন না নিয়ে দ্বন্দ্ব সৃষ্টি হতে পারে।

SMR কোনো জাদু নয়; এটি একটি শৃঙ্খলাবদ্ধ উপায় যাতে "অর্ডারে সম্মতি" কে "অবস্থায় সম্মতি" তে পরিণত করা যায়।

সঠিকতা: সেফটি, লাইভনেস, এবং পরিষ্কার স্পেসিফিকেশন লেখা

বিতরণকৃত সিস্টেম অদ্ভুতভাবে ব্যর্থ হয়: বার্তা দেরিতে আসে, নোড রিস্টার্ট করে, ঘড়ি一致 করে না, নেটওয়ার্ক বিভক্ত হয়। "সঠিকতা" কোনো অনুভূতি নয়—এটি এমন কিছু প্রতিশ্রুতি যা আপনি স্পষ্টভাবে বলা যায় এবং তারপর প্রতিটি পরিস্থিতিতে পরীক্ষা করা যায়, এমনকি ফেলিওর সহ।

সেফটি বনাম লাইভনেস (কনক্রীট উদাহরণসহ)

সেফটি মানে "কখনোই খারাপ কিছু হবে না।" উদাহরণ: একটি রেপ্লিকেটেড কী-ভ্যালু স্টোর-এ একই লগ ইনডেক্সের জন্য দুইটি ভিন্ন ভ্যালু কখনই কমিট হওয়া যাবে না। আরেকটি: একটি লক সার্ভিস একই লক একসাথে দুইটি ক্লায়েন্টকে কখনই দেবে না।

লাইভনেস মানে "অবশেষে ভালো কিছু হবে।" উদাহরণ: যদি সংখ্যাগরিষ্ঠ রেপ্লিকা আপ থাকে এবং নেটওয়ার্ক শেষমেষ বার্তা পৌঁছায়, একটি রাইট অনুরোধ অবশেষে সম্পন্ন হবে। একটি লক অনুরোধ শেষমেষ হ্যাঁ বা না পাবে (অনন্ত অপেক্ষা নয়)।

সেফটি বিরোধাবোধ প্রতিহত করে; লাইভনেস স্থায়ী স্টল এড়ায়।

ইনভেরিয়েন্ট: আপনার অপ্রতিরোধ্য শর্তাবলী

একটি ইনভেরিয়েন্ট হল একটি শর্ত যা সবসময়, প্রত্যেকটি পৌঁছনীয় স্টেটে বজায় থাকতে হবে। উদাহরণ:

• "প্রতিটি লগ ইনডেক্সে সর্বোচ্চ একটি কমিটেড ভ্যালু আছে।"
• "একজন লিডারের টার্ম নম্বর কখনই হ্রাস পায় না।"

যদি কোনও ইনভেরিয়েন্ট ক্র্যাশ, টাইমআউট, রিট্রাই বা পার্টিশনের সময় ভাঙে, তবে সেটি আসলে-enforced ছিল না।

এখানে 'প্রমাণ' মানে কী

একটি প্রমাণ হল এমন একটি যুক্তি যা সমস্ত সম্ভাব্য এক্সিকিউশন কভার করে, কেবল "নরম পাথ" নয়। আপনি প্রতিটি কেস নিয়ে যুক্তি করবেন: বার্তা লস, ডুপ্লিকেশন, পুনরায় সাজানো; নোড ক্র্যাশ ও রিস্টার্ট; প্রতিদ্বন্দ্বী লিডার; ক্লায়েন্ট রিট্রাই।

স্পেসিফিকেশনগুলো আচমকা আচরণ রোধ করে

একটি স্পষ্ট স্পেসিফিকেশন রাষ্ট্র, অনুমোদিত অ্যাকশন এবং প্রয়োজনীয় বৈশিষ্ট্যগুলি সংজ্ঞায়িত করে। এটি "সিস্টেম কনসিস্টেন্ট হওয়া উচিত" মত অস্পষ্ট চাহিদাগুলোকে প্রতিবার বিভ্রান্তিকর প্রত্যাশায় রূপান্তরিত হওয়া থেকে রোধ করে। স্পেসিফিকেশন আপনাকে বলতে বাধ্য করে পার্টিশনকালে কী হবে, "কমিট" কী মানে, এবং ক্লায়েন্টরা কী উপর নির্ভর করতে পারে—প্রোডাকশনে কঠিন অভিজ্ঞতার বদলে আগে থেকেই।

তত্ত্ব থেকে বাস্তবে: TLA+ দিয়ে মডেলিং

ল্যাম্পোর্টের একটি সবচেয়ে ব্যবহারিক শিক্ষা হচ্ছে যে আপনি (এবং প্রায়ই উচিত) কোডের থেকে উচ্চতর পর্যায়ে একটি বিতরণকৃত প্রটোকল ডিজাইন করুন। থ্রেড, RPC এবং রিট্রাই লুপ নিয়ে চিন্তা করার আগে আপনি সিস্টেমের নিয়মগুলো লিখে ফেলতে পারেন: কোন অ্যাকশনগুলো অনুমোদিত, কোন রাষ্ট্র পরিবর্তিত হতে পারে, এবং কী কখনোই ঘটবে না।

TLA+ কী কাজে লাগে

TLA+ হলো একটি স্পেসিফিকেশন ভাষা এবং মডেল-চেকিং টুলকিট যা সমান্তরাল ও বিতরণকৃত সিস্টেম বর্ণনা করার জন্য ব্যবহার করা হয়। আপনি সিস্টেমের একটি সহজ, গাণিতিক-সদৃশ মডেল লিখেন—স্টেট এবং ট্রানজিশন—সাথে আপনি যে বৈশিষ্ট্যগুলো চান (উদাহরণ: "এক্স-লিডার সর্বোচ্চ একজনই" বা "একটি কমিটেড এন্ট্রি কখনো অদৃশ্য হবে না").

তারপর মডেল-চেকার সম্ভাব্য ইন্টারলিভিং, বার্তা বিলম্ব ও ফেলিওর এক্সপ্লোর করে একটি কাউন্টারএক্সাম্পল খুঁজে বের করে: একটি বাস্তব ধাপ-ধারা যা আপনার প্রপার্টি ভাঙে। সভ্যতার মধ্যে এজেন্সি-ভিত্তিক বিতর্ক করার বদলে আপনি একটি নির্বাহযোগ্য যুক্তি পান।

একটি বাগ যা মডেল ধরে করতে পারে

ধরুন রেপ্লিকেটেড লগে একটি "কমিট" ধাপ। কোডে সহজেই আপনি এমন ভুল করে দিতে পারেন যে বিরল টাইমিংয়ে দুইটি নোড একই ইনডেক্সে দুইটি ভিন্ন এন্ট্রি কমিট করে দেবে।

একটি TLA+ মডেল নিম্নরূপ ট্রেস প্রকাশ করতে পারে:

• নোড A কোয়ারাম শুনে ইনডেক্স 10-এ এন্ট্রি X কমিট করে।
• নোড B (স্টেইল ডাটা নিয়ে) কোয়ারাম গঠন করে এবং ইনডেক্স 10-এ এন্ট্রি Y কমিট করে।

এটি একটি সেফটি ভায়োলেশন—একটি বিরল অথচ মারাত্মক ঘটনা যা প্রডাকশনে মাসে একবার ঘটতে পারে, কিন্তু মডেলিং-এ দ্রুত ধরা পড়ে। অনুরূপ মডেলগুলো প্রায়ই হারানো আপডেট, ডাবল-অ্যাপ্লাই, বা "অ্যাক করে কিন্তু টেকসই নয়" পরিস্থিতি ধরতে পারে।

মডেলিং কখন মূল্যবান

TLA+ সবচেয়ে মূল্যবান হয় ক্রিটিকাল কোঅর্ডিনেশন লজিকের জন্য: লিডার নির্বাচন, মেম্বারশিপ পরিবর্তন, কনসেনসাস-মতো ফ্লো—যেখানেই অর্ডার ও ফেলিওর হ্যান্ডলিং ইন্টারঅ্যাক্ট করে। যদি একটি বাগ ডেটা নষ্ট করে বা ম্যানুয়াল রিকভারি দরকার করায়, একটি ছোট মডেল সাধারণত পরে বাগ ফিক্স করার চেয়ে সস্তা।

অভিউয়ার্কফ্লো: একটি হালকা স্পেস লিখুন (এমনকি অনানুষ্ঠানিক), তারপর সিস্টেমটি ইমপ্লিমেন্ট করুন এবং স্পেসিফিকেশন-ইনভারিয়েন্ট থেকে টেস্ট জেনারেট করুন। Koder.ai-এর মত প্ল্যাটফর্ম এখানে সহায়ক হতে পারে: সহজে সার্ভিস স্ক্যাফোল্ডিং, ডিপ্লয়/হোস্টিং, স্ন্যাপশট/রোলব্যাক এবং সোর্স-কোড এক্সপোর্ট দিয়ে দ্রুত ইটারেট করা যায়।

নির্ভরযোগ্য সিস্টেম নির্মাণ ও অপারেট করার জন্য ব্যবহারিক টেকওয়েস

ল্যাম্পোর্টের বরাদ্দ হলো একটি মানসিকতা: সময় ও অর্ডারিংকে আপনি মডেল হিসেবে বিবেচনা করবেন, দেয়াল-ঘড়ি থেকে নেওয়া অনুমান নয়। এই মানসিকতা প্রতিদিনের অভ্যাসে পরিণত করলে আপনি সোমবার থেকে প্রয়োগ করতে পারবেন।

তত্ত্বকে প্রতিদিনের ইঞ্জিনিয়ারিংয়ে রূপান্তর করুন

যদি বার্তা বিলম্বিত, নকল বা অর্ডারবিহীন থাকতে পারে, প্রতিটি ইন্টারঅ্যাকশনকে সেই অবস্থায় নিরাপদ করে ডিজাইন করুন।

• ডিফল্টভাবে আইডেম্পটেন্ট করা: "আবার করুন" ক্ষতিকর না করে দিন। পেমেন্ট, প্রোভিশনিং বা যেকোনো রাইট-এ আইডেম্পটেন্সি কী ব্যবহার করুন।
• রিট্রাই সহ ডেডুপ্লিকেশন: রিট্রাই প্রয়োজনীয়, কিন্তু ডেডুপ ছাড়া দ্বিগুণ-রাইট হবে। রিকোয়েস্ট আইডি ট্র্যাক করে "আগেই প্রসেস করা হয়েছে" মার্কার রাখুন।
• অ্যাট-লিস্ট-ওয়ান ডেলিভারি + এক্স্যাক্টলি-ওয়ান ইফেক্টস: নেটওয়ার্ক দুবার ডেলিভারি করতে পারে—আপনি নিশ্চিত করুন স্টেট পরিবর্তন এক্স্যাক্টলি-ওয়ান।

টাইমআউট ও ক্লক নিয়ে সাবধান থাকুন

টাইমআউট কোনো সত্য নয়; এটা একটি পলিসি। একটি টাইমআউট কেবল বলে "আমি সময়মত উত্তর পাইনি," নয় "অন্যপাশ কাজ করেনি।" দুইটি বাস্তব ইমপ্লিকেশন:

• টাইমআউটকে চূড়ান্ত ফেল হিসেবে ধরবেন না। ক্ষতিপূরণ ও পুনরায় মিলানোর পথ ডিজাইন করুন।
• নোডগুলোর মধ্যে ইভেন্ট অর্ডার করতে লোকাল ক্লক ব্যবহার এড়ান। সিকুয়েন্স নম্বর, মনোটোনিক কাউন্টার বা স্পষ্ট কারণগত মেটাডেটা (যেমন "এই আপডেট ভার্সন X কে supersede করে") ব্যবহার করুন।

কারণ-সম্মত অবজার্ভেবিলিটি

ভাল ডিবাগিং টুলগুলো কেবল টাইমস্ট্যাম্প নয়, অর্ডারিং এনকোড করে।

• ট্রেস আইডি সব জায়গায়: প্রতিটি হপ ও লগ লাইনে করেলেশন/ট্রেস আইডি প্রোপাগেট করুন।
• লগে কারণগত ক্লু: বার্তা আইডি, প্যারেন্ট রিকোয়েস্ট আইডি, এবং সিদ্ধান্ত নেওয়ার সময় "আমি কি মনে করছিলাম সর্বশেষ ভার্সন" উল্লেখ করুন।
• ডিটারমিনিস্টিক রিপ্লে: ইনপুট (কমান্ড) রেকর্ড করুন যাতে আপনি বিহেভিয়ার রিপ্লে করে যাচাই করতে পারেন এটা টাইমিং-ডিপেন্ডেন্ট না লজিক-ডিপেন্ডেন্ট।

শিপ করার আগে জিজ্ঞেস করার ডিজাইন প্রশ্নগুলো

বিতরণকৃত ফিচার যোগ করার আগে কিছু প্রশ্ন জোর করে পরিষ্কার করুন:

1. একই রিকোয়েস্ট দুবার প্রসেস হলে কী হবে?
2. আমাদের কী অর্ডিং প্রয়োজন (যদি থাকে), এবং কোথায় এটি এনফোর্স করা হয়?
3. কোন ফেলগুলো "নিরাপদ" (কোনো খারাপ অবস্থা নয়) বনাম "নোংরা" (ইউজার-কনফিউশন) বনাম "চুপচাপ" (লুকানো করাপশন)?
4. পার্শিয়াল আউটেজ বা নেটওয়ার্ক স্প্লিটের পরে রিকভারি পাথ কী?
5. প্রডাকশনে happened-before গল্প পুনর্গঠনের জন্য আমরা কী লগ করবো?

এই প্রশ্নগুলোর উত্তর পিএইচডি ছাড়াইও পাওয়া যায়—শুধু অর্ডারিং ও সঠিকতাকে প্রোডাক্ট দায়িত্ব হিসেবে বিবেচনা করার শৃঙ্খলা লাগবে।

উপসংহার ও পরবর্তী ধাপ

ল্যাম্পোর্টের স্থায়ী উপহার হলো এমন এক ভাবার উপায় যখন সিস্টেমগুলো ঘড়ি ভাগ করে না এবং স্বয়ংক্রিয়ভাবে "কি ঘটেছে" নিয়ে একমত নয়। নিখুঁত সময়ের পেছনে ছুটে যাওয়ার বদলে আপনি কারণ-প্রভাব ট্র্যাক করেন (কি কি কে প্রভাবিত করতে পারে), এটিকে লজিক্যাল সময় দিয়ে উপস্থাপন করেন (ল্যাম্পোর্ট টাইমস্ট্যাম্প), এবং—যখন প্রোডাক্ট একটি একক ইতিহাস দাবি করে—সম্মতি তৈরি করেন যেন প্রতিটি রেপ্লিকা একই ক্রমের সিদ্ধান্ত প্রয়োগ করে।

এই থ্রেডটি একটি ব্যবহারিক ইঞ্জিনিয়ারিং মনোভাবের দিকে নিয়ে যায়:

আগে স্পেসিফাই করুন, তারপর নির্মাণ

আপনি যা কখনওই ঘটতে দেবেন না (সেফটি) এবং যা অবশেষে ঘটতে হবে (লাইভনেস) লিখে ফেলুন। তারপর সেই স্পেসিফিকেশনের প্রতি ইমপ্লিমেন্ট করুন, এবং সিস্টেমটিকে বিলম্ব, পার্টিশন, রিট্রাই, ডুপ্লিকেট বার্তা, এবং নোড রিস্টার্টের মধ্যে টেস্ট করুন। অনেক "রহস্যময় আউটেজ" আসলে এই ধরনের স্পষ্ট না-করা স্টেটমেন্টের ফল।

পরবর্তী শেখার ধাপ (সংক্ষিপ্ত এবং বোধগম্য)

• Lamport-এর "Time, Clocks, and the Ordering of Events in a Distributed System" পড়ুন এবং happened-before ধারণা অন্তর্যত্ব করুন।
• "Paxos Made Simple" স্কিম করুন সেফটি ইন্টুইশন ধরতে: একবার একটি মান নির্বাচিত হলে ভবিষ্যত অগ্রগতি তা উল্টে ফেলতে পারে না।
• একটি TLA+ ইন্ট্রো টক দেখুন, তারপর একটি ছোট প্রোটোকল (একটি লক সার্ভিস বা দুই-রেপ্লিকা রেজিস্টার) মডেল করে চেক করুন।

একটি হাতে-কলমে অনুশীলন

আপনি যে কম্পোনেটটির দায়িত্বে আছেন, একটি এক পাতার "ফেলিওর কনট্রাক্ট" লিখুন: নেটওয়ার্ক ও স্টোরেজ সম্পর্কে আপনি কী অনুমান করেন, কোন অপারেশনগুলো আইডেম্পটেন্ট, এবং আপনি কী অর্ডারিং গ্যারান্টি প্রদান করেন।

আরও বাস্তব করতে, একটি ছোট "অর্ডারিং ডেমো" সার্ভিস তৈরি করুন: একটি রিকোয়েস্ট API যা কমান্ড লগ-এ অ্যাপেন্ড করে, একটি ব্যাকগ্রাউন্ড ওয়ার্কার যা সেগুলো প্রয়োগ করে, এবং একটি অ্যাডমিন ভিউ যা কারণগত মেটাডেটা ও রিট্রাই দেখায়। Koder.ai-তে এটি দ্রুত স্কাফোল্ড করে পরীক্ষা-নিরীক্ষা করা যায়—স্কাফোল্ডিং, ডিপ্লয় এবং স্ন্যাপশট রেখে ট্রায়াল করাটা সুবিধাজনক হতে পারে।

ভালভাবে করা হলে, এই ধারণাগুলো আউটেজ কমায় কারণ অনেক আচরণ আর ইমপ্লিসিট থাকে না। তারা যুক্তি সহজ করে: আপনি সময় নিয়ে তর্ক করা বন্ধ করেন এবং পরিবর্তে প্রমাণ করেন অর্ডার, সম্মতি, এবং সঠিকতা আপনার সিস্টেমের জন্য আসলে কী অর্থ রাখে।