حساب‌های سلبریتی چطور مدل ارسال مستقیم را از کار می‌اندازند: چرایی ترکیب انتشار با ادغام هنگام خواندن

در محتواهای آموزشی ساده طراحی سیستم، تصویر فریبنده‌ای وجود دارد که ادعا می‌کند فید شبکه‌های اجتماعی همیشه کاملاً از قبل آماده شده است؛ طبق این روایت، به محض انتشار یک پست، سیستم بلافاصله آن را به تایم‌لاین تمام دنبال‌کنندگان تزریق می‌کند تا بدون هیچ معطلی آماده نمایش باشد.[1]

اما برای حساب‌هایی با ده‌ها میلیون دنبال‌کننده، این مدلِ ارسال مستقیم (Push) ناممکن است و کل سرویس را زمین‌گیر می‌کند. تلاش برای ارسال هم‌زمان یک پست به چنین جمعیتی، گلوگاه هولناکی به نام «بزرگ‌نمایی نوشتن» یا Write Amplification می‌سازد.[4]

در واقعیت، پلتفرم‌هایی مثل اکس و اینستاگرام برای بقا زیر ترافیک سنگین، معماری هیبریدی را ترجیح می‌دهند. آن‌ها فید کاربران عادی را از پیش محاسبه می‌کنند، اما هنگام انتشار پست توسط سلبریتی‌ها، مرحله ارسال را کلاً نادیده می‌گیرند و پست را دقیقاً در لحظه خواندن در فید شما ادغام می‌کنند.[1]

این معامله مهندسی، تنها دلیلی است که شبکه‌های اجتماعی مدرن می‌توانند فید را در کمتر از ۲۰۰ میلی‌ثانیه بارگذاری کنند. بدون آن، یک پست وایرال از یک ستاره پاپ آن‌چنان صف عملیات نوشتن دیتابیس را پر می‌کرد که سیستم برای بقیه قفل می‌شد.[2]

مکانیک پدیده بزرگ‌نمایی نوشتن

برای درک شکست مدل ارسال مستقیم، باید حساب‌وکتاب سازوکار Fan-out on Write را ببینید. در این سازوکار، فید هر کاربر صرفاً آرایه‌ای از شناسه‌های پست است که در یک حافظه سریع موقت مثل Redis نگهداری می‌شود.[2]

وقتی یک کاربر معمولی با ۲۰۰ دنبال‌کننده پستی می‌گذارد، سیستم ۲۰۰ عملیات نوشتن مجزا انجام می‌دهد تا کش مخاطبانش را به‌روز کند. مدیریت ناهمگام این حجم کار در چند میلی‌ثانیه برای پایگاه‌های داده توزیع‌شده امروزی زحمتی ندارد.[5]

اما این معادلات در رأس هرم شبکه اجتماعی کاملاً متلاشی می‌شوند. اگر حسابی با ۱۰۸ میلیون دنبال‌کننده، مثلاً جاستین بیبر یا کیتی پری، عکسی منتشر کند، سیستم برای همان یک عکس باید ۱۰۸ میلیون بار در دیتابیس بنویسد.[3]

مستندات معماری سیستم TryExponent در این باره می‌گوید: «پست حسابی با ۴۰۰ میلیون دنبال‌کننده، ۴۰۰ میلیون عملیات نوشتن در تایم‌لاین ایجاد می‌کند. این پدیده زیرساخت را اشباع می‌کند، پست‌های دیگر را پشت صف معطل می‌گذارد و تأخیرهای چند دقیقه‌ای در کل سیستم می‌اندازد».[4]

این میلیون‌ها عملیات در صف‌های طولانی انباشته می‌شوند و انتشار پست‌های بقیه کاربران را عقب می‌اندازند. در رویدادهای زنده بزرگ، این تورم عملیاتِ نوشتن می‌تواند خطوط پردازش پلتفرم را فرسنگ‌ها از زمان واقعی عقب بیندازد.[4]

جایگزینی مدل دریافت و نقاط ضعف آن

گزینه تئوریک در برابر مدل ارسال، سازوکار «انتشار هنگام خواندن» (Fan-out on Read) یا مدل مبتنی بر دریافت (Pull) است. در اینجا، پست فقط یک‌بار در دیتابیس مرکزی ذخیره می‌شود و هیچ تایم‌لاینی از قبل دستکاری نمی‌شود.[1]

وقتی کاربر اپلیکیشن را باز می‌کند، سرویسِ فید تازه دست‌به‌کار می‌شود تا آخرین پست‌های تک‌تک صفحاتی را که او دنبال می‌کند واکشی کند. سپس این نتایج را ادغام و مرتب کرده و فید نهایی را به کاربر نمایش می‌دهد.[1]

این رویکرد معضل بزرگ‌نمایی نوشتن را کاملاً حل می‌کند و انتشار پست سلبریتی هیچ هزینه مضاعفی نخواهد داشت؛ اما تمام بار محاسباتی را دقیقاً روی مسیر خواندن می‌اندازد، یعنی مسیری که بی‌شمار بار بیشتر از مسیر نوشتن فراخوانی می‌شود.[5]

به گزارش تیم تحلیلی SysGeeks: «عملیات خواندن تقریباً ۵۰ برابر عملیات نوشتن است». اگر هر بار بازخوانی فید مستلزم ارسال کوئری برای صدها حساب دنبال‌شده باشد، پایگاه داده زیر فشار وحشتناک کوئری‌های خواندن ذوب می‌شود.[5]

در مقیاسی با ۵۰ میلیارد بار مشاهده فید در روز، اجرای صدها کوئری برای هر خواندن از نظر مالی و زیرساختی فاجعه‌بار است. در نتیجه تأخیر سیستم از میلی‌ثانیه به چندین ثانیه می‌رسد و حس زنده بودن فید از بین می‌رود.[1]

آستانه تفکیک در مدل هیبریدی

چون هیچ‌کدام از دو مدل خام ارسال یا دریافت در مقیاس بالا جوابگو نیستند، مهندسان معماری ترکیبی را پیاده‌سازی کرده‌اند. سیستم کاربران معمولی و اینفلوئنسرهای بزرگ را به چشم دو مسئله مهندسی کاملاً جداگانه می‌بیند.[2]

مرز این تفکیک یک آستانه دنبال‌کننده است که بسته به ظرفیت پلتفرم معمولاً بین ۱۰ هزار تا ۱ میلیون تعیین می‌شود. حساب‌های زیر این مرز با مدل ارسال کار می‌کنند و به‌روزرسانی‌ها مستقیماً وارد کش Redis دنبال‌کنندگانشان می‌شود.[2]

اما به محض عبور یک حساب از این آستانه، رویه تغییر می‌کند: پست‌های جدید او دیگر به کش تایم‌لاین هیچ‌کس ارسال نمی‌شوند تا بزرگ‌نمایی نوشتن از همان ریشه متوقف شود.[1]

یک بررسی فنی در Whiteboard Scale اشاره می‌کند: «ما آستانه ۱۰ هزار دنبال‌کننده را برای جداسازی انتخاب کردیم؛ زیر ۱۰ هزار: انتشار هنگام نوشتن برای خواندن زیر ۱۰ میلی‌ثانیه، و بالای ۱۰ هزار: دریافت هنگام خواندن برای مهار بزرگ‌نمایی نوشتن».[2]

این آستانه یک متغیر تنظیم‌پذیر است که مهندسان متناسب با بار لحظه‌ای دیتابیس تغییرش می‌دهند. کاهش آن در ساعات اوج مصرف ظرفیت نوشتن را نجات می‌دهد و افزایش آن بار محاسباتی سرهم‌بندی فید را کم می‌کند.[4]

سرهم‌بندی فید در لحظه خواندن

ترفند اصلی مدل هیبریدی دقیقاً در همان چند میلی‌ثانیه‌ای رخ می‌دهد که کاربر برنامه را باز می‌کند. سرویس ابتدا تایم‌لاینِ پیش‌محاسبه‌شده مربوط به کاربران عادی را از کش Redis که حدود ۸۰۰ شناسه پست اخیر را دارد، می‌خواند.[2]

هم‌زمان، سیستم گراف اجتماعی کاربر را بررسی می‌کند تا ببیند کدام‌یک از سلبریتی‌های بالای آستانه را دنبال کرده است. سپس فقط برای همان چند حساب خاص، یک درخواست دریافت زنده می‌فرستد.[1]

از آنجا که میلیون‌ها نفر پست‌های این افراد را هم‌زمان درخواست می‌کنند، این داده‌ها همیشه در کش‌های بسیار سریع لبه شبکه (Edge) آماده‌اند و نیازی به فراخوانی دیتابیس اصلی نیست؛ بنابراین عملیات دریافت بسیار کم‌هزینه تمام می‌شود.[4]

سپس سرویس، پست‌های واکشی‌شده سلبریتی‌ها را با تایم‌لاین قبلی ادغام و براساس زمان یا الگوریتم رتبه‌بندی می‌کند و فید یکپارچه نهایی را تحویل دستگاه شما می‌دهد.[1]

این ادغام در زمان خواندن آن‌قدر سریع انجام می‌شود که کاربر هرگز متوجه نمی‌شود فید او از دو لایه زیرساختی کاملاً جداگانه سرهم شده است؛ کل پروسه معمولاً زیر ۲۰۰ میلی‌ثانیه تمام می‌شود.[2]

مهار بدترین سناریوهای محاسباتی

موفقیت معماری هیبریدی در این است که بدترین سناریوهای هر دو سو را مهار می‌کند: نه اجازه می‌دهد یک پست میلیون‌ها نوشتن ثبت کند، و نه می‌گذارد باز کردن فید به صدها کوئری سنگین تبدیل شود.[5]

مستندات طراحی سیستم توضیح می‌دهند: «تفکیک هیبریدی بدترین گلوگاه‌ها را حذف می‌کند. ادامه فرایند توزیع روی کارگران ناهمگام انجام می‌شود تا انتشار پست معطل نماند و کل اطلاعات هم در حافظه کش توزیع می‌گردد».[6]

با ایزوله کردن حساب‌های سنگین، شرکت‌ها می‌توانند هزینه‌های زیرساختی خود را به شکل دقیقی پیش‌بینی کنند؛ مصرف حافظه نیز کاملاً مهار می‌شود زیرا تایم‌لاین هر کاربر در سقف ثابتی در حدود ۶٫۴ کیلوبایت متوقف می‌ماند.[2]

این معماری پاک‌سازی و تعدیل محتوای وایرال را هم ساده می‌کند؛ چون در کش کاربران فقط شناسه‌های پست ذخیره می‌شوند نه متن کامل، برای حذف پست یک چهره مشهور فقط تغییر یک رکورد مرکزی کافی است.[4]

در نهایت، روانی فیدهایی که روزانه مرور می‌کنیم حاصل موازنه بار دقیق پشت صحنه است؛ سیستم با تمام حساب‌ها رفتار یکسانی ندارد، بلکه آن‌ها را بر اساس تعداد مخاطبانشان از مسیرهای سخت‌افزاری کاملاً متفاوتی هدایت می‌کند.[6]

نقش کلیدی کش‌های درون‌حافظه‌ای

پایایی این سازوکار هیبریدی در گرو بیرون راندن فیدهای پیش‌محاسبه‌شده از دیتابیس‌های سنتی دیسک‌محور است؛ پلتفرم‌ها این فهرست‌ها را در کش‌های درون‌حافظه‌ای توزیع‌شده مثل Redis نگه می‌دارند که پاسخگوی میلیون‌ها درخواست در ثانیه هستند.[2]

در ردیس، تایم‌لاین کاربر معمولاً به صورت یک ساختار Sorted Set ذخیره می‌شود که با برچسب زمانِ هر پست مرتب شده است؛ این ساختار اجازه می‌دهد تازه‌ترین صفحه بدون اسکن بیهوده کل داده‌ها فراخوانی شود.[2]

تحلیل Whiteboard Scale نشان می‌دهد: «ما استفاده از مجموعه‌های مرتب ردیس را انتخاب کردیم چون واکشی ۸۰۰ شناسه توییت را زیر ۱۰ میلی‌ثانیه ممکن می‌کند؛ یعنی فقط ۶٫۴ کیلوبایت برای هر کاربر و ۱٫۲۸ ترابایت برای ۲۰۰ میلیون کاربر».[2]

ذخیره کردن صرف شناسه‌ها بدون پیوستن متن یا رسانه، حجم مصرف حافظه را به شکل معناداری پایین می‌آورد؛ هنگام نمایش، یک سرویس مجزای تکمیلی (Hydration) متن و تصویر واقعی را برای این شناسه‌ها لود می‌کند.[5]

مهار بحران ترافیک ناگهانی یا Thundering Herd

با این حال، حساب‌های سلبریتی حتی در سازوکار دریافت زنده با مشکلی روبه‌رو هستند که مهندسان به آن «رمه خروشان» یا Thundering Herd می‌گویند: وقتی چهره‌ای مشهور پست می‌گذارد، میلیون‌ها نفر هم‌زمان فید خود را نوسازی می‌کنند.[4]

اگر تمام این درخواست‌های خواندن یک‌باره به پایگاه داده اصلی اصابت کنند، سقوط سیستم حتمی است؛ برای پیشگیری، پلتفرم‌ها سیاست کش لبه‌ای (Edge Caching) را با سخت‌گیری اجرا می‌کنند.[1]

به محض انتشار پست توسط یک سلبریتی، نسخه آن به شبکه‌های توزیع محتوا و سرورهای لبه در سراسر دنیا پرتاب می‌شود؛ بنابراین سرویس هنگام سرهم‌بندی فید، داده را از کش محلی برمی‌دارد نه دیتابیس مرکزی دوردست.[6]

این لایه‌بندیِ کش تضمین می‌کند که ادغام در لحظه خواندن بدون هزینه پردازشی سنگین ادامه یابد؛ این همان شبکه نجات پنهانی است که اجرای مدل انتشار هیبریدی را در مقیاس‌های میلیاردی ممکن می‌سازد.[6]