Ticketing Raft پیرامیٹرز
| آئٹم | قدر |
|---|---|
| ہارٹ بیٹ وقفہ | 500ms (cluster_heartbeat_ms) |
| بے جوابی قرار دینے کا وقت | 2000ms (cluster_election_timeout_ms) — ہارٹ بیٹ اتنی دیر رکے تو قائد مر چکا سمجھا جاتا ہے |
| انتخاب شروع ہونے کا اصل وقفہ | 1750-2000ms — ہر نوڈ پر بے ترتیب طور پر بکھرا ہوا تاکہ بیک وقت امیدوار بننا (split vote) نہ ہو۔ سب سے بڑی قدر ہی وہ بے جوابی کا وقت ہے جو سیٹ کیا گیا ہے |
| قائد کی ناکامی پر کلائنٹ کا رکنا | ماپا گیا: بے جوابی کا وقت + 0.3-0.5 سیکنڈ (ڈیفالٹ پر تقریباً 2.3-2.5 سیکنڈ) — تشخیص کے بعد ایک بار redirect |
| نوڈز کی تعداد | 3 یا 5 (کنفیگ لوڈ پر نافذ — کوئی اور تعداد بوٹ ہونے سے انکار کرتی ہے) |
| نوڈ ID | cluster_peers فہرست میں اپنی (cluster_self) پوزیشن — اسی لیے فہرست کی ترتیب ہر نوڈ پر یکساں ہونی چاہیے |
| Bootstrap | آغاز کے 500ms بعد، ہر نوڈ ایک ہی ممبرشپ کے ساتھ initialize ہوتا ہے — اگر پہلے سے initialized کلسٹر میں شامل ہو رہا ہو تو نظر انداز |
| لاگ اسٹوریج | میموری میں (volatile) — دوبارہ شروع ہونے والا نوڈ نقل/اسنیپ شاٹ سے بحال ہوتا ہے |
| lease میعاد ختم ہونے کی تشخیص | قائد ہر 100ms میں جانچتا ہے اور Expire کو اتفاقِ رائے سے کمٹ کرتا ہے |
wait ٹائم آؤٹ کی باریکی | انتظار کا ٹائم آؤٹ (T) بھی اسی 100ms ٹک پر طے ہوتا ہے — یہ 100ms تک دیر سے آ سکتا ہے |
| قائد بدلنے کی اطلاع | قائد بدلنے پر جڑے ہوئے تمام کلائنٹس کو فوراً L بھیجا جاتا ہے |
ہارٹ بیٹ اور بے جوابی کا وقت منتخب کرنا
دونوں قدروں کو ترتیب کے cluster_heartbeat_ms اور cluster_election_timeout_ms سے ایڈجسٹ کیا جاتا ہے۔ بے جوابی کا وقت (T) ہی وہ دورانیہ ہے جتنی دیر قائد کی ناکامی پر سروس رکی رہتی ہے؛ اس کے برعکس اگر یہ ضرورت سے زیادہ چھوٹا ہو تو زندہ قائد کو مردہ سمجھ کر غیر ضروری انتخابات ہونے لگتے ہیں۔
| ہارٹ بیٹ / T | تشخیص کا وقفہ | قائد kill پر بدترین تاخیر (ماپی گئی) | تجویز کردہ ماحول |
|---|---|---|---|
| 100ms / 600ms | 450-600ms | تقریباً 0.9 سیکنڈ | ایک ہی ریک·ایک ہی AZ، بہت مستحکم latency |
| 100ms / 1000ms | 750-1000ms | تقریباً 1.2 سیکنڈ | ایک ہی AZ |
| 250ms / 2500ms | 1875-2500ms | تقریباً 2.8 سیکنڈ | ملٹی-AZ |
| 500ms / 2000ms | 1750-2000ms | تقریباً 2.4 سیکنڈ | ڈیفالٹ — ملٹی-AZ میں توازن |
| 500ms / 5000ms | 3750-5000ms | تقریباً 5.3 سیکنڈ | کراس-ریجن، یا ایسا ماحول جہاں latency بہت اتار چڑھاؤ کرے |
- عام حالات میں پروسیسنگ کی تاخیر ان قدروں سے غیر متعلق ہے (ماپے گئے p50 میں کوئی تبدیلی نہیں) — یہ صرف ناکامی کے وقت بحالی کا دورانیہ طے کرتی ہیں۔
- follower کے مرنے کی صورت میں کسی بھی قدر پر کلائنٹ متاثر نہیں ہوتا۔ اوپر والی تاخیر صرف قائد کے مرنے پر ہوتی ہے۔
- پابندیاں:
cluster_election_timeout_msکم از کم 600ms، اور ہارٹ بیٹ کا کم از کم 4 گنا ہونا چاہیے۔ (لوڈ کے دوران ایک بار کی scheduling تاخیر دو ہارٹ بیٹس مکمل نگل جانے کا مشاہدہ کیا گیا ہے۔)
نوڈز کی تعداد 3 یا 5 کیوں ہے
کمٹ کے لیے اکثریت درکار ہے۔ جفت تعداد کی ترتیب صرف لاگت بڑھاتی ہے بغیر خرابی برداشت کرنے کی صلاحیت بڑھائے، اس لیے سرور اسے مسترد کرتا ہے۔
| نوڈز کی تعداد | اکثریت | بیک وقت برداشت کی جانے والی ناکامیاں |
|---|---|---|
| 2 | 2 | 0 — ایک ناکامی سے کلسٹر رک جاتا ہے۔ سنگل موڈ سے بہتر نہیں |
| 3 | 2 | 1 |
| 4 | 3 | 1 — 3 نوڈز جیسا ہی، بس لاگت زیادہ |
| 5 | 3 | 2 |
ناکامی کے رویے کا خلاصہ
| صورتحال | رویہ |
|---|---|
| غیر-قائد نوڈ کو کلائنٹ کی درخواست | M (قائد کا پتہ)، یا اگر قائد معلوم نہ ہو تو E no_leader |
| قائد کی ناکامی | 500-1000ms میں نیا قائد منتخب۔ اس دوران درخواستیں E no_leader پاتی ہیں → کلائنٹ دوبارہ کوشش کرتا ہے |
| قائد کی تبدیلی کا لمحہ | زیر التوا حصول کی درخواستیں M/E no_leader سے صاف کی جاتی ہیں، اور کلائنٹ نئے قائد کے خلاف دوبارہ کوشش کرتا ہے |
| نوڈ کا دوبارہ آغاز | خالی حالت میں بوٹ → پیئر کی لاگ نقل/اسنیپ شاٹ سے پکڑتا ہے |
| اکثریت کا نقصان | کمٹ ناممکن → تحریر رک جاتی ہے (حفاظت پہلے)، اکثریت بحال ہوتے ہی خودکار طور پر دوبارہ شروع |
اصطلاحات
- quorum — کل نوڈز کے نصف سے زیادہ (3 میں سے 2، یا 5 میں سے 3)۔ چونکہ کسی بھی فیصلے کے لیے quorum کی رضامندی درکار ہے، دو الگ ہو جانے والے گروہ کبھی بیک وقت متضاد فیصلے کمٹ نہیں کر سکتے۔
- election timeout — وہ وقت جس تک ایک فالوور بغیر ہارٹ بیٹ کے انتظار کرتا ہے اس سے پہلے کہ یہ نتیجہ اخذ کرے کہ قائد مر چکا ہے اور انتخاب شروع کرے۔ ہر نوڈ کے لیے بے ترتیب (randomized) ہوتا ہے تاکہ بیک وقت امیدوار بننے کا امکان کم ہو۔