قفل توزیع‌شده و انتخاب رهبر
قفل توزیع‌شده با Redis و انتخاب رهبر با Zookeeper — هماهنگی سرورها در سیستم توزیع‌شده
مشکل: دو سرور، یک کار!
«هر شب بکاپ بگیر» روی ۳ سرور زمان‌بندی شده → سه بکاپ هم‌زمان! یا: دو کاربر آخرین بلیط را هم‌زمان می‌خرند!
در تک‌پروسه: lock ساده. در سیستم توزیع‌شده؟ قفل توزیع‌شده لازم است!
قفل با Redis — SET NX
SET lock:backup "server1" NX EX 30
NX: فقط اگر وجود ندارد (atomic!)
EX 30: انقضا ۳۰ ثانیه (سرور مرد = قفل آزاد!)- ✓ موفق = قفل مال تو؛ کار کن
- ✗ موجود = کسی دیگر دارد؛ صبر/رها
خطرات ظریف
- انقضا زودهنگام: کار طولانی شد، قفل منقضی شد، دیگری گرفت! → تمدید (watchdog) یا fencing token
- آزادسازی اشتباه: قفل منقضی و دیگری گرفته؛ من DELETE می‌کنم = قفل «او» را! → چک مقدار قبل حذف (Lua atomic)
- Redlock: قفل روی چند Redis مستقل برای اطمینان — جنجال‌برانگیز (کلمی بحث کرده!)
انتخاب رهبر (Leader Election)
الگوی رایج: یک «رهبر» بین نودها که کارهای هماهنگی را انجام دهد (نوشتن، زمان‌بندی). رهبر مرد؟ بقیه رهبر جدید!
با Zookeeper/etcd:
- هر نود یک «znode موقت» می‌سازد: /election/node-۱
- کوچک‌ترین شماره = رهبر!
- زنود موقت: اتصال قطع = خودکار حذف → بقیه متوجه مرگ رهبر!
- نود بعدی «مراقب» قبلی است — مرگ رهبر = ارتقای فوری
کاربردهای واقعی
| الگو | مثال |
|---|---|
| قفل توزیع‌شده | جلوگیری از خرید دوباره بلیط، cron یکتا |
| رهبر | Kafka (controller)، دیتابیس‌ها (master) |
| هماهنگی | خدمات کشف (service discovery) |
نکته: قفل توزیع‌شده «سخت» است — اگر می‌توانید با طراحی (idempotency، صف، تراکنش DB) از قفل فرار کنید، بهتر! قفل آخرین راه است.
جمع‌بندی
- قفل توزیع‌شده: SET NX EX + چک قبل حذف
- خطرات: انقضای زودهنگام، آزادسازی اشتباه
- رهبر: Zookeeper با znode موقت
- اگر ممکن است، idempotency به‌جای قفل!
این مبحث بخشی از دوره آموزش کامل طراحی سیستم (System Design) است.