چگونه پی‌پال با ۸ ماشین مجازی، روزانه ۱.۲ میلیارد تراکنش را پردازش می‌کند؟🚀

در این نوشتار به صورت مختصر این معماری فوق‌العاده را با هم بررسی می‌کنیم

پی‌پال چگونه مسیر خود را پیدا کرد؟

پی‌پال در سال ۱۹۹۸ به‌عنوان یک شرکت امنیتی شروع به کار کرد، اما مدل کسب‌وکار اولیه‌اش موفق نبود. پس از یک تغییر استراتژیک (پیوت)، به سرویس پرداخت آنلاین تبدیل شد و نام PayPal را برگزید.
با افزایش سریع کاربران، نیاز به سخت‌افزار قدرتمندتر احساس شد، اما این تنها آغاز چالش‌های مقیاس‌پذیری بود.

راه‌حل اولیه: مقیاس‌پذیری افقی (Horizontal Scaling)

در کمتر از دو سال، پی‌پال به بیش از ۱ میلیون تراکنش روزانه رسید. اما قانون مور (Moore’s Law) که پیش‌بینی می‌کرد هر دو سال تعداد ترانزیستورها دو برابر شود، به کندی گرایید.
افزایش عملکرد پردازنده‌های سینگل‌ترد متوقف شد، و صرفاً ارتقای سخت‌افزار دیگر پاسخگوی نیاز نبود.

پی‌پال برای حل این مشکل، سرویس‌های خود را روی بیش از ۱۰۰۰ ماشین مجازی اجرا کرد. این کار مشکل را موقتاً حل کرد، اما چالش‌های جدیدی به وجود آمد:
افزایش لتنسی شبکه
هزینه‌های زیرساختی بالا
پیچیدگی مدیریت سیستم‌ها
مصرف ناکارآمد منابع (CPU کم‌بار)

راه‌حل نهایی: مدل اکتور (Actor Model)

پی‌پال به دنبال سیستمی ساده، مقیاس‌پذیر و کم‌هزینه بود. در نهایت، معماری خود را بر پایه مدل اکتور طراحی کرد و به فریم‌ورک Akka (یک ابزار قوی بر پایه JVM و Java) مهاجرت کرد.
مدل اکتور چیست؟
اکتورها واحدهای فوق‌سبک پردازشی هستند که به‌جای استفاده از تردها، از پیام‌های غیرقابل‌تغییر (Immutable Messages) برای ارتباط استفاده می‌کنند.
این تغییر به پی‌پال اجازه داد میلیون‌ها اکتور را در سیستم مدیریت کند و به سطح جدیدی از کارایی دست یابد.

مزایای مدل اکتور برای پی‌پال

استفاده بهینه از منابع
اکتورها فقط در لحظه پردازش پیام یک ترد دریافت می‌کنند. تعداد تردها محدود به تعداد هسته‌های CPU است، و با Dynamic Thread Pooling هزاران اکتور به‌طور همزمان اجرا می‌شوند.
مدیریت بهینه State
اکتورها ایزوله و بدون حافظه مشترک هستند. هر اکتور یک Mailbox دارد که پیام‌ها را به‌صورت FIFO ذخیره می‌کند.
این معماری نیاز به کش‌های توزیع‌شده یا دیتابیس اضافی را کاهش داده و با ذخیره‌سازی محلی، لتنسی را به حداقل می‌رساند.
کانکارنسی بالا بدون بلاک شدن
هر اکتور پیام‌های خود را به‌صورت ترتیبی پردازش می‌کند، اما چندین اکتور می‌توانند همزمان و غیرهمزمان اجرا شوند.
این معماری از بلاک شدن پردازش‌ها جلوگیری می‌کند و با استفاده از برنامه‌نویسی Functional، ساید افکت‌ها را حذف می‌کند.

نتیجه؟
با این تغییر معماری، پی‌پال توانست با فقط ۸ ماشین مجازی، روزانه ۱.۲ میلیارد تراکنش را پردازش کند، درحالی‌که هزینه‌های زیرساختی را ۹۰٪ کاهش داد!
مراجع :
https://newsletter.systemdesign.one/p/actor-model